ZFX + Developia

Krishty hat geschrieben:für europäische, geomorph gewachsene Städte würde ich gern ein überzeugendes Konzept sehen :)

Schon mal im IRC von mir genannt: CityEngine vom Pascal Müller aus der Schweiz. Hier gibts was zum weiterlesen.

Da ich während der Entwicklung immer viele Screenshots mache, die es nicht unbedingt zu Posten lohnt, die für den einen oder anderen aber vielleicht dennoch von Interesse sind, habe ich mich entschlossen, diese einfach in Form eines (un-)regelmäßig aktualisierten Bilderstroms online zu stellen: http://dl.dropbox.com/u/1973074/breeze/livedev.htm

Das erinnert mich doch an meine alte Techdemo... die war ja auch Deferred Rendering... :D

Eine andere Frage ist auch, ob LPPR überhaupt etwas bringt. Ich habe nun schon von zwei Seiten gehört, dass sie das implementiert haben, aber am Ende das nichts brachte (im Vergleich zu normalem deferred shading).

Bungie hat dazu ganz gute Paper.

j.klugmann hat geschrieben:Bungie hat dazu ganz gute Paper.

Meinst du den SIGGRAPH 2009 Course? Das Problem ist, dass dort wieder der Wolfgang Engel, der das ja entdeckt hat, einen Vortrag gemacht hat; er findet das natürlich toll. Leider gibt es dort keine Benchmarks; stattdessen ist alles, was ich höre: Wenn man extrem viele Lichter im Vergleich zu Geometrie hat (zwanzig mal mehr Lichter als Geometrie-Passes um den G-Buffer zu füllen, o.Ä.) bringt es was, ansonsten nicht. Ich muss dazu noch Quellen finden, aber Google zickt gerade etwas.

eXile hat geschrieben:Wenn man extrem viele Lichter im Vergleich zu Geometrie hat (zwanzig mal mehr Lichter als Geometrie-Passes um den G-Buffer zu füllen, o.Ä.) bringt es was, ansonsten nicht.

Wie kommt das? Wegen den 1-2 Texture Fetches mehr bei reinem Deferred Lighting? Die hat man bei LPPR ja eigentlich auch, nur in einem extra Geometrie-Durchlauf?

Schatten - zu mehr bin ich jetzt nicht mehr in der Lage, das Bett weckt mit seinem Rufen schon die Nachbarn.

Wie so oft, würde ich eigentlich gerne viel mehr schreiben, aber die Tage rennen nur so davon bis zur Devmania. Nachdem ich die letzten 2 Tage neben Physik die Synchronisations-, Animations- und Simulationslogik implementiert habe, habe ich den heutigen Tag darauf verwendet, mich mit 6DOF-Joints vertraut zu machen, einen selbst-balancierenden Einrad-AI-Bot (tatsächlich abstrahiert zu einer frei beweglichen Kugel mit Aufbau) zu basteln, und diesem eine autonome Navigation durch dynamische Umgebung zu verpassen.

Nach etwas mühsamer Einarbeitung gelang das dann auch tatsächlich exzellent mit einem einzigen 6DOF-Joint und wenigen Quaternionen. Nun steht das Ding, obwohl nur durch ein einziges, vollkommen frei bewegliches Kugelgelenk mit seiner Kugel gekoppelt, geradezu überraschend stabil da, selbst energiereiche Stöße mit größeren Boxen gleicht es mit etwas Bewegung wunderbar aus. Der 6DOF-Joint fungiert dabei als Motor, PhysX übernimmt die Beschleunigung anhand gegebener Feder- und Dämpfwerte, die gesamte Balance resultiert aus der Steuerung der Motorzielausrichtung, weder die Kugel noch der Aufbau werden von außen zusätzlich fixiert.

Bis jetzt kann der Bot einem beweglichen Ziel hinterhernavigieren und dabei Hindernisse überspringen, auch seine eigene Bewegungsrichtung steuert er dabei alleine durch leichte Gewichtsverlagerung seines Aufbaus.

So viel zu den heutigen Spielereien, jetzt muss die ganze Arbeit der letzten Wochen noch irgendwie zu einem netten Gesamtkunstwerk zusammengerührt werden. Bilder gibts nach wie vor ab und an hier: http://dl.dropbox.com/u/1973074/breeze/livedev.htm

Anmerkung: Weil ich gerade kein Kugelmesh parat hatte, ist der Bot auf dem Bild eher schwer zu erkennen, mittig (etwas weiter oben) ist er gerade im Sprung über einen Würfel begriffen.

Ich mag diese surrealen minimalistischen Landschaften, die Du immer zu Testzwecken erzeugst. Ich wünschte, Du würdest daraus mal ein richtiges artsy Spiel draus machen, bei dem man solche Landschaften durchkämmt und ebenso surreale Charaktere kennenlernt.

Der autonom balancierende Bot klingt aber auch nach ner coolen Spielerei. Bleib dran, ich freu mich drauf!

Nachdem zur Devmania leider keine Demo fertig wurde (u.a. weil mir das neue Blender und das neue PhysX mit einigen Bugs auf die Schnelle doch etwas zu viele Steine in den Weg gelegt hatten), werde ich neben dem laufenden Semester nun erstmal weiterhin ausstehende Engine-Funktionalität fertig implementieren. Die Roadmap für das erste Open-Source-Release liegt nach wie vor auf dem Schreibtisch, wenngleich ich mir vorgenommen habe, während des Semesters nur noch abends an eigenen Projekten zu werkeln. Bis dahin vertröste ich euch mit Bildern und hoffentlich bald auch wieder einigen technischen Details. ;)

So, ich nehme mir mal wieder die Zeit, ein wenig Technisches zu berichten:

Nachdem ich in der ersten Iteration den klassischen Ansatz der Einheitentyphierarchie gewählt hatte, bin ich dort sehr schnell an Grenzen gestoßen, sobald mehr als Rendering ins Spiel kam. Wenn ich von Einheitentyphierarchie spreche, dann meine ich damit alle möglichen Szenenelemente wie statische Meshes, animierte Meshes, mehrere Lichttypen, Partikelemitter, Terrain, Wolken, Wasseroberflächen/-volumina etc., welche sich über Vererbung gemeinsame Eigenschaften teilen, wie beispielsweise Position und Ausrichtung (das klassische Entity), räumliche Ausdehnung ... wars das schon? Meiner persönlichen Erfahrung nach: Ja. Nun war also der Rendering-Anteil des Szenengraphen über eine derartige Klassenhierarchie implementiert, und hätte in allen möglichen Kombinationen mit verschiedenen physikalischen Eigenschaften (statische/dynamische Actors) oder gar weiterer Ausgabefunktionalität (Audio!) - womöglich noch AI-Integration - eine Explosion der Klassenhierarchie bedeutet.

Aus dieser Not heraus und etwas inspiriert von mirlix' damaligen Andeutungen über die Architektur seines damaligen (etwas über-generischen?) Framework-Projekts wurde das Controller-Konzept geboren. Jedes Entity besaß fortan eine Liste angehängter Controller-Objekte, die das Entity in allen weiteren Aspekten neben dem Rendering vertraten und koppelten. So übernahmen verschiedene Rigid-Body-Controllers die Synchronisation des Entities mit der physikalischen Simulation und umgekehrt, je nach Controller-Typ und ausgeführten Operationen. Wäre die Iteration fortgesetzt worden, so hätten sich auch Audio-Quellen, AI-Anbindung und viele weitere Dinge elegant in Controller-Form an beliebige Entities heften lassen. Das Konzept erwies sich als enorm flexibel und leistungsfähig, es trennte verschiedene Aufgabenbereiche elegant und rettete das Projekt so vor dem absoluten Chaos. Am Ende blieb Verärgerung, Verärgerung darüber, dass das Rendering unumkehrbar in die Einheiten hineingegossen war, und viele Erweiterungen des Renderings durch den rigiden Rahmen der Einheitenlogik erschwert wurden.

Ich habe die Chance der neuen Iteration genutzt, diese Uneinheitlichkeit endlich zu beheben. Ein Entity ist in Bezug auf die gesamte Simulation und Ausgabe fortan eine nicht-polymorphe Dateneinheit, die mit Position und Ausrichtung in einer gleichermaßen nicht-polymorphen World ihrer einzigen Aufgabe nachgeht, zu existieren. Entities referenzieren mit einer jeweiligen polymorphen Liste beliebige (Entity-)Controller-Objekte, die zur Laufzeit hinzugefügt und entfernt werden. Daneben existiert eine ebenfalls nicht-polymorphe Simulation, die ebenfalls mit einer polymorphen Liste (Simulation-)Controller-Objekte referenziert, welche ebenfalls zur Laufzeit hinzugefügt und entfernt werden. Momentan hängen an der Simulation typischerweise ein (Graphics-)SceneController, ein (Physics-)SceneController und ein (Character-)SceneController. An einem Entity hängen dabei beilebig viele Mesh-, PointLight-, SpotLight-, DirectionalLight-, RigidDynamic-, RigidStatic- und CharacterControllers.

Die Logik der Verbindung mehrerer interagierender Systemkomponenten ist hierbei etwas entgegengesetzt zum klassischen Einfügen von Einheiten in eine Simulation / Szene: Jeder Controller implementiert eine Attach- und eine Detach-Methode, welche seine eigene Funktionalität, zumeist durch Eintragung bzw. Austragung bei anderen Komponenten, aktiviert bzw. deaktiviert. Einheiten lassen sich über eine eigene Attach- bzw. Detach-Methode auch als Ganzes in die Simulation "einfügen" bzw. aus der Simulation "herausnehmen", die beiden Methoden arbeiten sich jeweils einfach durch alle angefügten Controller-Objekte.

Was auf den ersten Blick etwas umständlich, unintuitiv und überkompliziert wirkt, birgt einige entscheidende Vorteile:

• Subsysteme lassen sich vollständig isoliert implementieren. Controller-Objekte werden meist bereits bei der Konstruktion fest untereinander verdrahtet, Mesh- oder Light-Controllers beispielsweise bekommen bei der Konstruktion bereits die Zieleinheit und den Zielszenen-Controller übergeben. Werden sie an eine Einheit gehängt und wird diese Einheit im Anschluss per Attach eingefügt, so ist das Objekt bei ebenfalls an die Simulation angefügtem Szenen-Controller vollständig in den Renderablauf integriert, ohne dass die Simulation das entsprechende Subsystem kennt oder gar entsprechende Einheitenverwaltungslogik implementieren muss. Übrig bleibt für die Anwendung nur, Fetch, Step, Flush und Render aufzurufen, jedes Simulation-Controller-Objekt reagiert auf die entsprechenden Aufrufe mit den notwendigen Arbeitsschritten.

• Einheiten lassen sich nach Bedarf zusammenbauen, alles, von der funktionslosen Positionsmarkierung bis hin zum mehrteiligen Mesh (ein Controller pro Material-Subset) mit integrierter Beleuchtung, Physik-/AI-Integration und Tonemission ist ohne zusätzlichen Implementierungsaufwand möglich.

• Controller-Objekte wissen wesentlich besser, wem sie gehören, zuhören und mit wem sie zusammenabeiten wollen, als dies eine allgemeine Simulation je könnte. Hierin liegt der Grund für die umgekehrte Einfüge-/Herausnehm-Logik. Konkret hatte ich in der ersten Iteration massive Probleme, Instancing vernünftig zu implementieren. Nahm ich Objekte aus der Simulation, um die Renderlogik einem einzigen Instanz-Objekt zu übertragen, nahmen die Objekte auch nicht mehr an der restlichen Simulation teil. Entfernte ich sie gezielt aus dem Rendering, hatte ich keinen Überblick mehr, wo mein Objekt am Ende noch registriert war und wo es ggf. herauszunehmen war. Im neuen System existieren beide Probleme nicht mehr: registriert sich ein Controller nicht im zentralen Rendering-System der jeweiligen Simulation, so findet auch kein automatisiertes Rendering statt. Jeder Controller ist frei, auf andere Aufrufe hin an anderweitigem Rendering teilzunehmen. Da jeder Controller für sich seine eigene Registrierung steuert und somit kennt, lassen sich alle Einheiten über dieselben Controllers auch wieder sauber aus den jeweiligen genau richtigen Subsystemen entfernen.

• Wenngleich ich diesen Punkt bisher nicht ausgenutzt haben, so lassen sich verschiedene Aufgabenbereiche mit diesem Ansatz sogar im Speicher lokal gruppieren, indem gleichartige Controller-Objekte auch in dasselbe Stück Speicher gelegt werden. Bei der typischen (mehr oder weniger) linearen Abarbeitung vieler gleichartiger Objekte ließe sich so ein Vorteil in Bezug auf Cache-Ausnutzung ziehen.

Fazit: Ich bin mit der neuen einheitlichen Nicht-Bevorzugung aller Subsysteme sehr zufrieden, die saubere Trennung und die massive Verringerung von Vererbung schaffen eine großartige Übersicht, Flexibilität und Einfachheit. Wenngleich es vielleicht zunächst nicht so aussieht, ist die Kopplung interagierender Komponenten extrem direkt, und nirgends stehen einem große und unhandliche Verwaltungsstrukturen im Weg, selbst wenn es darum geht, größere systemische Neuerungen einzuführen.

Ich finde ein KlassenDiagramm da auch immer sehr aussagekräftig :)

Gruß

Ein sehr interessanter Lesestoff. Danke dafür. Ich habe schon gelegentlich auf GameDev.net von diesem komponenten-basierenden Ansatz gelesen, aber Du hast auch schon verständlich dargelegt, was man damit gewinnt. Wenn ich mal wirklich viel Zeit habe, baue ich die Splitterwelten-Engine auch nochmal auf so ein System um. Und schreibe die ganzen Konvertierer zur Erhaltung der 2GB an existierenden Daten, was wahrscheinlich die anstrengendere Aufgabe wird.

Ich wundere mich aber, ob ich das überlesen habe: hast Du eine Möglichkeit vorgesehen, Objekte zu gruppieren? Wir benutzen das in der Splitterwelten-Engine für folgende Dinge:

- Zusammenfassen von vielen Objekten zu einem großen Mesh ab einer gewissen Detailstufe. Alle Bäume stecken z.B. in 50m-großen Waldsegmenten, die ab einer Entfernung das Rendern aller Unterobjekte übernehmen. Das Zusammenfass-Objekt sammelt dazu alle Objekte in einer reduzierten Detailstufe in einem Mesh und schaltet dann einfach den kompletten Hierarchiezweig ab, wenn es mit diesem Mesh das Rendering übernimmt.

- Transformations-Hierarchien: komplexe Objekte wie z.B. Häuser mit beweglichen Teilen (aka Türen, Fenster, Fensterläden) drin - im Editor möchte man die üblicherweise als Ganzes erstellen, bearbeiten, löschen. Rotierende Türen müssen ihren Türknauf und den Schlüssel im Schlüsselloch mitbringen, wenn sie aufgehen. Sowas halt.

Speziell das "Zusammenfassen von Unterobjekten" gibt es bei uns in vielen Varianten, weil wir nunmal durchweg CPU-limitiert sind und irgendwie die DrawCalls runterkriegen müssen. Daher finde ich das Thema ein Spannendes, auch wenn das unter DX11 vielleicht nicht mehr so das Problem ist.

Und mich würden die Schnittstellen Deiner grundlegenden Klassen interessieren. Das, was ich bisher von komponentenbasierender Programmierung gesehen habe, lief immer darauf hinaus, dass man unendlich viele Versionen von "Suche mir alle Komponenten des Typs xy raus und mach was damit" schrieb. Mich würde interessieren, ob Du dafür eine Lösung gefunden hast, die sowohl die Coder-Finger als auch die CPU schonen.

Ich finde Entity Systeme ziemlich gut. Wie löst du technisch die Identifizierung von Controllern bzw. wird es möglich sein, dass ein Controller A eine Art Schnittstelle B als Controller entgegen nimmt um bestimmte Aufgaben zu delegieren/Aktionen auszulösen/Daten zu erhalten? Wird es möglich sein die zu benutzenden Controller eines Entities z.B. via XML zu konfigurieren? In einem recht interessanten Entity-System für Java werden dazu in den Komponenten des Entity nur Daten gespeichert und Systeme übernehmen die Verarbeitung sozusagen von außen. In Unity wird das ganze ja so ähnlich wie bei dir gemacht (sofern ich es richtig verstanden habe). Dort kann man ja die Komponenten über den Typ erhalten. Gruppierung von Objekten ist da übrigens durch GameObject Hierarchien möglich, vielleicht ist das ja auch ein sinnvoller Weg für dich...

joggel hat geschrieben:Ich finde ein KlassenDiagramm da auch immer sehr aussagekräftig :)

Schrompf hat geschrieben:Ich wundere mich aber, ob ich das überlesen habe: hast Du eine Möglichkeit vorgesehen, Objekte zu gruppieren? [...]

Sehr gute Frage, denn die Antwort macht wohl den Aufgabenbereich des gesamten Systems sehr viel klarer: Meine Einführung über die Entwicklung des Systems aus dem Szenengraphen heraus war in dieser Beziehung leider etwas missverständlich. Tatsächlich enthält das beschriebene abstrakte System einen solchen Szenengraphen in keinster Weise, denn über die Beziehungen von Objekten untereinander enthält es keinerlei Information.
Auch hier greift die Trennung einzelner Subsysteme: Betrachten wir wieder das Beispiel des Instancing, so ist eine Gruppierung gleichartiger Meshes unter dem Aspekt des Renderings sehr sinnvoll, in der physikalischen Repräsentation der Welt dagegen wäre eine derartige Hierarchie ohne jeglichen Vorteil für die Simulation, schlimmer, unnötiger Balast bei der Verarbeitung. Aufgabenbezogene Szenengraphen finden sich also frühestens in der Ebene der SceneControllers, welche an einer bestimmten Simulation hängen. Dortige Struktur und Gruppierung wird durch das beschriebene System in keinster Weise beschränkt oder vorgegeben.

Neben dem Simulationssystem existiert, wie im letzten Post angedeutet, auch noch eine Welt (welche dem entspräche, was man in einem Editor bzgl. Szenenobjekten sähe und bearbeitete). Diese enthält momentan einfach alle existierenden Objekte in einer linearen Liste, Hierarchien zur Objektgruppierung ließen sich hier jedoch ohne weiteres implementieren. Von echten Transformationshierarchien (abseits der Editierlogik) bin ich persönlichen kein Fan, weil sie den Code zur Laufzeit unnötig verkomplizieren, und in Bezug auf Verhalten bereits vollständig durch die Physiksimulation abgedeckt sind (für korrektes physikalisches Verhalten entstünde gar eine Dopplung derselben Funktionalität in gänzlich verschiedenen Codeabschnitten).

Schrompf hat geschrieben: Das, was ich bisher von komponentenbasierender Programmierung gesehen habe, lief immer darauf hinaus, dass man unendlich viele Versionen von "Suche mir alle Komponenten des Typs xy raus und mach was damit" schrieb.

Ja, nichts hasse ich mehr als diese pseudogenerischen Architekturen, die um der Generizität willen alles in einen Topf werfen, nur um es anschließend mit viel Mühe wieder herauszufischen. Abgesehen von oberflächlicher Entkopplung, welche in der Regel wohl vor allem ein Workaround um das verfehlte Modulkonzept der jeweiligen Programmiersprache ist, gewinnt man in meinen Augen nicht viel. Dafür nimmt man, wie du schon sagtest, eine massive Unsicherheitsquelle, einen unnötigen (Such-)Laufzeitverlust und extrem viel umständlicheren Code in Kauf.

Mein System ist, wie schon angedeutet, extrem direkt. Wie schon einmal erwähnt, habe ich mich in vielerlei Hinsicht von tiefer Kapselung gelöst. Die Verbindung verschiedener Controllers geht nicht den Umweg über Entities oder gar Simulationen, keinen Umweg über Typsuchfunktionen. Viel schlichter werden einfach direkt Instanzen zusammenarbeitender Objekte verknüpft. Der MeshController erhält schon bei der Konstruktion sein Entity, seinen (Rendering-)SceneController, sein Mesh, seinen EffectCache etc. unverschleiert per Argument, alle zur Laufzeit benötigten Objekte landen in Form von Zeigern im MeshController-Objekt.

Dies hat die offensichtliche Konsequenz, dass neben der Simulation auch die verschiedenen Rendering-, Physik-, Character- etc. SceneControllers durch die Anwendung gespeichert werden müssen. Dies geschieht in der Regel in einer durch die Anwendung hart-codierten Szenenstruktur, die Zeiger auf alle für die Anwendung relevanten Simulations-Controllers bereit hält. Eine naheliegende Reaktion wäre jetzt: Aber was ist dann der Punkt dieser ganzen Architektur, die Controllers generisch an Simulationen anheftet, wenn ich diese Controllers selbst wieder hart-codiert speichern muss? Die Antwort: Das Controller-System automatisiert und steuert Verhalten, nicht Beziehungen. Eine Anwendung weiß immer, von welchen Subsystemen sie Gebrauch macht, ein Verstecken dieser wäre also absolut sinnlos.

Eine gewisse Ausnahme dieser Regeln stellen Tools in der Content-Pipeline da. Zwecks Serialisierung und Bearbeitung existiert tatsächlich ein minimales Reflection-System, angedeutet durch die GetType()-Methoden im Klassendiagramm. Diese sind jedoch ausdrücklich nicht für den normalen Gebrauch zur Anwendungslaufzeit gedacht, sondern allenfalls zur generischen Bearbeitung polymorpher Objekte in den entsprechenden Tools sowie zur generischen Serialisierung polymorpher Objekte durch das Serialisierungssystem.

Chromanoid hat geschrieben:Wie löst du technisch die Identifizierung von Controllern bzw. wird es möglich sein, dass ein Controller A eine Art Schnittstelle B als Controller entgegen nimmt um bestimmte Aufgaben zu delegieren/Aktionen auszulösen/Daten zu erhalten?

Ich denke das habe ich an dieser Stelle bereits ausreichend beschrieben, dennoch die direkte Antwort: Das Problem existiert nicht, ich übergebe bei der Konstruktion direkt Objekt B an Controller A.

Chromanoid hat geschrieben:Wird es möglich sein die zu benutzenden Controller eines Entities z.B. via XML zu konfigurieren?

Da die Serialisierung momentan in XML geschieht: Ja, im Rahmen der normalen Serialisierung eben. Konfiguration über einen entsprechenden Editor sollte aber wesentlich sicherer und einfacher sein, als im XML rumzuschmieren. ;)

Chromanoid hat geschrieben:In einem recht interessanten Entity-System für Java werden dazu in den Komponenten des Entity nur Daten gespeichert und Systeme übernehmen die Verarbeitung sozusagen von außen.

Bei mir gibt es gewissermaßen beides, die Controllers steuern in erster Linie das Verhalten, Daten werden von den Controllers i.d.R. nur referenziert oder bei Bedarf leicht ergänzt (z.B. Renderable Controllers durch Bounding Spheres und Renderable Flags). Beim Rendering existieren durchaus auch datenorientierte Ansätze, bei denen Subsysteme von Controllers mit Daten gefüttert werden, woraufhin diese Subsysteme den Daten entsprechend von außen die Steuerung der Controllers übernehmen.

Chromanoid hat geschrieben:In Unity wird das ganze ja so ähnlich wie bei dir gemacht (sofern ich es richtig verstanden habe). Dort kann man ja die Komponenten über den Typ erhalten.

Wenn Komponenten regulär über den Typ abgefragt werden, dann nein. Ich habe das Unity-System kurz überflogen, und es scheint mir eher ein besonders schwammiger Vertreter der gerade eben angesprochenen pseudogenerischen Waschbärarchitektur zu sein, korrigiere mich, wenn ich mich irre. ;)

Ich nutze das gleiche Prinzip für meine aktuelle Engine-Iteration und habe das gleiche System auch schon in einer kommerziell-verwendeten Engine integriert. Wie Cat bereits sagte, ist die Flexibilität enorm und kann auch sehr einfach erweitert werden. Letztendlich gehe ich bei der Entwicklung meiner Engines immer von einem sehr unfähigen und faulen Programmierer aus, der die Engine letztendlich nutzen wird. Damit erreiche ich, dass viele Controller sehr spezialisiert arbeiten können und ich nicht mehr so extrem verallgemeinern muss, damit der Nutzer das System ohne Probleme versteht. Bei mir kann jeder Controller und jedes Entity per XML inklusive aller Eigenschaften und Typen gespeichert und geladen werden. Zur Identifikation von einzelnen Controllern nutze ich ein internes Typsystem in Verbindung mit Hashing( Murmur3 ).

Gruppierungen sind sehr praktisch und nennen sich bei mir "Szene" ;). Eine Szene ist einfach ein abstrakter Container, der wiederum Elemente seines Types beinhalten kann. Man kann beispielsweise aus einer Szene A alle Objekte in die Szene B transformieren, die die Eigenschaft XY mit dem Wert Z haben. Entsprechend dazu gibt es dann Interfaces, die es einem ermöglichen die Szene soweit zu modifizieren. Ich weiß nicht, wie es genau bei Cat ist, aber meine Controller sind immer datenlos und werden erst mit dem Entity in Verbindung mit Daten gebracht. Die reine Funktionalität, also meinetwegen des Rendern eines Meshes, sollte meines Erachtens nach möglichst getrennt von den Daten existieren. Entities sind bei mir also nur reine Data-Holder mit nur geringer Funktionalität. Perspektiven (also meinetwegen für Shadow-Maps etc. ) sind bei mir auch nur Szenen mit einer Camera integriert.

€dit: Da war ich zu langsam.

Danke für das Diagramm.
Ich hab ein paar Fragen zum bessern Verständnis, sry.
Also genauer: was im einelnen in dem Diagramm dargestellt wird.
Ich habe da echt Probleme das alles zu verstehen :(.

- wo befindet sich der Mesh? Kapselt es die "Renderable"-Klasse?
- was/wo ist der "EffectCache"?
- Die "Simulation" _verwendet_ "SynchronizedHost", "AnimatedHost", "RenderableHost"?
- Warum noch mal dieses "XYZ-Hosts"? was kapseln die oder verwalten sie? Eine Menge an "XYZ's"?

Ich würde gerne noch mehr Fragen stellen, denke aber das das vlt. erstmal reicht.
Ich bin mir auch nicht im klaren, was die einzelnen Pfeile repräsentieren...

Aber naja, sooo genau brauchst auch nicht auf jede *sinnlose" Frage einzugehen ^^..
Soll ja OpenSource werden. Und wenn ich dann mal Code sehe, verstehe ich vlt. mehr.

Fragen beantworte ich später, noch kurz ein neues Bild vom AO, zum ersten Mal getweakt in einigermaßen realistischer Umgebung.

Der Bilderstrom fließt wieder.

Ist das AO mit 2 Kernelgrößen verbaut? Oder wie kommt zum einen dieses feine Detail, zum anderen die seeehr grobe Schattierung zustande?

Genau, ich werde mal noch vollständiges Multi-Resolution AO testen, damit dürften sich noch mehr Graustufen bei besserer Effizienz rausholen lassen.

Ein kleiner Trick, der unverschämt gut wirkt: Ambientes Licht direktionaler Lichtquellen nicht völlig ungerichtet anwenden, sondern auch im Schatten / auf Objektrückseiten eine sehr abgeschwächte Winkelbeeinflussung einführen, z.B. 0.5f - 0.1f * cosAngle, wobei cosAngle = dot(normal, toLight) (ohne saturate()!). Man beachte das umgekehrte Vorzeichen zur normalen Winkelbeeinflussung saturate(+cosAngle). Die Idee dahinter ist, dass starkes indirektes Licht bei Streuung an der direkt beleuchteten Fläche die Richtung ändert.

CodingCat hat geschrieben:Ein kleiner Trick, der unverschämt gut wirkt: Ambientes Licht direktionaler Lichtquellen nicht völlig ungerichtet anwenden, sondern auch im Schatten / auf Objektrückseiten eine sehr abgeschwächte Winkelbeeinflussung einführen, z.B. 0.5f - 0.1f * cosAngle, wobei cosAngle = dot(normal, toLight) (ohne saturate()!). Man beachte das umgekehrte Vorzeichen zur normalen Winkelbeeinflussung saturate(+cosAngle). Die Idee dahinter ist, dass starkes indirektes Licht bei Streuung an der direkt beleuchteten Fläche die Richtung ändert.

Allerdings!
So hab ich das damals auch gemacht
Beim mittleren Bild mit dem Hasen sieht man das ganz gut. Wäre es einfach nur Ambientes Licht, hätte man an jeder Stelle die gleiche Helligkeit.

Noch eine kleine Beobachtung: Beim Sampeln des Halbschattens mit zufällig gedrehten ganzen Sample-Scheiben verliert man standardmäßig immer die Hälfte seiner Samples auf der Hälfte der Scheibe, welche auf jeden Fall bedeckt ist. Dies lässt sich bei gleichmäßig verteilten zufälligen Drehungen (erfordert 360°!) ganz leicht dadurch beheben, dass man alle Samples auf eine Hälfte der Scheibe packt. Diese halbe Scheibe erwischt dann zwar ab und an nur bedeckte Samples, dafür erhält man jedoch alle paar Pixel wesentlich mehr Abstufungen.

CodingCat hat geschrieben:Noch eine kleine Beobachtung: Beim Sampeln des Halbschattens mit zufällig gedrehten ganzen Sample-Scheiben verliert man standardmäßig immer die Hälfte seiner Samples auf der Hälfte der Scheibe, welche auf jeden Fall bedeckt ist. Dies lässt sich bei gleichmäßig verteilten zufälligen Drehungen (erfordert 360°!) ganz leicht dadurch beheben, dass man alle Samples auf eine Hälfte der Scheibe packt. Diese halbe Scheibe erwischt dann zwar ab und an nur bedeckte Samples, dafür erhält man jedoch alle paar Pixel wesentlich mehr Abstufungen.

Verstehe ich nicht... meinst doch jetzt beim SSAO, oder wo?

Nein, Schatten eben. ;)

Leider wirkt die Vereinfachung des Halbschattens auf den "inneren Halbschatten" (nur der Teil, welcher bei einem vollkommen scharfen Schatten beschattet würde), auf die sich obige Beobachtung bezog, nicht sonderlich gut - schade, muss ich wohl doch auf Occluder-Suche gehen. Dabei sind meine GPU-Renderzeiten jetzt schon viel zu hoch. Vielleicht kann ich die Occluder-Suche dazu nutzen, Halbschattenbereiche im Voraus ausfindig zu machen und zu markieren.

Ich bin nun doch erstmal beim halben Halbschatten geblieben, mit etwas Tweaking sieht das ganz passabel aus, und erfordert nur ca. 12 PCF- statt 36 Blocker-Search-Samples.

Noch ein Random Shot im Kampf gegen den Einrat-Bot: Mehr Bilder gibts wie immer im Bilderstrom.

joggel:
Die Pfeile sind UML nachempfunden, in dem Rahmen, in dem es Power-Point ermöglicht. :P
(Ja, ich habe tatsächlich noch keine bessere Modellierungssoftware gefunden. :lol:)
Vertikal entspringende Pfeile entsprechen Vererbung, horizontal entspringende Referenzierung.

Das Diagramm zeigt die Entity-/Simulations-Controller-Logik. Meshes tauchen an mehreren Stellen auf: Zunächst gibt es das Mesh-Objekt, welches Vertex- und Index-Buffers mit zusätzlichen Informationen wie Vertex- und Indexanzahlen, Vertex-Beschreibung und Index-Format. Dieses Mesh-Objekt ist ein reines Datenobjekt, es kann weder rendern noch sonstig Intelligentes. Daneben gibt es noch ein MeshCompound-Objekt, welches mehrere Mesh-Objekte zusammenfasst (z.B. Subsets mit verschiedenen Materialien etc.).
Das eigentliche Rendering findet dann in einem entsprechenden MeshController-Objekt statt, welches pro Mesh-Entity an das entsprechende Entity geheftet wird. Das MeshController-Objekt erbt von Controller und beScene::Renderable und nimmt bei der Konstruktion u.a. ein Mesh-Objekt entgegen (Mesh-Objekte können selbstverständlich von mehreren MeshControllern geteilt werden). Nebenbei bemerkt unterscheidet sich beScene::Renderable vom Renderable-Interface in obigem Diagramm, letzteres bietet eine allgemeine Schnittstelle für Rendering (z.B. auch Audio, Force Feedback oder wasimmer dir einfällt), ersteres dagegen ist die Schnittstelle für grafisch gerenderte Objekte. Grafische Renderables werden von der Rendering Pipeline und der Szene behandelt, welche wiederum vom allgemeinen Renderable erbt, um das speziell grafische Rendering des Szenen-Moduls in den allgemeinen Rendering-Ablauf einzubetten.

Der EffectCache ist ein stupider Resource Manager, welcher Effekte bei Bedarf nachlädt, wenn bereits geladen zurückgibt, und dabei die Dateiversion des Effect-Source-Codes sowie includierter Effect-Headers überwacht, um diese gegebenenfalls automatisch neu zu kompilieren und binär in einem Cache-Verzeichnis abzulegen. (Der Effect-Compiler des DirectX-SDK ist ein sehr gemächliches Stück Software, ohne binäres Caching compilierter Effekte würde jeder Programmstart locker eine halbe Minute oder mehr in Anspruch nehmen).

Die Hosts sind einfache Basisklassen, die Objekte des jeweiligen Interfaces in Listen verwalten und selbst auch wieder das Interface implementieren, um Aufrufe des Host-Objekts automatisch an alle gespeicherten Objekte weiterzugeben.

Das sieht schon ganz in Ordnung aus! :D
Was wirft denn da noch Schatten? Das sieht aus wie ne Achterbahn... ;)