Koppelen van lights aan geometry

[Mischa_NL]

Ik ben reeds een tijdje bezig aan een game engine maar loop nu toch tegen een performance issue aan!

Alle objecten zijn opgeslagen in een scenegraph, deze graph bepaalt alleen de relatie tot andere objecten. Daarnaast zijn sommige nodes 'cullable' (geometry, lights), deze nodes worden in een spatial tree (octree) geknald.

In de octree staan dus op dit moment lichten en geometry. De tree houdt zelf bij wanneer hij moet resizen (joinen en splitten). Op de update gaatie de tree door en bepaalt welke objecten zichtbaar zijn en niet.

Vervolgens gaat de tree kijken welke lights welke geometry intersecten.
Dit doe ik door de tree door te zoeken, naar lichten.
Als ik een licht vind moet ik de bijbehorende geometry vinden.
Ik doe dit als volgt:

-check light against all objects in same node.
- check light against all parents of node
- check light against all children of node

Op deze manier vind ik alle mogelijke geometry.

Op een intersect met geometry kijk ik of light en geometry visible zijn.
Zo ja kijk ik of het licht al in de ´affectinglights´ van de geometry staat. Zo niet dan add ik hem
Bij invisibility verwijder ik hem uiteraard!

Nu lijkt dit goed, maar ik heb het idee dat dit traag is!

Zijn er misschien ervaringsdeskundigen op dit gebied die uit kunnen leggen hoe dew proffesionals )dynamic) lights en (dynamic) geometry aan elkaar koppelen?!

Opzich werkt het dus wat ik toepas, alleen is het verschrikkelijk traag door de vele checks tegenover geometry.

[Herko_ter_Horst]

Vraagje vooraf: heb je gemeten dat het traag is, of heb je alleen maar het idee dat het traag is?

[Mischa_NL]

Herko_ter_Horst schreef op donderdag 07 oktober 2010 @ 17:37:
Vraagje vooraf: heb je gemeten dat het traag is, of heb je alleen maar het idee dat het traag is?

ik heb het gemeten, exacte frametimes heb ik niet maar render / update verhouding is 5%/95%, en dat is belabberd veel.

[NC83]

Hoe test je of je een intersect hebt tussen light en Geometry, misschien zit daar een optie in om het sneller te maken.

Daarnaast zou je je intersect test met children en parents kunnen stoppen zodra je er een vindt waarmee hij niet meer intersect.

[ Voor 35% gewijzigd door NC83 op 08-10-2010 17:55 ]

[Mischa_NL]

ik heb de boel nog iets versoepeld!

Als volgt nu: zoek lights en geometry in octree

voor ieder light zoek:
- in huidige octree node
- in alle parent nodes
- in alle children nodes die daadwerkelijk met het light intersecten!

Dit zorgt dus dat het doorzoeken van childnodes nog een tikkie sneller is geworden!

Performance is oke nu! het is natuurlijk van verschillende dingen afhankelijk waarvan de belangrijkste 2 logischerwijs zijn: spacing en grootte van dingen!

te groot -> octree kan neit splitten -> veel intersection (frustum, binding) werk op cpu.
te weinig spacing -> heel veel lichten per object -> gpu loopt te hijgen!

k heb nu een kleine stap gezet richting een model importer... 'k heb reeds een paar modelletjes ingeladen op een erg 'proof of concept' achtige manier... Alleen deze modellen waren zeeer crappy... Heeft iemand (al is het er maar 1) een goed .x of .fbx model dat gerigged is? Deze kan ik for the time being via de content processor inladen namelijk (totdat ik daadwerkelijk de .x file importer schrijf).

Daarnaast vraag ik mij nog iets af:
Hoe renderen real-life apps eignelijk instanced?! De vele combinaties van lights maakt het practisch onmogelijk om ook maar 1 mesh te instancen ...

Verder ben ik ook nog steeds bezig met de material builder GUI... als deze ook af is kun je daadwerkelijk wat modellen maken, importeren, en met relatief ZEER weinig code op het scherm toveren!!

edit//
nog iets:
Modellen wil ik inladen en vervolgens in de scenegraph zetten. Het meest logische leek mij om deze niet als 'model-node' te inputten maar om meshes en bones als geometry en transformaties in de scenegraph te zetten. Is dit een gangbare approach?
Ook vraag ik me af hoe hierbij lod geregeld wordt. Lod dmv een 'switch' of 'LOD' node in de scenegraph implementen? Switch/lod node bekijkt op basis van camera distance welke lod nodig is. Logisch? of compleet niet!?

[ Voor 14% gewijzigd door Mischa_NL op 14-10-2010 19:11 ]

[Mischa_NL]

klein kickje?

[NC83]

Als je veel lichten (>8) aan het gebruiken bent is forward shading niet de manier omdat te doen en zul je naar een deferred shading over moeten stappen.
In deferred is het berekenen van lichten niet meer zo zwaar voor de GPU omdat je geen berekeningen hoeft te doen voor geometry die nooit zichtbaar is, nadeel hier van is dat je in een multipass systeem moet renderen en alle material properties naar een texture moet schrijven. Daarnaast is transparantie een probleem en zal altijd onverlicht zijn.

Je moet eens naar GPU Gems op de nvidia developer site gaan kijken om te zien hoe veel dingen werken, de deferred manier van shading die S.T.A.L.K.E.R. gebruikt is duidelijk beschreven in GPU Gems 2.

Instance rendering is niet de heilige graal het werkt perfect voor bepaalde dingen maar je moet alle parameters via een tweede vertex buffer naar je GPU sturen (Dx in ieder geval). Je hebt namelijk per instance van je geometry alle parameters nodig die verandered zijn.

[ Voor 25% gewijzigd door NC83 op 20-10-2010 00:30 ]

[Bahmi]

Dat is grappig, voor mijn huidige (school) project ben ik onze engine naar een deferred shader model aan het ombouwen.

In plaats van dat je op je CPU door allemaal octtrees aan het lopen bent moet je meer doen op je GPU. Jij bent als je eenmaal een hoop modellen op je scherm hebt duizenden intersections aan het plegen. Daardoor loopt (hoewel je na die optimalisaties het nu wel meevalt denk ik) je processor veel te veel dingen te doen die door je GPU opgelost horen te worden (daar is hij voor).

Met instancing gebruik je een model om die in batches achter elkaar te renderen, maar om die te belichten moet je een generiek belichting systeem gebruiken, of iets van een 3D radiosity map. Echte point lights zul je hier niet echt mee bereiken. Dan moet je modellen apart renderen en kun je misschien met wat simpele distance checks kijken welke lichten actief zijn. Tegenwoordig hebben mensen dikke videokaarten die geen problemen met een flinke berg polygonen hebben, dus bruteforce je het maar een beetje op de videokaart.

Zoals ik al zei ben ik de engine aan het ombouwen voor deferred shading, zodat ik in 2D de belichting bereken, ipv 3D (door niet direct naar het scherm te renderen, maar naar een aantal buffers die data zoals kleur, diepte en view-space normal map hebben). Elke pixel word dus maar 1 keer uitgerekend, in plaats van meerdere keren met overdraw.

Daardoor maakt het eigenlijk niet uit hoeveel lichten ik heb, maar hoeveel pixels elk licht op het scherm heeft. Hoe kleiner elk licht, hoe sneller het draait.

tl;dr
Allemaal belichting berekenen op de CPU slaat nergens op. Gebruik simpele distance checks om te weten welke lichten gebruikt moeten worden of lightmaps voor level geometry, plak er wat shaders op en doe het op de GPU. Wil je verder gaan, gebruik dan of deferred lighting of shadowmaps. Ligt er totaal aan wat voor type game je maakt, de ene heeft meer detail nodig dan het andere.