[C#] Scenegraph (DAG), Materials en HLSL

[Mischa_NL]

Ik ben maar eens gedoken in engine design en dergelijke. En de scenegraph is toch wel een wezelijk belangrijk gedeelte van de rendering engine! Daarom ben ik begonnen met deze in elkaar te zetten.

De scenegraph is een Tree waarin elke node slechts 1 parent kan hebben. BEHALVE een geometrie node, die kan meerdere parents hebben ivm instancing.

Er zijn op dit moment een aantal simpele TreeNodes (die allemaal iSceneGraphNode implementen):
Root - root node, doet niks interessants (internal class)
Transformation - past de world matrix aan.
Material - class met daarin de effect file en paramaters
Renderstate - culling, wireframe, zbuffer enzovoort
Geometry - Node met mesh, NIET instancable
InstancableGeometry - Instance Mesh!

Bij het traversen wordt state uit deze nodes automatisch overgegeven. Plaats je bijvoorbeeld een material recht onder de root, dan worden alle meshes volgens die material gerendert.
Objecten worden aan andere nodes gehangen (node.Append(new_node)), en inheriten de complete traversal state van de parent!

Dit werkt allemaal prachtig! Het is nu al mogelijk om bijvoorbeeld 2 objecten te renderen en dmv een renderstate node de ene in wire en de andere als solid te renderen.


Nou komt het: de material class is een placeholder, slechts een class met daarin een Effect.
Het idee is als volgt: Een heleboel kleine functies in aparte txt files (bv doWorldTransform, doTexFetch, etc), die je in een programma alá een tree (input naar output weer naar input etc) kunt koppelen. Dit programma knalt er vervolgens een fx file uit die je in de engine kunt gebruiken, ook genereert hij in een xml file de 'material container'. een stukkie xml waarin de parameters, type en effect path staan.

Een andere (static) class kent dan materials toe aan nodes: een node geeft aan welke functies hij wil hebben (bv Phong etc) in de effect file en de class zoekt op of dit mogelijk is en returnt de effect.


Maar het probleem is: als je dit bekijkt, dan lijkt het makkelijker om het anders te doen: maak een simpele material creater. Je knalt in die creator wat je wilt hebben: bv phong, 2 textures etc, en deze generate on the fly een fx (of haalt hem uit cache van schijf op).

Toch lijkt het me dat dit systeem minder robuust is dan het eerste. Het 2e systeem is beperkt daar je in de source moet gaan aanpassen als je echt nieuwe functietjes bijschrijft (de material creater weet namelijk niet wat hij ermee moet). Maar, het is denk ik veel makkelijker implementeren...
Ik ben zeer in dubio en neig zelf eerlijk gezegd naar optie 1, wat waarschijnlijk weken werk is. Daarom ben ik benieuwd wat anderen ervan vinden, voordat ik iets zeer stoms doe en weken verspil!

[roy-t]

Kun je nog iets meer uitleg geven over je eerste idee, het wordt mij nog niet helemaal duidelijk. Wil je het nu in code doen, of nieuwe technieken inlezen van txt files en parsen? Gebruik je trouwens C#+MDX of C#/XNA? (Mocht het XNA zijn, dan kan ik inhoudelijker wat zinnigers zeggen).

[ Voor 13% gewijzigd door roy-t op 11-06-2010 16:26 ]

[Laurens-R]

Is dit niet meer een SE&A topic, gezien het feit dat het meer om een globale aanpak/architectuur gaat ipv een specifieke implementatie?

[Mischa_NL]

roy-t schreef op vrijdag 11 juni 2010 @ 16:26:
Kun je nog iets meer uitleg geven over je eerste idee, het wordt mij nog niet helemaal duidelijk. Wil je het nu in code doen, of nieuwe technieken inlezen van txt files en parsen? Gebruik je trouwens C#+MDX of C#/XNA? (Mocht het XNA zijn, dan kan ik inhoudelijker wat zinnigers zeggen).

Het is XNA, maar dat doet er vrij weinig toe. Beide hebben volgens mij wel een Effect.CompileFromFile.
Maargoed, Mijn eerste idee was wat uitgebreider als volgt:

Ik maak een subprogramma voor developers, die daarin 'shader fragments' (losse text files met daarin implementaties) kunnen combineren door middel van het slepen vanuit een menu naar een 'boom/tree'.

Hier een zeeer abstract voorbeeld:


Deze parsed dan vervolgens deze tree naar een effect file, en de info die de shader nodig heeft wordt in een xml file gezet. Die xml file wordt door een material class (of hoe je hem ook wilt noemen) ingeladen als een game/de engine start. Deze leest dan alle materials in en aan de hand van hoe die material in de xml gedefinieert is levert deze een soort van interface (en hoe ik dit precies wil doen weet ik nog niet) aan de engine. Een Material node gebruikt dus deze interface als volgt. Als de scenegraph gaat renderen past hij die material dus toe.
Wat ik extra kan doen is een soort selecter maken nadat ik verschillende materials gecreate heb met bv alleen een verschillende lighting: een static class kiest op basis van input parameters een material uit (phong, blinnphong, oren nayer, etc)

Tis moeilijk uit te leggen, maar ik hoop dat het zo al iets duidelijker is. Het probleem hiermee lijkt alleen dat ik elk material zelf moet maken. Een extra helper class zou er dan voor moeten zorgen dat base lighting bv ook automatisch gegenereerd kan worden. Tis meer de bedoeling dat die tool een extra is waarbij je ingewikkeldere shaders (en dus materials) visueel kunt bouwen!


Scenegraph voorbeeld:


Scenegraph Design:

EvilB2k schreef op vrijdag 11 juni 2010 @ 16:39:
Is dit niet meer een SE&A topic, gezien het feit dat het meer om een globale aanpak/architectuur gaat ipv een specifieke implementatie?

Hmmm. Ik weet het niet. Er zullen over de implementatie ook nog wel vragen komen. Dus imho kan hij wel hier blijven staan.

[roy-t]

Ah nu snap ik het een stuk beter. Ik neig ook naar optie 1. Dit is veel dynamischer en zit veel meer 'buiten de code'. Het is nu inderdaad wel veel werk, maar het maakt een editor veel dynamischer, het lijkt een beetje op het idee van de material editor in sommige 3D modelleer pakketten, alleen weet ik niet of daar wat over te vinden is qua achtergrond, misschien dat blender ook zo'n material editor heeft, daar kun je natuurlijk wel wat spieken.