[Projekt] breeze 2.0

[kimmi]

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

Nein, daher mein Feedback :).
Ich kenne DOD noch aus alten Fortran-Tagen, wo dieses Design-Konzept ganz und gäbe ist. Auch wirst du es in vielen C-Projekten finden. Womit bewiesen wäre: kommt alles mal wieder, funktinierende Konzepte kommen vielleicht mal aus der Mode, aber selten in die Jahre.

Gruß Kimmi

[j.klugmann]

Große C-Projekte? Ich kenne kein einziges Open-Source Projekt.

[kimmi]

Blender? War meines Wissens mal komplett in c, keine Ahnung, ob das immer noch so ist.

Gruß Kimmi

[dot]

Große C-Projekte? Ich kenne kein einziges Open-Source Projekt.

Linux? ;)

[Schrompf]

Und was ist daran Daten-orientiertes Design?

[dot]

Ich dachte es ging um große Open Source Projekte in C... ;)

[kimmi]

Nun ja, schaut man sich so manchen Datenentwurf in C bzw. anderen prozedualen Sprachen wie zum Beispiel Fortran an, wird genau dieses gemacht. Ich in meinem ersten Job beispielsweise habe genau den daten-orientierten Entwurf auf Performance-Gründen zu benutzen gelernt. Lesbar war das dann leider nicht immer. OOD brachte dann verständlicheren Code hervor, der allerdings nicht so cache-freundlich sprich nicht so performat war. Nun entdeckt man halt auch in c++ die alten Tricks aus Fortran wieder.

Gruß Kimmi

[CodingCat]

Nunja, Cache-Optimierung von Datenstrukturen ist ja weder neu, noch je "aus der Mode" gewesen. Das, was gerade als "Data-oriented Design" gehypet wird, ist zwar meines Wissens nach nicht klar definiert worden, geht aber wie ich das verstehe wesentlich mehr in Richtung Entwurf. Dazu gehört das Grundprinzip der Gruppenverarbeitung, wo es mehrere Objekte gleichen Typs gibt, sowie die Bevorzugung direkter expliziter Ausformulierung gegenüber einer sukzessiven Durchlöcherung abstrakter Subsysteme und der damit verbundenen Akkumulation von Objektindirektionen. Schlussendlich steht dahinter die Erkenntnis, dass jede Abstraktionsebene auch eine Barriere darstellt, welche die Datenverarbeitung und den zugehörgigen Code tatsächlich umständlicher (nicht nur ineffizienter) macht, sofern diese Abstraktion nicht tatsächlich notwendig ist (weil tatsächlich polymorphe Objekte verarbeitet werden). Weiterhin lässt sich die Abstraktion selbst im polymorphen Fall oftmals eine Ebene höher schieben (Objektgruppen statt individueller Objekte), wobei durch den Wegfall der Abstraktion innerhalb der Gruppe der Datenzugriff wesentlich erleicht wird, ohne dabei die Abstraktion selbst zu verlieren.

Soweit die Theorie. In der Praxis möchte man dann natürlich auch die Möglichkeiten der Cache-Optimierung mitnehmen, was wieder viel Indexschieberei bedeuten kann. Hierbei handelt es sich jedoch prinzipiell schon um einen Optimierungsschritt, nicht mehr direkt um den datenorientierten Entwurf.

Nebenbei: Der Rettungsring jeder leeren Szene: Planares Wasser. ;)

(Ich muss mich unbedingt mal mit Normal Filtering / Specularity Anti-Aliasing befassen. Dieser Artikel sieht ganz brauchbar aus.)

[kimmi]

Die Art des Entwickeln in zum Beispiel Siumulationen in F77 richtet sich nach den Datenstrukturen, also genau wie in der von dir angewandten Art und Weise. Man schaut sich die Daten an, dann die Operationen auf die Daten, mit dem Input entwirft man den Code. Dann optimiert man. Deswegen kriegen heute F77-Entwickler auch ein sehr ansehnliches Gehalt, wenn sie alten Code aufarbeiten bzw. erweitern dürfen :). F77 ist nämlich nicht wirklich lesbar.

By the Way: Schicke Bilder...

Gruß Kimmi

[CodingCat]

Ein bisschen Parallax Mapping mit Tiefenanpassung (SV_DepthGreaterEqual) macht die Kantenwelt gleich viel glaubhafter.

(Billiges 16-Step-Ray-Marching mit stückweise linearer Höhenannahme. Korrekt skalierter Tangentenraum im Pixel Shader über Screen-Space-Derivatives konstruiert; für nicht-orthogonal texturierte Oberflächen bräuchte ich den Co-Tangentenraum; habe das hier aber noch nicht so weit durchschaut, dass ich die Skalierung der Co-Tangenten/Co-Bitangenten vollständig richtig hinbekomme.)

[CodingCat]

[...] habe das hier aber noch nicht so weit durchschaut, dass ich die Skalierung der Co-Tangenten/Co-Bitangenten vollständig richtig hinbekomme [...]

Nachtrag: Jetzt hab ichs, ist schlussendlich ganz einfach. Das, was im dort angegebenen Code fehlt, ist lediglich die Division durch die Determinante bei der Invertierung der 3x3-Matrix, die den Tangentenraum aufspannt. (Da der Code für Normal-Mapping gedacht ist, macht dort ein normierter Co-Tangentenraum wesentlich mehr Sinn als einer, der die absolute Skalierung der Texturkoordinaten respektiert.)

Ersetzt man im Angegebenen Code ...
float invmax = inversesqrt( max( dot(T,T), dot(B,B) ) );
... durch den Kehrwert der Determinante ...
float scale = 1.0f / dot(dp1, cross(dp2, N));
..., dann erhält man einen wunderschön skalierten Co-Tangentenraum, aufgespannt durch die zurückgegebene Matrix.

Mit der resultierenden Matrix ist dann auch die Transformation in nicht-orthogonale Tangentenräume kein Problem mehr. (Mein zuvoriger Ansatz: Im orthogonalen Fall reicht es aus, die Tangente und Bitangente mit dem Kehrwert ihrer jeweiligen Betragsquadrate zu skalieren, um den Co-Tangentenraum zu erhalten).

Toller Nebeneffekt dieser Mühen: Ich brauche ab sofort überhaupt keine vorberechneten Tangenten mehr, weder für Normal Mapping, noch für Parallax Mapping. Damit entfallen auch verlustbehaftete Kompressionen wie die Auslassung der Bitangenten, welche dann auch keine Korrektheit bei nicht-orthogonalen Tangentenräumen mehr erlaubt.

[Schrompf]

Sieht schick aus! Warum aber GreaterOrEqual? Sollten neue Pixel nicht *vor* den alten sein, also eine geringere Tiefe haben, wenn sie sichtbar sein sollen? Und zur Optik: je mehr Shader man drauf wirft, desto mehr sieht man den Texturen an, dass die Höhen/Normalen nur aus der Diffuse erzeugt wurden. Aber die Grafiker machen das grad alle so, CrazyBump und Konsorten laden dazu ja regelrecht ein. Wird dauern, eh das wieder rausgewachsen ist.

Den Trick mit den Screen-Space-Derivatives muss ich mir merken, das könnte speziell für dynamisch erzeugte Geometrie eine wichtige Sache werden.

[Krishty]

Er spricht nicht vom Vergleich, sondern von der Shader-Semantik (Conservative Depth Output). Die Tiefe über das Pseudoregister SV_DepthGreaterEqual auszugeben teilt der Hardware mit, dass die Tiefe, die man im Pixel Shader schreibt, größer oder gleich der Tiefe des interpolierten Dreiecks ist, das zum Rasterizer geschickt wurde. Dadurch können Pixel von der GPU teilweise verworfen werden ohne erst auf die Tiefenausgabe des Shaders warten zu müssen. (Tatsächlich ist es leicht komplizierter; siehe hier.)

[CodingCat]

Ganz genau, die virtuelle Geometrie liegt quasi unter der Oberfläche, d.h. Höhe 1 entspricht der tatsächlichen Oberfläche und Höhe 0 einer virtuellen Grundebene unter der Oberfläche. Entsprechend liegt virtuelle Geometrie allenfalls hinter der echten, nie davor, und die Hardware kann weiterhin Z-Culling vor Ausführung des teuren Parallax-Shaders durchführen.

Und zur Optik: je mehr Shader man drauf wirft, desto mehr sieht man den Texturen an, dass die Höhen/Normalen nur aus der Diffuse erzeugt wurden. Aber die Grafiker machen das grad alle so, CrazyBump und Konsorten laden dazu ja regelrecht ein. Wird dauern, eh das wieder rausgewachsen ist.

Tatsächlich habe ich die gezeigte Textur von CG Textures einfach einmal durch die CrazyBump-Eval gejagt. Fine-Tuning ist leider gerade nicht, weil meine Eval aufgebraucht war, bevor ich Zeit hatte, die entsprechenden Dinge zu implementieren. Das geht sicher noch hübscher, insbesondere mit etwas gefaketem AO, korrekten Parallax-angepassten Schatten; weiterhin sollten diffuse Texturen wohl von sämtlicher Shading-Information befreit werden etc. Dazu gab es übrigens gerade einen netten FMX-Vortrag von Crytek.

[Schrompf]

Ah, verstehe. Die GPU kann dann immernoch klassisch vorab den Tiefentest machen und muss nur nachher nochmal ran. Spannend.

Danke übrigens für den Vortrag-Link. Genau das meinte ich.