Mir fehlt grade irgendwie das Verständnis weshalb gluBuild2DMipmaps überhaupt noch einen Effekt auf texture hat, da ja hier nur die Ursprünglichen Daten verändert werden können - oder sehe ich das falsch? warum generiert mir das genau so meine Textur?


Ich fühle mich ja etwas unbeholfen, aber ich war wohl zu lange nicht in der Materie

Gruß .grey

Wieso sollte das keinen Effekt haben. Du hast deine Daten in den RAM geladen und lädst sie mit gluBuild2DMipmaps zur Grafikkarte. gluBuild2DMipmaps verändert deine Textur und lädt sie dann mir glTexImage2D witer hoch. Bzw er generiert auch noch die MipMaps und lädt die auch hoch.

Statt gluBuild2DMipmaps zu verwenden empfehle ich dir wärmstens einfach das folgende Flag zu setzen und die Textur mit glTexImage2D hoch zu laden.

1. Mindestens seit OpenGL 1.5 ist das der offizielle Weg um Mipmaps zu generieren.
2. Wenn die Textur nicht power-of-two ist wird nicht komisch rumskaliert wie bei gluBuild2DMipmaps
3. die Erzeugung der Mipmaps dürfte auf der Grafikkarte geschehen und nicht per Software.
4. keine Abhängigkeit von GLUT.

_________________
Yeah!

Coolcat, bei mir muss was falsch laufen, ich habe glut nicht installiert, kann aber trotzdem MipMaps auf dem "alten" Weg benutzen.

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

glu != glut
Kleiner tippfehler von Coolcat

Glu gehört irgendwie mit zum Ztandardumfang des Betriebssystems wärend glut das nicht ist. Glu bietet aber auch nur so ein paar kleine Hilfen für OpenGL. Ich verwechsel glu und glut auch ständig.

Nichts desto trotz. Das was Coolcat gesagt hat stimmt. gluBuild2DMipmaps ist so ziemlich die älteste Methode um MipMaps zu erstellen. Abgesehen wird dabei die Grafikhardware komplett außer acht gelasen.

ABER. Coolcats Methode ist eigentlich auch schon wieder überholt. Denn dabei kann man nicht mehr kontrollieren wann die MipMaps erstellt werden. Besonders im Zusammenhang mit FrameBufferObjects ist das eher unpraktisch. Deswegen gibt es bei FBOs eine Methode namens glGenerateMipmap. Diese Methode erzeugt zu einem definiertem Zeitpunkt die MipMaps des übergebenen TexturTargets. Und zwar genau dann wann man sie braucht und auch nur dann und nicht jedes Mal wenn sich die Textur verändert. In 3.0 ist das auch nur noch die einzige Möglichkeit. Der Parameter gilt dort als deprecated.

Oh...GLU != GLUT wusste ich nicht...musste immer GLUT installieren damit glu-Funktionen verfügbar sind

glGenerateMipmap gibt es in OpenGL 2.x noch nicht, hatte das gestern jedenfalls nicht gefunden. Und bei jemandem der mit gluBuild2DMipmaps arbeitet gehe ich nicht davon aus das er OpenGL 3 verwendet.

_________________
Yeah!

[OffTopic]
glut ist im grunde eigentlich soetwas wie SDL.. also eine möglichkeit platformunabhängig ein/mehrere Fenster mit OpenGL context zu erstellen.

glu sind "nur" ein paar utility funktionen die das leben bei OpenGL etwas leichter machen sollten

Na ja. Es gibt noch viele Stellen an denen gluBuild2DMipmaps als das non plus ultra gehandelt wird obwohl der Parameter schon Asbach ist (die SGIS Erweiterung ist von 97). Das ist auch ein Nachteil vom Web. Selbst solche Aussagen verschwinden nicht auf absehbare Zeit.

Prinzipiell hast du aber recht. glGenerateMipmap stammt aus der Erweiterung GL_ARB_framebuffer_object und diese ist Bestandteil des 3.0er Kerns. Vorher ist es nur als Erweiterung vorfügbar. Bzw. gibt es noch die Methode glGenerateMipmapEXT aus der Erweiterung GL_EXT_framebuffer_object. Die EXT Variante der Erweiterung gibt es glaube ich schon seit 2.0 und dürfte wohl auch die gebräuchlichere Variante sein.

Ich benutze es vornehmlich deshalb, weil ich keine 2^x Texturen habe sondern beliebige Bilder (soll eine Art Bildbetrachtungsprogramm werden) und ich speicher mir die Skalierung des Bildes in zwei kleinen Variablen

@Lossy: Danke, das mit dem RAM zur Graka war mir nicht mehr im Bewusstsein ... das erklärts mir zumindest

LG .grey

Besonders dann solltest du auf gluBuild2DMipmaps verzichten. Denn gluBuild2DMipmaps verändert deine Daten. Wenn du also keine pot Textur hast wird die unweigerlich matschig. Außerdem brauchen die MipMaps mehr Speicher. Obendrein ist der noch tierisch langsam. Also da solltest du entweder npot texturen benutzen oder aber deine pot texturen erweitern und die Bilder 1:1 rein packen.

Also das mit dem langsam hab ich grad festgestellt - könntest du mir nen Beispiel machen, wie ich die Textur anständig erweitern kann? Also nen Ansatz würde mir schon reichen.

LG .grey

Beispiele für die verschiedenen Mipmap Arten würden sich auch im Wiki gut machen. Am besten mit Aussagen zur Geschwindigkeit.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Na ja. Was ich meinte war die Textur so zu erweitern, damit sie in POT reinpasst. Sagen wir mal du hast ein Bild 500x789. Dann müsste das auf 512x1024 erweitert werden. Die eigentliche Textur würde dann nur noch dort hineinkopiert werden. Der Rest wäre dann leer. Ziemlich genau so wie Wilson das im Meinungsthread der glBitmap gepostet hat.

Problem an der Methode entstehen dann wenn man die Texturen skaliert. Wenn man mit CLAMP_TO_EDGE arbeitet, dann befindet sich die Ecke weit außerhalb unserer Textur und entsprechend fällt das Clamp dort durch. Wenn man MipMaps benutzt um ein schöneres (ruhigeres etwas weicheres) Bild beim Skalieren zu ereichen, dann werden für die MipMaps auch die Teile der Texturen benutzt die nicht dafür bestimmt sind. Um das zu verhindern müsste man die letzte Zeile der Textur bis zum Ende wiederholen. Bzw die letzten Pixel jeder einzelnen Zeile müssten bis zum Ende wiederholt werden. Das ist im Endeffekt was das Clamp to edge machen würde. Dann passt das auch wieder wenn die MipMaps berechnet werden. Und man hätte POT Texturen.

Aber ich würde dahingehend erst mal schauen ob man das nicht auch alles mit NPOT Texturen hinbekommt. Denn das spart Speicher, Leistung und Arbeit. Setzt allerdings vielleicht geringfügig größere Hardware vorraus.

@Flash: Ob man da wirklich aussagen zur Geschwindigkeit machen wage ich zu bezweifeln. Es gibt nur eines was wirklich fest steht. gluBuild2DMipmaps ist mit Abstand das Langsamste.

@Flash :
Geschwindigkeitsunterschiede gibts da ja nur beim Laden. Und das hab ich die Tage bereits im MipMap-Artikel nachgetragen. Also das gluBuildMipMaps sehr langsam beim Erstellen der Maps ist (und nicht flexible), und man daher MipMaps selbst erstellen und laden soll, ggf. via DDS.

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