[3D/OpenGL] Structuur voor renderen met blending

[phaas]

In mijn prog worden te renderen object opgeslagen in een boom-structuur waarbij elk object een willekeurig aantal child-objecten kan hebben. De uiteindelijke lokatie in het 3D-veld van een object is relatief van de lokatie van het parent-object, mits aanwezig.

Objecten kunnen verschillende 'draw-typen' hebben dat bepaalt hoe het object gerenderd wordt, oa:
• Sprite - sprite of billboard dat altijd recht naar de camera kijkt. Een sprite kan een alpha-mask hebben, maar geen alpha-transparantie.
• Particle - een sprite, maar dan mèt mogelijkheid voor een texture met alpha-transparantie
• Mesh - een model/mesh met evt. een apart materiaal en texture voor elke face, evt. een willekeurig aan faces met alpha-transparantie

Renderen is natuurlijk mogelijk door de lijst met objecten door te lopen (nadat frustum culling is toegepast) en bij elk object de lijst met diens child-objecten, en diens child-objecten etc...
Het probleem is alleen dat het van belang is dat alle objecten/faces ZONDER alpha-transparantie eerst worden gerenderd ivm. de Z-buffer.
Op deze manier zou de lijst dus elk frame twee keer doorgewandeld moeten worden.
Het wordt nog erger als sommige faces meerdere keren moeten worden gerenderd voor multi-pass texturing.

Heeft iemand een idee om mijn lijst-gebeuren te optimaliseren? Hoe wordt dit gedaan in bv. een game-engine?
Een aantal ideeën die ik had:
• Bij alle mesh-object de mesh opdelen in twee delen: faces mèt en zonder alpha-transp. En deze als vertexarrays gebruiken
• Frustum-culling maakt de lijst natuurlijk al een stuk kleiner


Dank!

[Zoijar]

Twee lijsten is wel een idee. Transparante objecten moet je toch heel specifiek renderen, je moet ze ook eerste sorteren op diepte. Of je kan trucks gebruiken, zoals bv. screendoor transparancy met een blending (image space) pass...of een van de vele andere technieken bv depth slicing dat pixel perfecte transparantie geeft maar weer erg duur is. (depth slicing is wel meteen ook weer extreem handig bij schaduw generatie technieken zoals shadow mapping, en zelfs bij vormen van radiosity.. jammer dat het nogal duur is...)

[ Voor 21% gewijzigd door Zoijar op 28-06-2005 17:49 ]

[quistnet]

volgens mij is het zelfs sorteren op diepte afhankelijk van camerapositie,
normale z-as sortering werkt niet (behalve als camera statisch is natuurlijk )

en dan zou je dus per rendermoment (of liefst alleen bij individuele object- en camera- veranderingen) de diagonale afstand tot de camera moeten berekenen voor ieder object, en die dan weer sorteren (direct of later pas).

edit:

oh en per face/triangle zelfs, niet alleen het object

verder heb ik nogsteeds geen idee hoe dit geregeld is in andere engines, weet wel dat het meestal iig minimaal met 2 loops gaat, eerst de solids, daarna de doorzichtigen renderen.

[ Voor 7% gewijzigd door quistnet op 28-06-2005 18:23 ]

[Zoijar]

Je kan eerst je solids renderen; de depth buffer freezen, en dan ga je als je transparents renderen alsof het solid zijn. De resulterende depth buffer sla je op als texture, vervolgens ga je opnieuw al je transparents renderen alsof het solids zijn, maar ZONDER de depth buffer te resetten. Zo krijg je steeds een nieuw 'laagje'. Bij een bol komt bv eerst de zichtbare voorkant in de depth buffer, en daarna de (onzichtbare) achterkant. Meestal stop je met render passes als er slechts een bepaald percentage van alle depth samples nog maar veranderd (of tot dat getal 0 is voor perfectie). Nu kan je daarna al die 'depth buffers' renderen als screen quads in de goede volgorde. Pixel perfecte transparantie. (en die screenquads dus op de juiste, order dependent, manier blenden)

[ Voor 7% gewijzigd door Zoijar op 28-06-2005 18:45 ]

[phaas]

Volgens mij denken jullie te moeilijk.... Het maakt toch niet uit in welke volgorde ik de transparante faces render? Zolang ze iig maar ná de solids zijn en met een depth-buffer mask/freeze.
Als je bv. stukken doorzichtig gekleurd papier op elkaar legt, maakt het toch in weze ook niet uit in welke volgorde je dit doet, want het resultaat blijft hetzelfde.... Tenzij je natuurlijk andere manieren blending gaat gebruiken als multiple, substract etc.

[Zoijar]

Nee, de standaard formule voor alpha blending is A*src + (1-A)*dst, en die vergelijking is order dependent. Alleen als je ipv 1-A een factor 1 gebruikt is dat niet zo, maar dat ziet er weer vreemd uit. Je moet dus back-to-front renderen. Je kan je objecten sorteren, maar dan heb je kans dat delen van die objecten overlappen. Dus dan ga je je faces sorteren, maar dan blijken er twee faces elkaar te snijden... goede pixel perfecte transparantie, zonder eisen aan de mesh, kan je alleen bereiken met technieken zoals dus depth peeling (sorry dat ik eerst slicing zei, ik was even in de war met volume rendering) of...ray tracing...

[phaas]

Oké, ik snap wat je bedoelt. Helaas is moet mijn prog te draaien zijn op low-end hardware en gaat het bovenstaande mij zoieso een beetje te ver
In welk opzicht gaat die manier met factor 1 er trouwens raar uitzien? Zou het voor een low-end toepassing misschien toch bruikbaar zijn?

[Zoijar]

Je kan het proberen, en kijken of je het acceptabel vindt. Wat je verder kan doen is gewoon je objecten sorteren, en de fouten die optreden voor lief nemen. Als je objecten ver uit elkaar liggen, en de bounding boxes niet snijden is er sowieso geen probleem met deze methode. Dus eis simpelweg dat bounding boxes (of spheres, etc) niet overlappen. (er zijn nog wel gevallen die fout gaan...het bekende 'hekje' bv, waar je niet vast kan stellen welk object voor welk ligt, omdat ze allemaal zowel voor als achter elkaar liggen. Dat soort dingen...die fouten moet je dan maar voor lief nemen bedoelde ik)

Een andere manier is om in een soort van 'schaak' patroon the renderen, door pixels weg telaten. Dan krijg je het effect dat de objecten niet echt transparant zijn, maar een soort roosters. Alsof je door een hor voor een raam kijkt. Als je dat nog nabewerkt met wat blending kan je ook een redelijke benadering krijgen.

[ Voor 18% gewijzigd door Zoijar op 28-06-2005 20:34 ]

[.oisyn]

Het per frame sorteren van alphablended polygonen is de normaalste zaak van de wereld, everybody's doing it . Wij deferren zelf sowieso alle render calls die op de renderer gedaan worden, er zijn heel wat passes die doorgelopen moeten worden aangezien we materials ondersteunen met heel wat lagen, en ook aan realtime dynamic lighting doen. En als je dat allemaal efficient wil doen dan moet je zorgen dat je zo weinig mogelijk statechanges doet tussen drawprimitive calls (dus: sorteren op dingen als texture, shader en vertexbuffer). In principe wordt het daadwerkelijke renderen pas gedaan aan het eind van de frame als de scenemanagere langs alle objecten gewandeld heeft en de nodige culling gedaan heeft, en de renderer zelf alle objecten mooi per pass gesorteerd in een lijstje heeft staan.

[ Voor 22% gewijzigd door .oisyn op 29-06-2005 11:54 ]