"power of two" - Texturen: Ein Dilemma?

[ecto111]

Liebe Community,

einmal mehr stehe ich vor einem kleinen Dilemma, das vielleicht keins ist und deshalb hier diskutiert werden könnte:

Warum auch immer geht man als Benutzer jeglicher GameEngines aus irgendeinem Grund davon aus, dass Texturen, die in ihren Maßen eine Potenz von Zwei repräsentieren (d.h. 2, 4, 8, 16, 32, 64, usw.) und dabei ein Quadrat darstellen, besser sind als andere.
Mein Verständnis davon ist, dass solche Texturen die Grafikkarte weniger stark belasten und damit ihren Teil zur Performance beitragen, aber das ist nur Halbwissen, deshalb ja auch dieser Thread hier.

Allerdings ist mir heute beim Arbeiten aufgefallen, dass ich bei einer rechteckigen Alpha-Textur (mit den ungewöhnlichen Maßen 320x160 Pixel) eine Menge Platz verschwenden würde, wenn ich das Ganze auf eine 512x512 (oder mit entsprechendem Qualitätsverlust auf eine 256x256) Pixel große Textur klatschen würde. Macht also der Performance-Unterschied zwischen ungerader Zahl und verschwendeter Fläche die Verschwendung von Fläche wett? Ist er bei dementsprechend vielen Objekten überhaupt bemerkbar?
Und wie sieht es zum Beispiel mit einer 128x512 Pixel Textur aus?

Ich hoffe aus diesem halben Roman geht meine Fragestellung einigermaßen klar hervor.
Vielen Dank im Voraus für Eure Antworten!

Grüße,
ecto

[Doc Holiday]

Es war denke ich mal so, das die Grafikkarten ihren Speicher so unterteilt haben. Also eine eine 100x100 Textur trotzdem einen 128x128 großen Block belegt hat. Die restlichen Pixel waren dann quasi leer und verschenkt. Mit den Zugriffszeiten hat das vermutlich auch war zu tun. Ich schätze das ist immer noch so.

Quadrat mußte glaub ich nicht unbedingt sein. Als sowas wie 256x512 war erlaubt.

[Malo]

Genau, Power of Two bezieht sich nicht nur auf 512x512 sondern auch auf 512x2048.
Du kannst also ohne weiters gestreckte varianten nehmen.

[Monster]

Das hat ganz einfach was mit der Effizienz beim Zugriff auf die Textur zu tun.

Die Textur wird als Baum betrachtet. Z.B. wird die Textur in der Mitte geteilt, dann wird entscheiden, ob links oder rechts gesucht wird. Dort macht man dann das gleiche.

Dadurch erhält man einen Aufwand von O(log(n)) was sehr effizient ist (bezogen auf große Datenmengen).

Die Suche in einem Baum geht am besten, wenn der Baum ausbalanciert ist. D.h. alle Zweige sind gleich lang/groß. Man kann dann bestimmte Prüfungen ausschließen. Fehlende Prüfungen= weniger Arbeit = höhere Geschwindigkeit.

So das ganze hat jetzt weniger mit dem Rendering zu tun, da ich die eingesetzten Algorithmen nicht kenne. Aber die "empfohlenen" Bedingungen lassen den Schluß nahe das ein Algorithmus mit ähnlichem Prinzip verwendet wird.

Verschiedene GPU's können auch verschiedene "Empfehlungen" haben. Das mit dem "Hoch-Zwei" beinhaltet sozusagen alle. Oft reicht ein Teilbar durch 8, manchmal ein geradzahlig. Aber das ist halt von GPU zu GPU verschieden.
Quadratische Texturen werden glaube ich schon seit sehr langer Zeit nicht mehr verlangt.

Es gibt auch rein praktische Gründe von vornherein die Texturen wie verlangt zu gestalten:
Die BGE konvertiert die Textur auf die verlangten Maße während des Ladens. Das ist zwar ein bequemer Service, kann aber ganz schnell zu unerwünscht veränderten Texturen führen. Automatismus führt halt nicht immer zum gewünschten Ergebnis.

Wenn Du meinst Du verschwendest Texturspeicher, dann kannst Du auch:
A) den restlichen Platz mit einem anderen Motiv füllen
B) mehrere kleinere Texturen verwenden (ist wahrscheinlich dann nicht mehr ganz so effizient)

Nun zumindest ist das mein Verständnis bei diesem Thema.
Monster

[ecto111]

Erstmal vielen Dank.
Eure Aussagen bestätigen, was ich mir schon grob vorgestellt hatte.

Ein Wort noch zu den "Textur-Atlanten", die Monster vorgeschlagen hat, um den "verschwendeten" Platz zu nutzen: Ich habe leider immer wieder die Erfahrung gemacht, das bei so einem Atlas durch das Mipmapping unschöne Artefakte am Rand der Texturen entstehen.

Grüße,
ecto

[Doc Holiday]

Danke Monster. Sehr aufschlussreich.

[Monster]

Danke Doc

Nun Mipmapping ist ja was anderes.
Details zum Mipmapping werden bei Wikipedia gut beschrieben. Die BGE unterstützt ja leider nur das automatische Mipmapping. Dabei wird eben immer das gleiche Verfahren angewendet.
Das automatische Mipmapping (eingebaut in OpenGL) halt so eine Art "Weichzeichnen" um
- Moiré-Muster zu vermeiden
- abrupte Übergänge beim Wechsel auf höher/niedriger detailierte Texturen zu vermeiden.

Nun muß man wissen wie in etwa dieser "Weichzeichen-Filter" funktioniert. Die Farbe eines Model-Pixels (X,Y,Z) wird berechnet aus der Farbe des Textur-Pixels (U,V) an genau dieser Stelle kombiniert (Filter) mit den benachbarten Textur-Pixeln. Je mehr Nachbarn hinzugezogen werden, desto weicher erscheint die Textur auf dem Model. Wie und wieviele Textur-pixel verwendet werden hängt vom Filter ab. Bei der BGE-haben wir leider nur einen Algorithmus auf alles oder keine Filterung auch auf alles.

Das an sich ist noch kein Problem, aber wir wissen jetzt dass aus einer Textur auch die umliegenden Textur-Pixel verwendet werden. Betrachten wir uns mal den Rand eines UV-Netzes näher:

Nimmt man ein Text-Pixel vom Rand, dann sieht man, dass nicht alle Nachbarn zum UV-Netz gehören. Läßt man diese Bereiche Blau dann mischt sich genau dieses Blau in die Farbe der Textur-Pixel am Rand = Unerwünschte Ränder.


Wie kann man das vermeiden?
A)
Man erzeugt sogenannte UV-Inseln. Die verschiedenen UV-Netze schließen nicht direkt aneinander an, sondern halten Abstand zueinander. Die Texturen werden über das UV-Netz hinaus belegt. Dabei reicht es in der Regel, die Textur am Außenrand eines UV_Netzes zu duplizieren.
Diese Methode ist recht sicher, aber sie "verschwendet" scheinbar auch Platz, da ja nicht alle Textur-pixel innerhalb der UV-Netze liegen

B) Platziere Texturen für verscheidene UV-Netze so nebeneinander, dass sehr geringe Kontrast und Farbunterschiede an den Kontaktlinien entstehen.
Z.B. Bei Skymaps, ZiegelWänden etc.
Diese Methode erfordert etwas mehr Geschick beim UV-Mapping ist auch sicher solange die Unterschiede klein bleiben und die Textur nicht mehr geändert werden soll. Außerdem kann man damit 100% der Textur verwenden.

Sonderfall: Texturrand
Der Texturrand ist ein Sonderfall. Auch hier wurden schon Probleme berichtet.
Wenn ein UV-Map direkt an den Rand einer Textur stößt gehören auch Textur-Pixel auf der gegenüberliegenden Seite zu den benachbarten Textur-Pixeln (sogenanntes Wrapping).
Das fällt nicht gleich auf, da diese Pixel für uns eben nicht nebeneinander liegen.

[Edit: falsche Pfeile korrigiert]
Lösungen wie oben.

Klassische Antwort: Rücke mit Deinem UV-Netz von den Rändern ab.

Evtl. kann man Textur-Wrapping über Textureinstellungen abstellen, aber das habe ich nicht untersucht. Das ist übrigens ziemlich nützlich bei "endlosen" Texturen.

[edit:] Laut Wikipedia werden Textur-Pixel auch Texel genannt. Aber ich lass das mal so.

[ecto111]

Sehr erfreulich, wie viel Mühe du dir mit deinen Antworten machst, vielen Dank dafür.
Alles fein säuberlich aufgelistet und gut verständlich. (Sogar mit Bildern! )

Grüße,
ecto