ZFX + Developia

Hallo ZFXler,

als neuer hier im Forum möchte ich ne kleine Vorstellung schreiben. Bin eigentlich angemeldet um ne Frage zu stellen (siehe irgendwann heute bei Grafikprogrammierung), aber damit ihr wißt mit was ihr es zu tun habt müßt ihr euch ne kleine Einleitung antun. Das ganze hier extra, weil ich den Frage-Thread clean halten wollte von unnötigen Details :-)

Wie wahrscheinlich fast jeder hier programmiere ich als Hobby ne kleine Spieleengine, d.h. etwas mehr ringsrum als nur ein Renderer. Der gesamte Code hat 3 Schichten; Kern, Engine, Spielcode. Und weils so klein ist heißt das ganze dann "Nano Engine".

Im Kern: Speichermanager zum Finden und automatischen Beseitigen von Lecks, ein paar File-Tools, Konsole, formatiere Log-Ausgabe; Containerklassen und die übliche Mathematik ( Vektoren, Matrizen, Ebenen, Quaternionen und so), Parser
Engine: Renderer, Welt-Handler ( Occlusion- und Frustum-Culling, Kollsionserkennung (Traces) ), Ressourcenbibliothek ( verwaltet Texturen, Materialien, Effekte, Modele ), Kamera, Entity-Manager, Oberflächen-Manager ( in Planung; Menüs, Fensteranzeigen )

Im großen und ganzen bilden der Renderer und die Bibliothek ein Gerüst für Deferred Shading: In einer Definitionsdatei werden Rendertargets, Materialeigenschaften, Postprocessing definiert; Materialien ordnen den möglichen Eigenschaften Werte zu und verknüpfen dies mit Effekten und Rendertargets. Dadurch kann der Engine-Anwender bestimmen, welche Werte in welchen Targets liegen, er schreibt die Shader selbst (natürlich schreibe ich auch welche, aber die kann man dann austauschen). Die Renderreihenfolge unterliegt jedoch gewissen Begrenzungen, die quasi Deferred Shading erzwingen: ein Pass für die Welt, einer für Objekte, dann die Lichter ( mit Passes für Welt und Objekte für Shadowmaps ); am Enden postprocessing laut User-Definition.

Die Definitionsdatei und Materialien werden in Pseudo-C geschrieben und zur Runtime übersetzt, Effekte sind HLSL-Effektdateien. Das heißt auch nach Compilieren des Spielcodes bleibt das Grafikgerüst flexibel; Einschränkungen finden sich bei der Benennung von Variablen, d.h. damit man eine WeltViewProjektionsmatrik o.ä. im Shader bekommt, muss man der einen bestimmten Namen zuweisen. Das ist glaube ich zu verkraften.

Screenshots gibts dann irgendwann wenn das ganze weniger Baustelle ist^^

Zukunftspläne:
- Terrain-Rendering
- Networking-/Multiplayer-Code
- persistente Server, für kleine Online-Gemeinden mit RPG-Elementen (d.h. persistente Charakterentwicklung, Inventare etc.)
- Indoor-Levelgenerator: Für instanzierte Bereichen in persistenten Welten, zufällige Generierung nach Vorgaben (Stil, Größe, Begrenzungen durch umliegende Welt etc.)

...Weil man ja mal Träumen darf. Wer bis hier gekommen ist, hat wohl echt Geduld :-)

MfG
Haiaiai

Das Konzept klingt solide. Jetzt mal abgesehen von der hirnverbrannten Idee, eigene Containerklassen schreiben zu wollen. Ein Deferred Renderer übt zunehmend Faszination auf mich aus... die schlichte Eleganz, mit der man z.B. Reliefshader bauen kann, die dann ganz automatisch auch auf Licht- und Schattenverläufe wirken, finde ich toll. Leider sind viele andere Effekte nicht so einfach damit umzusetzen... hast Du schon Ideen, wie Du z.B. CubeMap-Spiegelungen oder transparente Objekte integrieren willst? Das würde mich interessieren.

Ansonsten: Bilder her! :-)

Jetzt mal abgesehen von der hirnverbrannten Idee, eigene Containerklassen schreiben zu wollen.

Container ist vielleicht etwas falsch genannt. Im großen und ganzen sind es 2 die in der Engine viel Anwendung erfahren: Pools und Trees.

Trees sind selbstbalanzierende binäre Bäume und werden hauptsächlich als Wörterbuch verwendet, d.h. sie ordnen einem Namen, z.B. eines Materials, eine interne Struktur zu (geben also nen Zeiger darauf zurück). Da die suche binär ist spart man sich n Haufen String-Vergleiche, außerdem bietet die Klasse die Möglichkeit, den gesamten Inhalt mit Callbacks durchzulaufen, wobei auch entschieden werden kann, ob man weiter nach links und/oder weiter nach rechts in der Suchmenge geht. Das ermöglicht zum Beispiel die suche nach Wortfragmenten, bekannt aus der Auto-Vervollständigung bei einer Konsole.

Pools dienen dazu, Speicher blockweise zu reservieren und zu zerlegen. Wenn man dann für eine Struktur braucht, nimmt man den aus den Pool - kein malloc nötig. Genau so kann man Speicher wieder zurücklegen in den Pool. Wenn in den reservierten Blöcken kein Platz mehr ist, holt der Pool neuen Speicher. Wenn man ständig Elemente vernichtet und neu erstellt, z.B. Spiel-Entities, spart man sich damit Unmengen mallocs und frees. Außerdem räumt der Pool, genau wie der Tree, am Ende auf.

hast Du schon Ideen, wie Du z.B. CubeMap-Spiegelungen oder transparente Objekte integrieren willst? Das würde mich interessieren.

CubeMaps ansich lassen sich ja über Material und Effekte einbinden, das reicht für Himmelsreflektionen und Glanzeffekte. Rendern in CubeMaps habe ich im Moment noch nicht vorgesehen, aber auch nicht abgelehnt. Spiegel und Portaleffekte sollen später möglich sein durch Kamerarotation und ein vollständigen Rendervorgang (außer PP) in eine Zwischentextur, die dann per Stencilmask in die vorhergegangen Ansicht eingefügt wird. Geht theoretisch rekursiv, kostet aber Performance.

Transparenzen (noch in Arbeit) werden zum einen in die fertig beleuchtete Szene gezeichnet, zum andern in eine Farbmap aus Sicht einer Lichtquelle, d.h. Transparenzen modifizieren kein z aus Lichtposi, sondern die Farbe die in eine Richtung fällt. Sollte gut zusammen gehen, hat aber den Nachteil dass die transparenten Objekte nur das Licht hinter ihnen durchlassen und selbst nicht beleuchtet werden. Wenn dieses Modell steht auch funktioniert wirds evtl. noch verfeinert.

Hm, da war ich mit "hirnverbrannt" doch näher als befürchtet.

Haiaiai hat geschrieben:Trees sind selbstbalanzierende binäre Bäume

std::map

mit Callbacks durchzulaufen, wobei auch entschieden werden kann

Comparator - der aus std::map<key, value, compare, alloc>

Pools

boost::pool

kein malloc nötig

Ich hoffe innig, dass Du new benutzt und kein malloc :-)

CubeMaps ansich lassen sich ja über Material und Effekte einbinden, das reicht für Himmelsreflektionen und Glanzeffekte. Rendern in CubeMaps habe ich im Moment noch nicht vorgesehen, aber auch nicht abgelehnt. Spiegel und Portaleffekte sollen später möglich sein durch Kamerarotation und ein vollständigen Rendervorgang (außer PP) in eine Zwischentextur, die dann per Stencilmask in die vorhergegangen Ansicht eingefügt wird. Geht theoretisch rekursiv, kostet aber Performance.

Hm, ok, das war eine dumme Frage von mir. Planare Reflektionen macht man genauso wie beim Forward Renderer auch, CubeMap-Reflektionen muss man halt zusammen mit dem Ambient Light pro Objekt in den Ergebnis-Buffer rendern.

Transparenzen (noch in Arbeit) werden zum einen in die fertig beleuchtete Szene gezeichnet, zum andern in eine Farbmap aus Sicht einer Lichtquelle, d.h. Transparenzen modifizieren kein z aus Lichtposi, sondern die Farbe die in eine Richtung fällt. Sollte gut zusammen gehen, hat aber den Nachteil dass die transparenten Objekte nur das Licht hinter ihnen durchlassen und selbst nicht beleuchtet werden. Wenn dieses Modell steht auch funktioniert wirds evtl. noch verfeinert.

Das sind die Stellen, an denen die Deferred Renderer dann doch einen Forward Renderer mit einbauen. Oder zu Tricks wie Alpha To Coverage greifen. Was für Bewuchs z.b. gut funktioniert, aber unglaublich Fillrate frisst.

Nuja, ich bin gespannt, wie das am Ende aussehen wird. Viel Erfolg noch.

Schrompf hat geschrieben:Ein Deferred Renderer übt zunehmend Faszination auf mich aus... die schlichte Eleganz, mit der man z.B. Reliefshader bauen kann, die dann ganz automatisch auch auf Licht- und Schattenverläufe wirken, finde ich toll.

Deferred Shading wird immer mehr zum Standard. Crysis, Stalker (in hoher Detailstufe), Starcraft 2, Unreal Tournament 3 (teilweise) verwenden es z.B. Aber DS ist nur der Vorläufer eines allgemeinen Paradgimenwechsels hin zu Effekten in Image-Space. DS war zuerst, dann SSAO, und Global Illumination-Fakes (genauer: 1-2 indirekte Bounces) in Image Space sind auch im Kommen. Dadurch, dass man bei DS viiiele Lichter haben kann, kann man "Light Splatting" betreiben, also das Bild mit Lichtern vollmachen. Das ist nützlich für Global Illumination-Fakes.

Die Vorteile liegen auf der Hand: Erstens sind die Kosten relativ fix, hauptsächlich nur von der Auflösung abhängig. Zweitens ist das viel robuster, da die Geometrie egal ist -> es gehen skeletale Animationen usw. automatisch. Drittens nimmt die Komplexität des Codes deutlich ab, und die Flexibilität zu. Viertens sind die Effekte schön orthogonal, und können leicht nachträglich dazugebaut werden.