In meiner Szene befindet sich ein Level mit 64x64 Stücken. Jedes Stück hat evtl noch 2 Wände. Isometrische Ansicht.
Jedes Stück könnte eine andere Textur haben, genau wie dessen Wände.
Wenn ich die Szene iterativ durchlaufe entstehen deswegen sehr viele Texturwechsel. Im schlimmsten Fall wird bei jedem der 1024 Stücke 3mal die Textur gewechselt.

Im Moment behelfe ich mir damit, dass ich die Szene mehrfach durchlaufe und gleiche Texturen/Stücke in eine Displayliste filtere.


Habe auch schonmal daran gedacht alle Texturen in eine sehr große Textur zu packen und allein durch die Texturkoordinaten an die bunten Bildchen zu kommen. Damit hätte ich dann jeglichen Texturwechsel gespart.

Haltet ihr das für sinnvoll oder hat jemand eine Idee die Sache anders zu lösen?

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Ein textur atlas funktioniert nur mit einschränkungen, besonders an den übergängen zwischen den kacheln kommt es zu hässlichen Artefakten. Eine lösung ist es einen großzügigen rahmen drum herum stehen zu lassen, was aber damit ende das man die gleiche texture quasi 4x im Atlas hat. Deutlich sauberere geht es mit 2DArray texturen aber eine shader Model4.0 karte für eine isometrische engine zu verlangen wäre eindeutig overkill.

Bei einer isometrischen engine kann man das rendering teilweise dadurch beschleunigen, in dem die isometrisch tiles schon vorgerendert sind. Das bild muss dann nur noch von oben nach unten gerendert werden.

_________________
Lumina plattform unabhängige GLSL IDE

Also, wenn du es schaffst, alle deine Tiles in 512x512 Texturen unterzubringen ist das nicht schlecht. Bedenke aber, dass du um jedes Tile einen Rand von 1px halten musst, den du mit den Pixeldaten der jeweils anderen Seite füllst, damit es beim Linearen Filtering keine Probleme gibt.

Ansonsten ist das sortieren nach Textur schonmal kein schlechter Ansatz, am besten ist es, wenn du dafür sorgen kannst, dass die Tiles sobald sie in den Frustum kommen bzw erstellt werden sofort in der richtigen Liste landen, was das sortieren in jedem Frame erspart. Ich würde hierbei keine Displaylisten verwenden, da sie beim erstellen zu viel Zeit brauchen und je nach dem, wie oft Tiles sichtbar werden bzw versteckt werden, kann das die Performance mehr drücken, als die vielen Texturwechsel.

Die beste Performance würdest du wohl mit einem VBO rausholen, aber das ist auch wieder eine Sache mit den Anforderungen für eine 2D-Engine.

//Edit: Am besten ist natürlich eine Kombination aus der ersten (Texturatlas) und der zweiten (Sortieren nach Textur) Methode, falls du deine Texturen nicht alle in eine 512x512 bekommst. Wenn du dann auch noch beim erstellen der Texturatlanten auf eine gute logische Ordnung achtest (also möglichst keine Tiles, die niemals in einem Screen vorkommen in eine Textur, es sei denn, du müsstest sonst eine neue Anfangen) gibts glaube ich nicht mehr viel zu optimieren.

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

Erstmal Danke für eure Antworten.

Also bislang bin ich mit den Bildern pro Sekunde noch zufrieden.
Um die Sache mit der Isometrie mal etwas klarer zu machen hab ich mal nen Screenshot angehangen.
Im Moment ist erstmal eine feste Kamerablickrichtung vorgesehen. Kann sich evtl. noch in Richtung einer Shooter-ähnlichen 'überdieschulter'-Ansicht ändern.

Die hässlichen Artefakte bzw. Übergänge mit dem Texturatlas hatte ich schon befürchtet.

Ich werde es mit dem Atlas mal ausprobieren wie schlimm das wird.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Das is ja keine Isometrie sondern Perspektive. Also, wenn du den Atlas machst, sorg wie gesagt dafür, dass die "Kerntextur" noch einmal umrandet ist, und zwar mit der jeweils gegenüberliegenden Seite, damit du keine Artefakte bekommst.

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

Wenn du mipmaps verwendest kann es sein, dass 1px Rand nicht ausreicht.

_________________

Guter hinweis, das hätte ich jetzt übersehen. Also, wenn du Mipmaps verwendest musst du die Textur tatsächlich 9x (oder weniger?) drin haben, um fehler zu vermeiden und da wirds dann langsam auch unschön...

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

Ich werde das mit dem Atlas lassen. Das Sortieren der Texturen/Flächen klappt prima.

Und mittlerweile kriegen die Quads auch nasse Füße s.o.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next