OpenGL render state beheer?

[Verwijderd]

Hallo!

Op dit moment ben ik als hobbyprojectje aan het werk aan een eenvoudig spelletje voor de iPhone, en ben bezig de 3d engine-in-wording die ik voor de Mac gemaakt heb te porten naar de iPhone. Dit gaat redelijk voorspoedig en alle functionaliteit van de engine die ik al had draait nu op de iPhone. Dit was nog niet zo veel, maar de basics zitten er ik; resource beheer, een scene graph en een constructie om objecten te kunnen bewegen en animeren enzo... Allemaal prima.

Hier is een screenshot van hoe het er nu uit ziet: http://emle.nl/forumpics/site/planes_grid.png. Het vliegtuigje heeft niets te maken met 't spelletje wat ik maak, maar is een ideaal testobjectje voor de 3d engine en de ondersteunende functionaliteit...

Nu ben ik zo ver dat ik na moet gaan denken over materialen; de beschrijving welke textures, lichten, etc horen bij een 'renderable', een zichtbaar 3d object. Dit komt in de praktijk neer op een heleboel OpenGL *ClientState en glEnable/glDisable calls, waarvan sommige best duur zijn om aan te roepen. Wat is een handige manier om dit te minimaliseren?

Op dit moment heb ik een class genaamd RenderState waarin ik lokaal cache wat de opengl state zou moeten zijn. Zodra er een ander materiaal gekozen wordt vergelijk ik alle members van die class met het nieuwe materiaal en voer alleen de state changes door die nodig zijn voor het nieuwe materiaal. Dit werkt nu aardig, maar ik ben bang dat het de potentie heeft een beetje uit de hand te lopen als de engine groeit en er meer en meer state onthouden moet worden... Help?

[Woy]

Kun je niet gewoon je objecten sorteren aan de hand van de RenderState's die je hebt? Je kunt dan de volgorde van renderen gewoon af laten hangen van objecten die veel overeenkomstige RenderState's hebben.

[Zoijar]

Je kan ook state changes minimaliseren door dingen als textures atlassen en pseudo-instancing te gebruiken, i.e. een enkele textures die door meerdere objecten wordt gebruikt, en een enkele VBO waar meerdere objecten in gedefineerd staan.

OpenGL 3+ werkt trouwens iets anders; daar heb je nu al wat meer mogelijkheden en in de toekomst waarschijnlijk een ander state model. Ik zou niet al te veel tijd besteden aan een OpenGL 2 engine to optimaliseren.

[.oisyn]

Woy schreef op woensdag 15 juli 2009 @ 12:32:
Kun je niet gewoon je objecten sorteren aan de hand van de RenderState's die je hebt? Je kunt dan de volgorde van renderen gewoon af laten hangen van objecten die veel overeenkomstige RenderState's hebben.

Dit is idd wat gebruikelijk is. Sowieso wil je ook sorteren op render targets (doet vrijwel iedereen impliciet al), vertex/indes buffers en textures.

[Gorion3]

Sorteren op textures (erg duur op de iphone! sowieso meestal duur..) raad ik sowieso aan. Daarnaast heb je misschien een handmatige draworder waarop je kan sorteren. Verder valt het wel mee, vanuit gaan dat al je objecten lighting hebben en depth test gebruiken..

Zoijar schreef op woensdag 15 juli 2009 @ 12:45:
Je kan ook state changes minimaliseren door dingen als textures atlassen en pseudo-instancing te gebruiken, i.e. een enkele textures die door meerdere objecten wordt gebruikt, en een enkele VBO waar meerdere objecten in gedefineerd staan.

OpenGL 3+ werkt trouwens iets anders; daar heb je nu al wat meer mogelijkheden en in de toekomst waarschijnlijk een ander state model. Ik zou niet al te veel tijd besteden aan een OpenGL 2 engine to optimaliseren.

Tja, OpenGL 3 is wel leuk en aardig, maar de iphone ondersteund dacht ik maar net OpenGL ES 2.x. En dan nog niet eens alle features

[ Voor 60% gewijzigd door Gorion3 op 16-07-2009 21:23 ]

[ZpAz]

Tja, OpenGL 3 is wel leuk en aardig, maar de iphone ondersteund dacht ik maar net OpenGL ES 2.x. En dan nog niet eens alle features

Dat geld volgens mij idd voor de 3GS, de 3G zit op 1.1 ofzo als ik me niet vergis. Maar toch wel vrij logisch dat een mobiele device niet alle features ondersteund van een volwaardige desktop.

[Verwijderd]

Tot dusver bedankt voor alle antwoorden. De meeste gaan in de richting waarin ik zelf al aan het programmeren was geslagen, dus het is goed dat bevestigd te zien. Dat texturewissels duur zijn kwam ik al bij de eerste ronde profiling achter. Wellicht dat alleen sorteren op textures al voldoende is om de performance goed genoeg te houden.

De iPhone doet inderdaad alleen maar OpenGL ES 1.1 op de 3G en 2.0 op de 3GS. Aangezien ik alleen een 3G heb beperk ik me voorlopig even daartoe...