PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Probleme bei Entwicklung eines Scene-Graph (Beleuchtung)


Nasenbaer
2010-08-19, 08:49:51
Hi,
meine neuestes Projekt soll eine kleine 3D-Engine sein - vornehmlich um die dahinter steckenden Mechanismen mal selbst umgesetzt zu haben. Angefangen habe ich dazu nun mit der Entwicklung eines Scene-Graph. Meine Idee ist, es das ganze als Engine für DX >= 10 zu entwickeln, weswegen es für jeden Mesh-Knoten möglich sein soll, sämtliche Shader selbst zu setzen.

Jetzt habe ich aber das Problem, dass ja seit DX10 Lichtquellen direkt in den Shadern behandelt werden müssen und DX dazu keine speziellen Funktionen mehr liefert. Wenn ein Mesh aber nun einen eigenen Pixel Shader setzt, wie kann ich dann dafür sorgen, dass die Lichtquelle, die ja in einem separaten Knoten gespeichert ist, dennoch für die Berechnung der Beleuchtung herangezogen wird? Dazu habe ich mir zwei Lösungen ausgedacht:

Designrichtlinien für PixelShader festlegen, sodass immer eine spezielle Datenstruktur gebunden wird in der Lichtquellen Infos für den zu rendernden Mesh enthalten sind.
Rendering grundsätzlich in mehreren Passes. Pass 1 rendert mit Mesh-gebundenem Pixel-Shader, Pass 2 berechnet die Szene nochmals mit einem einheitlichen Beleuchtungs-Pixelshader unter Berücksichtung der Lichtquellen und am Ende werden die beiden Ergebnisse per geeignetem Blending kombiniert.


Lösung 1 schränkt natürlich die Entwicklung der PixelShader an bzw. für eine korrekte Szenendarstellung muss man sich strikt an die Vorgaben halten. Zudem ist es nicht ohne weiteres möglich speziellen Lichtquelleneffekte unabhängig vom Pixelshader des Objektes vorzunehmen.
Lösung 2 benötigt grundsätzlich mindestens 2 Passes wodurch sich der Rechenaufwand natürlich erhöht, auch wenn man im 2. Pass vielleicht nur die Beleuchtung berechnet und im 1. nur die Texturierung - die Geometrie wird dennoch doppelt angefasst.

Hat jemand vielleicht eine bessere Idee oder vielleicht auch nur einen Tipp, denn beide Lösungen gefallen mir nicht so wirklich.

Neomi
2010-08-19, 10:45:59
So oder so mußt du bei den Shadern ein paar Konventionen herausarbeiten und dich daran halten. In deinem 2. Ansatz (Deferred Shading) ist das eben, daß du die Diffuse-Farbe rausrenderst, für wirklich brauchbare Ergebnisse brauchst du dann auch noch Specular, Specular Power, Screenspace-Normalen und und und. Aber wo soll da das Problem sein? Für Shader gibt es Hochsprachen, mit denen du die gemeinsamen Teile in einen gemeinsamen Header auslagern kannst.

Beide Ansätze haben jedenfalls ihre eigenen Nachteile. Beim Immediate Shading hast du eine begrenzte Anzahl an Lichtquellen pro DrawCall. Beim Deferred Shading brauchst du mehrere Buffer für alle materialabhängigen Beleuchtungsparameter und hast Probleme mit transparenten Flächen (die müßten in einem weiteren Pass nachträglich mit Immediate Shading drübergerechnet werden).

Das wichtigste ist erstmal, zu spezifizieren, was dein Scenegraph überhaupt können soll.

Nasenbaer
2010-08-19, 16:47:32
So oder so mußt du bei den Shadern ein paar Konventionen herausarbeiten und dich daran halten. In deinem 2. Ansatz (Deferred Shading) ist das eben, daß du die Diffuse-Farbe rausrenderst, für wirklich brauchbare Ergebnisse brauchst du dann auch noch Specular, Specular Power, Screenspace-Normalen und und und. Aber wo soll da das Problem sein? Für Shader gibt es Hochsprachen, mit denen du die gemeinsamen Teile in einen gemeinsamen Header auslagern kannst.

Stimmt, da hatte ich gar nicht dran gedacht. Arbeite noch nicht solange mit Shadern.
Ich werde dann wohl erstmal die Immediate Variante versuchen, da der deffered-Ansatz etwas komplexer ist und ich mir nicht gleich zu viel aufbürden möchte.


Das wichtigste ist erstmal, zu spezifizieren, was dein Scenegraph überhaupt können soll.
Wichtig ist mir in erster Linie, dass die Möglichkeiten, die mir DirectX bietet so wenig wie möglich eingeschränkt sind - darum sollen halt auch alle Shader-Stages durch die Mesh-Knoten steuerbar sein. Ich wills in erste Linie als ein etwas komplexerer D3D-Framework nutzen um mir bestimmte Techniken anzueignen (Schatten, HDR, Wasserrendering, usw.).

Naja und neben Mesh- und Terrain-Knoten für HeightMaps, soll's sonst nur noch nen Licht-Knoten und natürlich Kamera, Group, usw. geben.
Es soll also eine recht simple Umsetzung werden - wobei mir erstmal nur die Basics wichtig sind, wie ein einfaches BVH, Sortieren nach StateSwitches, FileManagement damit man den Graph nicht hardcoden muss ^^ und sowas halt.
Da ich bisher nur mal ein wenig OpenSceneGraph genutzt habe fehlt mir halt noch der Weitblick um entsprechend konkrete Festlegungen im Vorfeld vorzunehmen.

Demirug
2010-08-19, 18:33:20
Du bist dir aber schon bewusst das solche Scenegraphs bei denen man alles einfach in einen Graphen packt ziemlich aus der Mode gekommen sind?

Nasenbaer
2010-08-19, 18:40:40
Du bist dir aber schon bewusst das solche Scenegraphs bei denen man alles einfach in einen Graphen packt ziemlich aus der Mode gekommen sind?
Öhm nö das ist mir neu - ich dachte jede größere Engine würde darauf basieren. :)
Hielt das Konzept eigentlich immer für recht sinnvoll.

Wie organisiert man das denn mittlerweile?

Demirug
2010-08-19, 18:59:36
Man setzt auf mehrere parallel Datencontainer (in der Regel auf schnelle räumliche Suche optimiert) für die unterschiedlichen Objektetypen. Also mindesten einen für Lichtquellen und einen für Geometrie. Wir haben zum Beispiel auch noch einen für Windquellen um für jedes Objekt bei Bedarf die Windrichtung und stärke zu bestimmen.

Dann gibt es ein Rendermodul welches an diese Container entsprechenden Suchanfragen (Objekte im Frustum) stellt. Diese reduzierten Objektmengen werden dann gemerged. Also zum Beispiel für jedes Objekt die x wichtigsten Lichtquellen gesucht usw. Dann wandelt man das Ganze in eine Liste mit Draw Operationen um. Diese wird dann noch sortiert und schließlich zur Ausführung gebracht.

Nasenbaer
2010-08-19, 19:07:32
Hmm ok, das klingt eigentlich ganz gut.
Und verzichtet man dann auf die Möglichkeiten bei der Animationen, die einem die SceneGraph-Struktur bietet? Also Objekt x bewegt sich in Relation zum Vater-Knoten.

Demirug
2010-08-19, 19:37:10
Ich nehme mal an du meinst jetzt keine Skelet Animationen sondern eher solche Sachen das ein Objekt eine Lichtquelle hinter sich herzieht.

Das ganze wird so gelöst das jedes Objekt eine Liste mit verbundenen Objekten enthält. Kommt es nun zu einer Änderung werden alle verbundenen Objekte informiert. Diese wiederum enthalten ein Link Objekt welches auf die Masterobjekte verweist. Der einfachste Linktype übernimmt dabei einfach die Koordinaten des Masters. Man kann sich aber auch Links schreiben welche zum Beispiel die Position bestimmen welche die günstigste Position zu mehren Mastern einnimmt. Auch Zeitverzögerungen lassen sich realisieren. Dafür braucht man dann noch ein zusätzliches Zeitevent System.

Nasenbaer
2010-08-19, 20:39:04
Ich nehme mal an du meinst jetzt keine Skelet Animationen sondern eher solche Sachen das ein Objekt eine Lichtquelle hinter sich herzieht.

Das ganze wird so gelöst das jedes Objekt eine Liste mit verbundenen Objekten enthält. Kommt es nun zu einer Änderung werden alle verbundenen Objekte informiert. Diese wiederum enthalten ein Link Objekt welches auf die Masterobjekte verweist. Der einfachste Linktype übernimmt dabei einfach die Koordinaten des Masters. Man kann sich aber auch Links schreiben welche zum Beispiel die Position bestimmen welche die günstigste Position zu mehren Mastern einnimmt. Auch Zeitverzögerungen lassen sich realisieren. Dafür braucht man dann noch ein zusätzliches Zeitevent System.
Danke erstmal für die Infos. Klingt alles ziemlich durchdacht - EA Phenomic ist ja auch keine 08/15-Softwareklitsche. ^^
Ist aber natürlich auch etwas aufwändiger in der Umsetzung - ein Scenegraph ist en simpler DAG, bei räumlicher Suche denke ich mal, dass sowas wie Kd-Tree, BSP-Tree oder was ähnliches genutzt wird und das macht schon etwas mehr Arbeit.
Ich denke mal ich werde erstmal trotzdem nen einfachen ScreenGraph umsetzen aber die Interfaces so konzipieren, dass man auch andere Strukturen zur Sortierung nutzen kann. OGRE bietet laut Feature-List soetwas an.