Keine Ahnung obs am Alter, der Hardware oder den Treiber liegt, aber nachdem ich gluBuildMipMaps2D aufgrund seiner elendigen Langsamkeit komplett gegen die automatische Mipmapgenerierung eingetauscht habe, (für statische Texturen, kein Offscreen-Puffer wie bei meinem letzten Problem) musste ich feststellen dass ich bei Texturen die nicht 2n^2n sind keine Fehlermeldung mehr bekomme.

Da ich den Code für diese Sache schon länger im Texturenloader habe und einfach nur per Flag toggle, bin ich mir aber ziemlich sicher dass spätestens bei einer Textur die obigen Dimensionen nicht entspricht ein GL-Fehler ernstehen sollte (GL_INVALID_VALUE, inzwischen Teste ich aber auf <> GL_NO_ERROR, mit dem selben Ergebnis). Da wunderts mich doch dass ich keine Fehlermeldungen bekomme und die Textur später auch anstandslos (also kein weisses Quad) gerendert wird. Hab extra ne Textur mal auf 34x34 Pixel skaliert, wird problemlos geladen und dargestellt. Den Code hab ich glaub ich noch auf meiner Radeon9700 geschrieben, und da gibts definitiv ein GL_INVALID_VALUE + Weissem Quad bei der Anzeige, wenn die Textur nicht 2^n*2^n war.

Automatische Mipmaps aktivere ich übrigens via GL_GENERATE_MIPMAP_SGIS :


Diese automatische Mipmap-Generierung geschieht ja in Hardware (oder zumindest im Treiber), also kanns sein dass hier verschiedene Treiber/Hersteller verschieden reagieren, oder kann ich jetzt getrost auch Texturen <> 2^n*2^n dadurch jagen ohne mir Sorgen machen zu müssen dass es woanders nicht läuft? Hab leider keine Graka von nem anderen Hersteller mehr zur Verfügung, sonst würde ich selbst testen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Bei ARB_texture_non_power_of_two(GeForce6) kann man bei allen Texturen beliebige Größen ohne besondere Einschränkungen verwenden. Bei Cubemaps müssen sie aber zumindest quadratisch sein.

Danke für den Hinweis, Lars. Leider scheint diese Extension wirklich nur auf NVidia-Karten implementiert zu sein (ab GF6) und bei einigen kleineren Herstellern. ATI hat da wohl keinen Support dafür, schade eigentlich.

Edit : Sehe grad dass ARB_texture_non_power_of_two 2.0-Kernfeature ist, also siehts wohl einfach so aus dass ATI dass unterstützten, aber den String nicht exportieren.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Sehr gute Entscheidung.

Nach meinem Wissensstand besteht das Problem mehr oder weniger immer noch. Bzw war es vor einer Weile sogar so, dass man sobald man NPOT und MipMaps benutzt er in den Software gewechselt hat. Was ich persönlich für sehr fatal halte, da OpenGL eigentlich sagt, dass es unterstützt wird es aber doch nicht getan wird. Ob auch neuere Modelle davon betroffen sind kann ich nicht sagen oder Testen

Ich kann es aber hier auf arbeit nicht ausprobieren weswegen ich das später zu hause auf meiner 9600 Pro noch mal mit den aktuellsten Treibern testen werde und dann die Ergebnisse poste. Aber ich denke nicht, dass sich an meiner Aussage etwas ändern würde.

Extension: Ja das ist richtig. NPOT Texturen sollten eigentlich ab OpenGL 2.0 von allen System unterstützt werden. Und ein Bestandteil davon sind unter anderem der volle Support für MipMaps.

Wie angedroht habe ich das noch mal auf meiner Radeon 9600 Pro getestet.

Und na ja. Wie ich befürchtet habe hat sich nichts verändert. Sobald per Filter Mipmapping aktiviert und Mipmaps erzeugt sind braucht er zwei Sekunden um ein Bild zu rendern. Sobald MipMaps erstellt sind aber nicht aktiviert worden geht es.

Oh je, dass ist eigentlich das denkbar schlechteste Szenario. Ich denke mal dein Treiber gibt dir auf deiner Radeon 9600 nen 2.0er Versionsstring zurück, oder? Das bedeutet also dass ich auf so einer Kombination keine Möglichkeit hätte zu unterscheiden ob ich die automatische Mipmap-Generierung für NPOT-Texturen deaktivieren muss oder nicht. Wenn die Karte dann wenigstens nen GL-Error werfen würde wärs einfach dann auf gluBuildMipMaps2D zu wechseln, aber so ists denkbar schlecht. Macht ja echt "Sinn" so ein Feature zu implementieren, es aber dann in Software zu emulieren, nur damit die Karte OpenGL2.0-Konform ist...

Werd ich also wohl wieder vorm Release alle NPOT-Texturen im Bildbearbeitungsprogramm auf 2^n*2^n skalieren.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ja. Das ist wohl das Sinnfreiste was die sich hätten einfallen lassen können. Und nein einen Fehler habe ich natürlich auch nicht bekommen. Wie sollte es auch anders sein. Das Einzige woran man das derzeit unterscheiden kann ist die Extension selbst. Ati unterstützt sie nicht. Aber wer weiß ob sie das nicht auch noch irgendwann machen.

Aber wenn du stattdessen die Texturen durch gluBuildMipMaps2D jagen musst dann ist das auch nicht unbedingt die beste Lösung. Sowohl Qualitativ als auch von der Geschwindigkeit her. Auf die MipMaps verzichten geht dabei rein zufällig nicht, oder? Aber sonst wären POT Texturen wohl die beste Wahl.

PS: Aber ein gutes hat es. Durch die Tests habe ich gesehen, dass ATI seit "neustem" auch ARB_texture_rectangle. Ob sie es auch mit Shaderunterstützung tun steht allerdings in den Sternen. So sicher kann man sich da ja gerade nicht mehr sein.

Nein, auf Mipmaps will ich nicht unbedingt verzichten. Allerdings sind nur sehr wenige Texturen NPOT, da ich ja inzwischen selbst Texturen für 3D-Objekte usw. selbst mache und daher auch die original Photoshop-Dateien hab, da kann ich dann ohne Verluste/Probleme selbst auf POT skalieren. Ärgerlich ists natürlich trotzdem, weil mein Projekt evtl. auch modbar seins soll und ich dann trotzdem darauf reagieren muss.

Manchmal kann der ganze OpenGL-Extension/Kernversionskram aber auch echt nervig sein...

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Vor allem wen jemand der Meinung ist er müsse sich nicht an so etwas lächerliches wie eine Spezifikation halten müssen.


Du könntest ja auch wie in alten Spielen üblich einen Speedtest machen. Beim Starten der Anwendung 1 Bild damit rendern und wenn es zu lange dauert dann wird es nicht unterstützt. Dann kannste den User auch einschränken oder ihm halt die Freiheit schenken. Aber ich glaube mir ist gerade mein Sinn für Realismus abhanden gekommen.

Das mit dem Test der Render-Geschwindigkeit stand im Zusammenhang mit GLSL auch schonmal bei opengl.org und scheint wohl nicht so schlecht zu sein. Aber es nützt ja leider nichts, weil wenn der Test fehlschlägt braucht man die Bilder dann trotzdem in 2^n Größe.
NVidia hatte das früher auch mal. Da konnte die GeForce2 angeblich OpenGL 1.4(?) mit 3D Texturen, aber die Extension war nicht im Extension String und wurde per Software gerendert.

Hi,

ich weiß das ist denk ich eine sehr "dumme" lösung um zu testen ob es unterstüzt wird, aber es würde funktionieren:
Render doch beim Programmstart eine 3x5 große schwarze textur mit deiner MipMap erzeugung und schau ob du nen weißes oder schwarzes pixel hast an der stelle dann

Ich weiß, is dämlich... aber ähnliche probleme habe/hatte ich bei meinem Flipbook auch im bezug auf TextureRectangle und Shader (ich compilier - sofern Rect-Texturen unterstüzt werden) extra nen test-shader um zu sehen ob es wirklich geht.. -.-

Aya~

EDIT/PS: Wobei trotzdem das problem bestehen bleibt - was, wenn das Pixel weiß ist? :p

Diese Lösung bringt ja nix, denn auf Lossys 9600 klappt das Feature ja, ist aber elendig lahm da es in Software emuliert wird. Und einen Rendertest in eine extra Fenster wie anno dazumal (ich glaub sowas hab ich das letzte mal beim dritten Kyrandia-Teil gesehn) will ich auch nicht.

Irgendwie find ich die Problematik sowieso ziemlich ärgerlich, denn dass was ATI da machen sollte meiner Meinung nach mit einer Strafe (evtl. seitens des ARBs) belegt werden. Wenn ich eine API mit einem festen Funktionssatz habe, deren Funktionen nur für Echtzeitanwendungen gedacht sind (ist ja bei OpenGL primär so) kann es nicht sein dass sich ein Hardwarehersteller eine hohe Versionsnummer ermogelt in dem er mandatorische Funktionen über den Softwareweg erschummelt. Dadurch führt er ja die ganze Versionierung ad Absurdum, denn dann könnte ja jeder Hersteller hingehen und alles was seiner Hardware fehlt über Software emulieren um dann einen entsprechenden Versionsstring ausgeben zu können. Ich frag mich ob Microsoft unter D3D sowas auch erlauben (bezweifle es).

Aber mit sowas muss man wohl leben. Eigentlich will ich mein Projekt ja für GL2.0-Hardware auslegen, aber selbst darauf kann ich mich nun nicht mehr verlassen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Wobei man da auch sagen muss, dass eine 3x5 große Textur nicht sonderlich Aussagekräftig ist. Die ist so klein das macht selbst die CPU ziemlich fix. Also da sollte es schon eine im 500er Bereich sein. Denn nur dann kann man sagen, dass es wirklich emuliert wird. Wenn man so etwas zum Begin der Anwendung machen würde dann würde es ein mal höchstens 2-3 Sekunden (stark aufgerundet) länger dauern. Das sollte noch verkraftbar sein.

Nur um das mal zu erwähnen ich finde es auch reichlich lächerlich, dass man mehr oder minder dazu genötigt wird solche Lösungen zu implementieren oder darüber nachdenken zu müssen. Das sollte in der heutigen Zeit einfach nicht nötig sein. Wobei du mit FBOs und PixelBuffern ja auch so deine Differenzen hast. Und dafür wäre so etwas auch nicht unbedingt Nachteilig.

Lars: Ich meinte das jetzt nur für die User. Es macht natürlich keinen Sinn, wenn Sascha POT und NPOT Texturen ausliefern würde. Aber es würde dem User doch weniger Steine in den Weg legen, wenn benutzerdefinierte Texturen auf System N(vidia) erlaubt werden würden und auf Sytem A(ti) eben nicht erlaubt würden. Je nachdem ob der Test positiv war oder nicht.


Wie sieht das eigentlich mit der MesaGL aus? Die unterstützt ja auch OpenGL 2.0. Aber ich meine dadurch dass die keinen Treiber mitbringt wird die von Hause aus als Generic gekennzeichnet.