ZFX + Developia

Wieso nicht gleich alles in Polarkoordinaten ausdrücken :P

Wäre das geschickt? Ich meine, käme ich davon effizient zurück zu Vektoren?

War nur grad so ein Gedanke, habs nich ausprobiert. Du bräuchtest eben nur 2 Koordinaten pro Vektor. Die Bitangente könntest du als Offset zum Phi der Tangente codieren, damit bräuchtest du nur 5 Werte für den ganzen Tangenspace und kannst sogar Tangenten/Bitangenten die nicht orthogonal sind darstellen ;)
Du bezahlst eben mit 2-3 sin() und 2-3 cos() pro Vertex, ich vermute dass es effektiv kaum einen Unterschied macht...

Naja, die Argumentation hinter der Kodierung des Drehsinns in den Betrag des Tangentenvektors war folgende: Der Informationsgehalt der zusätzlichen Komponente ist extrem gering (1 Bit!). Normalen- und Tangentenvektoren müssen dabei eigentlich eh immer normiert werden, nachdem sie durch die allgemeine Welttransformation und die Interpolation gegangen sind. Im Vertex Shader aus dem Betrag des Eingabe-Tangentenvektors mittels sign(dot(t,t) - 0.5f) den Drehsinn zu rekonstruieren, kostet mich praktisch nichts. Dafür spare ich sowohl auf der Platte als auch im VRAM bei vielen Vertices eine ganz gehörige Menge Floats, in denen quasi keine Information steckt.

Jap, schon klar. Darum der (ursprünglich eher im Spaß gemeinte) Vorschlag, alles in Polarkoordinaten darzustellen, da du dadurch noch einen float sparen kannst (du brauchst dann nur 2 für die Normale + 2 für die Tangente + 1 für die Bitangente). Du bezahlst mit 2 bzw. 3 sin() und 2 bzw. 3 cos() (je nachdem wie du die Bitangente berechnest), sparst aber das Normalisieren.
Vermutlich würden sogar 16bit, möglicherweise sogar 8bit UNORMs für die Komponenten ausreichen ;)

Wie gesagt, ursprünglich nicht so ganz ernst gemeint, aber evtl. sogar einen Versuch wert...

Eigentlich eine gute Idee, aber ich bin beim Vertexspeicher-Sparen etwas konservativ geworden, seit ich gesehen habe, wie 8Bit-Bone Weights die Mimik eines gesunden jungen Menschen deformieren können.

Ja, das kann ich mir vorstellen. Da es in diesem Fall nur um 1 Bit geht, hoffe ich einfach mal, dass sich das hier nicht noch rächen wird. ;-)

Mir ist gerade aufgefallen, dass ich noch kein Bild mit ordentlichen Normalen da habe, also einfach mal wieder etwas Bildspam.

Das Crytek Sponza ist wirklich großartig, was man auch testet, es sieht immer irgendwie gut aus. :mrgreen:

Ein schöner Anblick! Ich ziehe meinen Hut.

Schrompf hat geschrieben:Eigentlich eine gute Idee, aber ich bin beim Vertexspeicher-Sparen etwas konservativ geworden, seit ich gesehen habe, wie 8Bit-Bone Weights die Mimik eines gesunden jungen Menschen deformieren können.

Verständlich. Aber mit 16bit UNORMs hab ich eine Winkelauflösung von 360° / 65536 = 0.005°. Die Frage ist eher, wie stark die Sinusse zu Buche schlagen und ob der reduzierte Bandbreitenbedarf das wettmachen kann (und da bin ich eher skeptisch)...

Btw: Herkömmliche Normalmaps speichern Normalen in nur 8bit pro Komponente und nutzen nichtmal die voll aus...

dot hat geschrieben:Jap, schon klar. Darum der (ursprünglich eher im Spaß gemeinte) Vorschlag, alles in Polarkoordinaten darzustellen, da du dadurch noch einen float sparen kannst (du brauchst dann nur 2 für die Normale + 2 für die Tangente + 1 für die Bitangente). Du bezahlst mit 2 bzw. 3 sin() und 2 bzw. 3 cos() (je nachdem wie du die Bitangente berechnest), sparst aber das Normalisieren.
Vermutlich würden sogar 16bit, möglicherweise sogar 8bit UNORMs für die Komponenten ausreichen ;)

Wie gesagt, ursprünglich nicht so ganz ernst gemeint, aber evtl. sogar einen Versuch wert...

Ja, letztlich sind die zwei Winkel wohl eher suboptimal in Bezug auf Platzverbrauch und Rekonstruktionsaufwand. Einen recht vielversprechenden Ansatz habe ich vor einiger Zeit via Twitter aufgeschnappt:

bmcnett hat geschrieben:my fav encoding: 16 bit distance along spiral between poles
- https://twitter.com/#!/bmcnett/status/1 ... 1589410816

Seine genaue Kodierung kenne ich nicht, aber mit einem sincos(2pi * alpha * turns) für den Einheitskreis und einem cos(pi * alpha) für die Y-Koordinate käme man bezüglich Rechenaufwand schonmal ganz gut weg, und das bei dem Speicherbedarf eines halben Floats. Eventuell gibt es auch noch geschicktere Rekonstruktionsabbildungen, die Werteverteilung sollte man auch noch kurz betrachten.

Nachträgliche Korrektur: Die Rekonstruktion ist in diesem Fall ja fast die gleiche wie bei der Beschreibung durch 2 Winkel. Ich hatte übersehen, dass du gleich für Tangente und Bitangente gerechnet hattest. Mit 8 Bit pro Winkel bist du auf jeden Fall nah dran. Ein Nachteil, der mir spontan einfällt, ist die etwas weniger geschickte Bitverteilung, weil der Horizontalwinkel eigentlich nur die Hälfte der Werte des Azimutalwinkels benötigt.

Ja. Und die Frage ist eben vor allem, inwiefern der Rekunstruktionsaufwand so einen Ansatz rechtfertigt. Meine Vermutung ist, dass es da nicht wirklich was zu gewinnen gibt, sofern man es nicht mit extrem großen Meshes zu tun hat und die Indices einigermaßen gute Lokalität aufweisen...

Leider habe ich im Moment der Klausuren wegen praktisch keine Zeit, produktiv weiterzuarbeiten. In einer kurzen Lernpause habe ich das Serialisierungssystem soweit aufgebogen, dass sich auch beliebige Teile der Welt in Form von Entity-Gruppen abspeichern, laden und einfügen lassen. Damit habe ich insbesondere endlich einen Weg, Objekte fertig mit Materialien abzuspeichern und einzufügen. Die bereits weiter oben im Thread angesprochene Asset-Synchronisierung ist noch in keiner Weise vorhanden, im Moment ist es nicht mehr als ein einfaches Copy & Paste. Das Qt QTreeWidget hat die Sache mal wieder so schmerzhaft wie möglich gemacht. (Item-Indizes ändern sich mit der Sortierung! Nächstes Mal lieber wieder QTreeView mit persistenten QStandardItemModel-Indizes verwenden.) Links befindet sich nun also ein Browser, der alle relevanten Ordner des Dateisystems spiegelt (inkl. Auto-Update), Assets lassen sich per Drag & Drop an gewünschter Stelle direkt in die Szene einfügen. Rechts unten befindet sich das "Selektionslabor", hier lässt sich in der aktuellen Objektauswahl des Editors bei Bedarf nochmal eine Unterauswahl treffen, um die gewählten Objekte dann gemeinsam als Asset in eine Datei zu speichern (landet natürlich direkt im Asset Browser zur Wiederverwendung mit Drag & Drop).

Fazit: UI-Programmierung ist mühsam und frustrierend, wenn man wenig Zeit hat.

Nachdem ich endlich Hot Swap/Reload, ein einheitliches Ressourcensystem, eine funktionierende Docking UI sowie ein datenorientiertes Entity- und Rendering-System habe, muss ich mir langsam Gedanken um Content Creation machen. Für prozedurale Texturgenerierung scheint Farbrauschs Werkkzeug 4 eine ganz passable Lösung zu sein. Insbesondere deren automatisierte Export-Operatoren erlauben in Kombination mit Texture Hot Swap einen sehr schönen Workflow mit direktem In-Engine Preview. Meine ersten Gehversuche:


Das einigermaßen physikalisch-basierte Rendering habe ich mir in der Kombination von Reset abgeschaut. Oren-Nayar für diffuse Beleuchtung, Kelemen-Kalos für Specularity und Schlick für Fresnel. Um diffuse und spekuläre Beleuchtung halbwegs normiert zusammenzusetzen, habe ich außerdem Shirleys 21 / 20 (1-r) * f_l * f_c -Koeffizienten gemopst.

Schick, gefällt mir der Editor. Sieht zumindest im Moment recht leichtgewichtig, also nicht überladen, aus. Die Modelle hast in Blender erstellt? Ach, und woher kommen in der Konsole immer diese E_INVALIDARG Fehler? ^^

mnemonix hat geschrieben:Schick, gefällt mir der Editor. Sieht zumindest im Moment recht leichtgewichtig, also nicht überladen, aus. Die Modelle hast in Blender erstellt? Ach, und woher kommen in der Konsole immer diese E_INVALIDARG Fehler? ^^

Das ist eine intern gefangene Exception beim Resize der Targets, nämlich immer dann, wenn die Engine feststellt, dass sich für das Swap Chain Target kein Shader Resource View ("Textur") erstellen lässt; daraufhin lässt die Engine es einfach sein. ;)

Und ja, Leichtgewichtigkeit war das Ziel; schon alleine, weil ich nicht die Ressourcen habe, einzeln aufwendige Spezial-UIs zu schreiben. Die Engine bietet eine kompakte Reflection-Schnittstelle für Eigenschaften, Komponenten und Komponentenverwaltung. Der Editor kennt so fast nichts von der Engine und die Engine bietet Ressourcen-Verwaltung, Entities etc. einfach durch diese Schnittstelle an. Hat den Vorteil, dass die meiste neue Funktionalität ohne weiteres Zutun direkt im Editor landet. In der Entwicklung abseits des Editors läuft natürlich alles uneingeschränkt durch die normalen API-Schnittstellen, ohne Indirektion durch das Reflection-System.

Die Test-Modelle sind in der Tat in Blender hingehuddelt. Vielleicht suche ich mir ja irgendwann kompetente Grafiker. ;)

Noch ein Rat zum Schluss: Hütet euch vor frühzeitiger Spieler/Physik-Integration, sonst wird jeder Test zum Jumping Puzzle. :P

Anmerkung: ArtificialMind hat mich gestern dazu bewegt, FXAA zu integrieren. Entgegen meiner Vorurteile funktioniert Post Processing Anti-Aliasing auf "normaler" Geometrie gar nicht schlecht.

CodingCat hat geschrieben:Anmerkung: ArtificialMind hat mich gestern dazu bewegt, FXAA zu integrieren. Entgegen meiner Vorurteile funktioniert Post Processing Anti-Aliasing auf "normaler" Geometrie gar nicht schlecht.

Endlich! Das Aliasing hat mich vorher immer fast verrückt gemacht …

CodingCat hat geschrieben:Entgegen meiner Vorurteile funktioniert Post Processing Anti-Aliasing auf "normaler" Geometrie gar nicht schlecht.

Es wird auf sämtlichen geradlinigen, lokalen Kontrastunterschieden der Luminanz von Nicht-sRGB-Render-Targets gut funktionieren. ;)

Ich habe soeben die verbleibenden 3K LOC Alt-Code aus der Engine gelöscht; nach einem halben Jahr Kernsanierung habe ich nun endlich wieder von allem eine einzige vollständige Version. Das öffentliche Repository ist aktualisiert. Wenn ich jetzt noch die externen Bibliotheken (Qt!) in eine halbwegs zahme, ohne große Umstände kompilierbare Form bekäme, wäre ich tatsächlich nahe an einem ersten, out-of-the-box lauffähigen Release.

Bis dahin ist dieses "Release" weiterhin für die wenigen Hochinteressierten, die tatsächlich ab und an ihre Nase in fremden Code stecken. Von Interesse könnten hier die neuen datenorientierten Klassen für Entities und Mesh-Rendering sein. Diese setzen um, was ich in diesem Thread vor einiger Zeit skizziert hatte. Ich habe das Gefühl, hier langsam eine akzeptabel kompakte Form zu erreichen, allerdings würde ich die manuelle Indexschieberei gerne noch etwas minimieren.

Von Interesse könnte auch die Umsetzung von Hot Reload/Hot Swap sein, die ein einfaches Bus-System und regelmäßige Commit-Aufrufe nutzt, um auf aktualisierte Nachfolger bestehender Ressourcen zu reagieren.

Grauen findet sich in meinem Versuch, alle drei Lichttypen auf einmal über ein Template zu lösen; die Kombination von komplexer Rendering-Logik mit Datenorientierung und C++' Template-Syntax sorgt hier für maximales Programmiererglück.

Die aktualisierte Dokumentation ist möglicherweise noch weniger hilfreich als beim letzten Mal; ich hoffe fest darauf, im Laufe des Jahres eine lauffähige Projektmappe mit aussagekräftiger Beispielanwendung einchecken zu können.

Ja, hört sich schon cool an. Hätte ich jetzt einen Monat oder so Zeit und keine anderen Projekte, würde ich mir das schon alles mal gerne komplett angucken und mich inspirieren lassen. Aber ich fürchte, ein kurzes Überfliegen und Probekompilieren wird kaum etwas bringen, und sehr viel mehr Zeit habe ich leider nicht.

Geht mir genauso. Könnte spannend sein, die Konzepte zu studieren und im Zusammenspiel zu erleben. Aber die Zeit habe ich nicht, mich jetzt in diese Massen fremder Gewohnheiten und Gepflogenheiten einzuarbeiten.

Mir fällt es einfach schwer, deinen Code zu lesen. Das mag einerseits an persönlichen Gewohnheiten meinerseits liegen. Aber ich finde es schwierig, deine Konzepte aus deinem Code zu extrahieren.
Und da du alles aus c++ herausholen möchtest, was geht, leidet meiner meinung nach die Lesbarkeit und Verständlichkeit. Dazu kommt noch: eine 1000-Zeilen-Datei ist schwierig zu überfliegen. Vielleicht bin ich auch einfach zu blöd bzw. habe halt nicht genügend Zeit.

Gruß Kimmi

Um das klarzustellen: Ich erwarte hier von niemandem, meinen Code zu studieren; ich lese ja auch nicht permanent den Code von anderen. Ich möchte den Code auch nicht als Ideallösung hinstellen, vielmehr ist er unter sehr spezifischen Gesichtspunkten entstanden, welche ich in meinen vielzähligen Beiträgen in diesem Forum bisweilen angedeutet habe. Ich stelle meinen Code online, um ein Beispiel für die mögliche Umsetzung dieser Punkte in einem größeren Gesamtprojekt zu bieten. Schlussendlich ist dieses ganze Projekt auch ein großes Experiment zur eleganten oder weniger eleganten Umsetzbarkeit oder Nichtumsetzbarkeit, Vereinbarkeit oder Unvereinbarkeit von systemischen Idealvorstellungen wie Effizienz durch datenorientierten Entwurf, langfristige Stabilität durch objektorientierten Entwurf (Modularität, Zustandsminimierung, Wiederverwendbarkeit, Einfachheit ...), Entkopplungsmöglichkeiten in C++ etc. Meine Suche ist hier nie abgeschlossen; ich hoffe, für einige dieser Punkte einigermaßen elegante Lösungen gefunden zu haben; und ich hoffe, für einige Punkte in Zukunft noch bessere Lösungen zu finden. Schlussendlich ist das Projekt groß, und auch meine Zeit begrenzt. ;)

kimmi hat geschrieben:Und da du alles aus c++ herausholen möchtest, was geht, leidet meiner meinung nach die Lesbarkeit und Verständlichkeit. Dazu kommt noch: eine 1000-Zeilen-Datei ist schwierig zu überfliegen. Vielleicht bin ich auch einfach zu blöd bzw. habe halt nicht genügend Zeit.

Dass Konzepte wie Datenorientierung mit der zusätzlichen Einführung von Speicherverwaltung und Speicherplatzierung in ohnehin schon nicht-triviale Probleme die Dinge nicht einfacher machen, ist klar. Meine Hoffnung ist hier, mit Datenstrukturen wie dem Structure-of-Array-vector Lösungen gefunden zu haben, die den Code nicht allzu sehr verschlimmern. Ich vermute, du sprichst mit der 1000-Zeilen-Datei die MeshControllers/LightControllers an; hier wäre es definitiv schön, noch eine Unterteilung in Render-Logik und Controller-Verwaltungslogik hinzubekommen. Meine Erfahrung mit datenorientiertem Entwurf ist noch sehr kurz und ich hoffe, dass ich die in meinem Code damit momentan einhergehende Kopplung von allgemeiner Verwaltung und spezifischer Logik noch etwas minimiert bekomme.
Davon abgesehen bin ich leider über den Punkt hinaus, an dem ich immer alles hochverständlich in winzige Häppchen teilen kann; irgendwann muss einfach ziemlich viel Funktionalität her, darunter dynamische Verwaltung und Reflection für den Editor, Ressourcen-Integration für Hot Swap etc. Hier denke ich, dass der Code bei näherem Hinsehen durchaus seinen Schrecken verliert, denn abgesehen von der großen Menge an zu erfüllenden Aufgaben sind die Zuständigkeiten in der Regel doch sehr klar verteilt.

Ich finde deine Ansätze auch oft sehr hilfreich, nur es kostet halt zur Zeit noch recht viel Zeit, diese heraus zu extrahieren :). Da sehe ich in deinem Code noch Potential.

Gruß Kimmi

kimmi hat geschrieben:Ich finde deine Ansätze auch oft sehr hilfreich, nur es kostet halt zur Zeit noch recht viel Zeit, diese heraus zu extrahieren :). Da sehe ich in deinem Code noch Potential.

Die Frage ist, inwieweit das Code für sich leisten kann. Abgesehen von einigen, teilweise bereits genannten Hot Spots, sehe ich nicht, inwieweit Änderungen am Code dies noch allzu stark verbessern könnten. Hier müsstest du wohl konkreter werden. ;)

Ok, ein Beispiel, was ich innerhalb von 1 Minute suchen gefunden habe: MeshController::Commit hat eine Looptiefe von etwa 4 ohne einen für mich hilfreichen Kommentar. Dazu sind viele structs gestreut, deren Sinn man nicht auf Anhieb versteht. Als Anwender muß ich mehrmals darüber nachdenken, was das alles soll und was da passiert. Sollte ich da einen Bug fixen müssen, hätte ich eine ziemlich große Einarbeitungszeit ( wo finde ich was etc. ).
Such doch mal nach Code-Reading in Google. Da findest du viele Dinge, die gerade auf Lesbarkeit abzielen, wenn du Hinweise haben möchtest.

Versteh mich nicht falsch, ich will nicht rummäkeln. Ich sehe das halt an den von dir hier gezeigten Stellen als ein Problem für mich und wollte dir einfach mal Feedback geben. Und das ist halt auch nur mein Feedback weil meine Meinung.

Gruß Kimmi

kimmi hat geschrieben:Ok, ein Beispiel, was ich innerhalb von 1 Minute suchen gefunden habe: MeshController::Commit hat eine Looptiefe von etwa 4 ohne einen für mich hilfreichen Kommentar. Dazu sind viele structs gestreut, deren Sinn man nicht auf Anhieb versteht. Als Anwender muß ich mehrmals darüber nachdenken, was das alles soll und was da passiert. Sollte ich da einen Bug fixen müssen, hätte ich eine ziemlich große Einarbeitungszeit ( wo finde ich was etc. ).
Such doch mal nach Code-Reading in Google. Da findest du viele Dinge, die gerade auf Lesbarkeit abzielen, wenn du Hinweise haben möchtest.

Die structs sind eigentlich nicht gestreut, sondern in ihrer Verschachtelung ein exaktes Abbild der Datenstruktur, die jeweils aufgebaut wird. Dass sich in der Mitte nochmal ein struct-Block findet, liegt daran, dass die entsprechende Datenstruktur erst im dort nachfolgenden Code Verwendung findet. Dass du im Falle einer Veränderung darüber nachdenken müsstest, ist unzweifelhaft, immerhin ist die Datenstruktur alles andere als trivial. Als bloßer Anwender siehst du vom Inhalt der gesamten Datei im Übrigen nichts. Es ist klar, dass der Code wenig dokumentiert ist; immerhin steht nicht in Aussicht, dass in allzu naher Zukunft viele Fremde daran werkeln werden.

Dass es wünschenswert wäre, die Datei nochmal in einen Verwaltungs- und einen Rendering-Teil zu unterteilen, hatte ich ja bereits angesprochen, da sind wir uns denke ich einig. Spannender ist deine Bemerkung zur Komplexität von Commit. Ich weiß, dass es zu den weit verbreiteten Best Practices gehört, verschachtelte Schleifen in eigene Funktionen/Methoden zu verpacken. Die dort aufgebaute Datenstruktur enthält einige Querverbindungen via Zeiger/Indizes; das was dort aufgebaut wird, hat einen starken Zusammenhang. Ist es nun transparenter, die Datenstruktur in wenigen kompakten Blöcken aufzubauen, oder den Aufbau gemäß Best Practices in kleine überschaubare Häppchen zu unterteilen?

Da du es so konkret ansprichst, hier das Experiment: Commit() vorher und nachher.

Auffällig ist, dass der Code vorher wesentlich kompakter (überschaubarer?) war. Dafür sind die Geltungsbereiche nun wesentlich klarer. Relevante Information wird in den Funktionsköpfen wiederholt (ins Gedächtnis gerufen?). Der Code enthält neben trivialen Verben nun auch kurze Halbsätze in den Funktionsnamen, die eine gewisse Absichtserklärung enthalten. Fazit: Der Ablauf ist nun klarer. Ist die Datenstruktur als Ganzes, mit ihren Zusammenhängen und Invarianten, ebenfalls leichter zu erfassen geworden?

Ich schau mir das später durch, gerade habe ich leider nicht die Zeit. Die Frage wegen Kompaktheit gegenüber kürzeren Funtionen / Methoden ist schwierig, da viel eigener Geschmack dabei. Kompakter lässt einem in der Tat den Algorithmus besser durchschauen. Allerdings verliere ich ab einer gewissen Komplexität die Übersicht. Ich denke, man muß beides gegeneinander abwägen.
Super finde ich, daß du so offen mit dieser Kritik umgehst.

Wegen den Structs: da hast du recht, sie bilden die Datenstruktur ab. Wenn man das erst mal gescnall hat, ist alles etwas leichter zu rallen :).

Gruß Kimmi

Tatsächlich ist DOD ja ein Design-Konzept wie jedes andere auch, unterscheidet sich aber in Struktur und prinzipiell von üblichen imperativen OOP-Ansätzen. Ich nutze seit gut einem Jahr DOD in einem Projekt, in dem ich in Echtzeit Driver/Application-API Calls überwache und daraus einen analysierbaren Datenstrom forme und habe seither viele von Cats Tipps und Tricks, die er hier im Forum preisgibt, ins Programm eingebaut. Klar, Cats Code könnte an einigen Stellen noch etwas übersichtlicher gestaltet werden, aber in welchem großen Projekt findet man nicht solche Stellen? Die geringe Lesbarkeit für andere Entwickler ergibt sich meines Erachtens nach, eher daraus, dass hier ein überwiegend unbekanntes Konzept verwendet wird, welches sich fundamental von üblichen Ansätzen in der C++/Java/C#-Welt unterscheidet. Ähnlich wie bei funktionalen Programmiersprachen erlangt man als Entwickler die Fähigkeit den entsprechenden Code schnell zu verstehen, erst mit Übung und Praxiserfahrung in der jeweiligen Sprache.

Ähnlich ist es meines Erachtens nach bei DOD auch, man braucht halt etwas Übung, um die dort üblichen Pattern und Abläufe zu verstehen. Bei anderen DOD-Projekten aus meinem Bekanntenkreis, die um Längen nicht an Cats C++-Expertise herankommen, ist die Lesbarkeit alleine durch die mangelnde Erfahrung stark beeinträchtigt. Mangelnde Lesbarkeit ist also kein DOD-Problem, sondern eine Schwäche des jeweiligen Teams. Ein weiterer Punkt, den ich an DOD sehr schätze ist, dass der Code durch die Orientierung am Datenstrom meist sehr selbsterklärend ist, sobald man DOD etwas kennengelernt hat. Mir reicht üblicherweise bei solchen Projekten eine reine API-Dokumentation.

Bin ich eigentlich der einzige, der regelmäßig durch Cats LeanCpp und Breeze-Repositories stöbert?