Hallo, bisher habe ich in meinem Programm alle Texturen mit gluBuild2DMipmaps geladen, und zwar mit
folgender Funktion, die einwandfrei funktioniert:



Viele Texturen (z.B. für Menüs) brauchen aber keine Mipmaps, deshalb möchte ich diese mit glTexImage2D laden. Außerdem stört bei gluBuild2DMipmaps, dass die Texturmaße auf 2^n zurechtgestaucht werden. Ersetze ich in der obigen Funktion nun den Befehl durch



gibt's nur weiße Flächen. Dabei sind bis auf die zusätzlichen Parameter level und border die Parameter doch identisch, soviel ich weiß. Ist da im Hintergrund noch was zu beachten?

Ja. Es gibt dort noch mehr zu beachten. Ganz wichtig. Wenn du keine MipMaps erstellst, dann darf deine Textur auch keine MipMaps benutzen. Also der MIN Filter darf entweder GL_NEAREST oder GL_LINEAR sein. GL_*_MIPMAP_* erzwingt immer die Verwendung von MipMaps. Wenn die nicht vorhanden sind, dann ist die Textur ungültig und es gibt weiße Flächen.

Aber ich kann generell nur von gluBuild2DMipmaps abraten. Selbst wenn du MipMaps benötigst solltest du Alternativen in betracht ziehen. Seit OpenGL 1.4 bzw durch die Erweiterung GL_SGIS_generate_mipmap kann OpenGL selbsttätig MipMaps erstellen. Das Einzige was man dann setzen muss ist der Parameter GL_GENERATE_MIPMAP. Sonst ganz normal mit glTexImage die Texturen hochladen.


Seit den FrameBufferObjects sollte man eigentlich sogar auch noch eine andere Methode bevorzugen. Diese Erweiterung bringt eine Methode mit, mit der man die Erstellung der MipMaps manuell anstoßen kann. So kann man zu einem kontrollierten Zeitpunkt die MipMaps erstellen lassen. Dadurch schraubt man aber auch die Anforderungen massiv in die Höhe. In meinem Texturenloader benutze ich aber überwiegen nur noch den Parameter GL_GENERATE_MIPMAP bzw nur als letzten Ausweg die Methode gluBuild2DMipmaps. Falls nichts Anderes unterstützt wird. Die Methode mit den FBOs benutze ich auch noch nicht.

PS: Hat es einen tieferen Sinn warum du bei glTexParameter die Variante für floats benutzt?

Danke Lossy, das war eine klare und erschöpfende Antwort. Ein Handgriff, und es funktioniert. Die rechteckigen Vorschaubilder im Menü-Screen kamen nämlich ziemlich verschwommen, nun sind sie deutlich. Ist ja auch logisch: Mit gluBuild2DMipmaps werden die zuerst auf quadratisch oder stark rechteckig gequetscht, anschließend wieder auf richtiges Seitenverhältnis gebracht. Das hält kein Bild aus.

In der Szenerie gibt es ohne Mipmaps natürlich ein fieses Flimmern, dazu werde ich mir deine weiterführenden Tipps mal zu Gemüte führen.



Nee, hab' das f durch i ersetzt.

Entnehme ich aus deiner Antwort richtig, dass deine Bilder keine Kantenlängen von 2^n haben? Wenn das so ist, solltest du das ändern, indem du z.B. den rest mit Schwarz auffüllst. Denn alte Grafikkarten (oder auch abgespeckte neuere) können damit nicht umgehen und liefern dann ebenfalls nur weiß.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Es geht hier nur um einige verkleinerte Screenshots, die in den Menü-Bildschirmen mit 192 x 144 erscheinen sollen. Alles andere liegt selbstverständlich mit Kantenlängen 2^n vor. Sicher, man könnte die Bilder auf 256 x 256 bringen und in einen transparenten Bereich legen, aber andererseits sollen die Benutzer ihre eigenen Screenshots für das Programm verfügbar machen. Da könnte die Aufbereitung Probleme machen.

Was die Grafikkarte betrifft: In meinem nicht mehr taufrischen Rechner (5 - 6 Jahre alt) steckt eine FX 5200, die inzwischen nur noch auf dem Flohmarkt zu haben ist. Diese arbeitet schon mit Version 2.1 und hat keine Probleme mit rechteckigen Texturen. Ich gehöre bestimmt nicht zu den Leuten, die immer das neueste voraussetzen, doch manchmal habe ich das Gefühl, dass die Rücksicht auf alte Geräte irgendwo an eine Grenze stößt. Ich weiß, ich weiß ... saubere Programmierung und so. Aber das wäre ein Punkt zum Diskutieren.

Ich weiß nicht, ob es sowas schon gibt, aber vielleicht wäre eine Liste mit den Grafikkarten und den implementierten OpenGL-Versionen ganz nützlich. Ich denke an die letzten 5 - 8 Jahre.

Eine Liste mit implementierten Funktionen (Kern + Erweiterungen) gab es mal (delphi3d.net). Die Seite ist aber ziemlich tot. Allerdings sind die OpenGL Versionen primär nicht von der Hardware sondern vom Treiber abhängig. Denn OpenGL beschreibt nur eine Schnittstelle. Wie das implementiert wird liegt in der Hand der Treiber. Das kann unter anderem auch ein Softwaremodus sein. Dann sieht das Bild zwar okay aus aber es wird nur noch ca 1 Bild in der Sekunde dargestellt. Mein Lieblingsbeispiel in dem Zusammenhang sind die ATI Chips der Radeon 9x00 Reihe und die eben angesprochenen NPOT Texturen. ATI implementiert OpenGL in der Version 2.0 und damit sollten theoretisch auch NPOT Texturen voll unterstützt werden. Sollte man die NPOT Texturen aber in Verbindung mit MipMaps benutzen, dann fällt der Treiber in einen Softwaremodus. Einfach so. Und das Programm ist urplötzlich und ohne ersichtlichen Grund langsam. Das schlimmste daran ist, dass sich so etwas nicht mal mit der Spezifikation von OpenGL beißt. Neuere Karten von ATI haben dieses Problem aber nicht mehr.

Was die hardware angeht denke ich muss man sich überlegen was man machen will bzw wofür das Programm gedacht ist! Wenn man sagt es soll auch neuere Techniken benutzen, dann sollte man diese zu mindest überprüfen und im Falle des nicht vorhandenseins dann auch die Arbeit verweigern. Damit wäre der Sauberkeit auch schon genüge getan. Wenn Shader zum Einsatz kommen, dann läuft wohl nichts ohne OpenGL 2.0. Sollten aber die NPOT Texturen das Einzige sein was man an "neuen" Technologien benutzt, dann muss man sehen wie das Verhältnis ist. Ansonsten denke ich aber sollte OpenGL 2.0 mittlerweile weit genug verbreitet sein (wobei ich die Masse der Laptops gar nicht einschätzen kann). Bzw sollten das ATI Phänomen einiger Karten bei dir aber auch nicht mal zum Problem werden.

PS: Du müsstest die Texturen auch gar nicht anpassen. Es gibt auch so etwas wie Texture_rectangles. Das ist ein Target so ähnlich wie TEXTURE_2D. Aber für NPOT Texturen der ersten Stunden. Die Rectangles unterstützen von Hause aus keine MipMaps. Das Einzige was du bei Bedarf ändern müsstest wäre ein anderes Texturtarget und Texturekoordinaten die nicht mehr auf 0-1 normalisiert sind.