Themen

Themenwahl ist selten eine geradlinige Sache, daher soll in diesem issue gesammelt werden welchen Themen jemanden interessieren. Heißt: Jeder möge in den nächsten Tagen mal in diesem issue posten was er/sie gerne machen möchte im Zuge dieses Projekts.

Danach können wir dann überlegen wie wir alles (oder das Meiste) davon in einem Projekt zusammenbringen.

changed due date to April 12, 2021

Mich interessiert: Variable Rate Shading, Mesh Shader, indirect draw/dispatch und raytracing (wobei ich dafür die Extension aber keine Hardwarebeschleunigung habe)

Mich würden auch die Mesh Shader reizen. Leider klappt das bei mir nicht wegen fehlenden Extensions. Aber ich hätte Interesse einen alternativen Compute Shader für Culling oder auch die Funktionen eines Mesh shaders einzubinden.

Ich schließe mich Variable Rate Shading, Mesh Shader und Indirect Draw an. Habe dieselbe Grafikkarte wie Alex, sollte also bei uns auch von den Extensions passen.

Cool wäre eine Art Viewer, in dem man sich alle möglich zum Beispiel Buffer anschauen kann, verschiedene Shader ein/ausschaltet, HDRIs durchwechseln, Materialien an den Objekten ändern, easy Szenen laden oder ggf. auch irgendwelche Datenstrukturen wie Voxel etc. zeigen kann.

Am Ende soll man sich dann nur komplett auf die Grafikpipeline konzentrieren können ohne sich mit solchen Details befassen zu müssen.

Vielleicht könnte man die Schritte in der Pipeline als Node-Graph modellieren? Bzw. einige der Shader als Nodes konstruieren, die sich modular kombinieren, ein- und ausschalten lassen.

Sowas fände ich wirklich nützlich. Die Synchronizationsstrukturen in Vulkan würden sowas auch zum Großteil parallel ermöglichen.

Zum Raytracing: vielleicht wäre es cool die Raytracing Effekte getrennt zu implementieren (also z.B. AO, Reflektionen, Schatten getrennt) und für alle einen Fallback mit traditioneller Rasterisierung bereitzustellen.

Soll das Ziel eigentlich sein, eine Alternative zum CVK zu bauen? Dann sollte man auf jeden Fall den Fokus darauf legen, zunächst die grundlegenden Features des CVKs alle abzubilden.

Generell würde mich auch Raytracing interessieren.

RTX GPU ist vorhanden und ich habe auch noch ein Intel Macbook, falls wir OSX unterstützen wollen. Wobei Raytracing da sicher nicht gehen wird.

Wenn wir das CVK ersetzen wollen, wäre das definitiv, worauf man achten sollte. Wir müssen trotzdem nicht unbedingt das Software-Design übernehmen. Aber das Framework sollte dann die gleiche Funktionalität abdecken, um möglichst einfach Anwendungen zu entwickeln.

Ich würde mich auch für was Viewer-mäßiges interessieren. Oder auch so eine Art eigener Shader Graph, wo man einzelne Bausteine zu einem Shader zusammenstellen kann.

Dachte sonst auch an einen Mesh Animator und Modellierungstool, welche man dann uni-intern verwenden könnte. Aber vermutlich würde das eher den Rahmen sprengen. Zumindest stelle ich es mir nicht so einfach vor. ^^;

Raytracing würde meine Grafikkarte auch unterstützen, wo ich auch was machen könnte.

Shader Graph a la Blender o.ä. stelle ich mir recht schwierig im Sinne von Umfangreich vor. Zumindest wenn es um die grafische Umsetzung geht.

Eine Stufe 'einfacher' wäre zumindest eine Art 'intelligente Shader Klasse', die es vereinfacht In-/Out-Variablen/Objekte von einem Shader zum nächsten zu leiten. Also quasi ein abstrakter Shader Graph ohne eine GUI. Prinzipiell bracht man aber sowieso eine solche abstrakte Klasse um die Basis für einen 'richtigen' Shader Graphen zu setzt.

Cool wäre so ein Ding bei dem die In/Outs direkt aus dem Shader Code in eine Klasse geparst werden, sodass man sowas wie Shader x = new Shader("path/to/shader.vert"); anlegt und dann direkt aud x.color o.ä. zugreifen kann.

Also generell wäre ich auch für ein Framework, was man dann für vieles einsetzen kann, wobei alle oben gennanten Features (Raytracing, Compute Shader, ermöglichen von Rasterisierung+RT, indirect draw/dispatch etc.) interessant sind, also hätte ich nichts dagegen die als Zusatz mit einzubauen. Aber ich bin da für alles offen, falls wir irgendwas spezifisches machen wollen.

Ich hätte auch die Grafikkarte für alles.

Die Themen, die mich im besonderen interessieren sind:

• Indirect Draw/Dispatch
• Adaptive Rate Shading
• Parallelisierung von Datentransfer und Rendering (intelligente Aufteilung von secondary command buffers)

Ich find's super, dass sich hier jetzt schon einige Projektideen ergeben haben; da will ich mich gleich mal anschließen:

Mir wäre es wichtig, dass unser Projekt auch in Zukunft nützlich für die CG ist, ähnlich wie das CVK-framework aber nicht unbedingt als Ersatz dafür. Die Vorschläge zu einem scene-viewer haben mich auf einige Ideen gebracht, die mir viel besser gefallen als meine ursprünglichen Ansätze (:

Mir schwebt ein Tool vor, das einerseits

• eine Szene laden und
• rendern kann (wie der scene-viewer, der bereits vorgeschlagen wurde),
• andererseits das Experimentieren mit Rendertechniken sehr einfach macht.

Was die Szenen angeht würde ich direkt schonmal GLTF nennen; dabei handelt es sich um einen Khronos-Standard zum effizienten Austausch beliebig großer Szenen zwischen tools (z.B. blender und einer Game-Engine). GLTF erlebt seit einiger Zeit starkes Wachstum und ist auf dem besten Weg zu einem Standardformat von 3D-Szenen wie jpeg es für Bilder ist.

Beim rendern der Szene denke ich an die Darstellung der Meshes in mehreren (synchronisierten) viewports, die nebeneinander z.B. eine Wireframe-Ansicht und eine Ansicht mit PBR-shading erlauben. Es wäre ein Schwerpunkt des tools, neue viewports aufzumachen, die die Szene in einem von vielen verfügbaren render-modes zeigen. Neben den viewports könnte es noch Ausgaben für render-Statistiken geben sowie den output der debug layer etc. Und natürlich Ansichten der genutzten buffer, geladener assets, etc.

Mit dem Experimentieren mir Rendertechniken meine ich, dass es leicht ist neue render-modes hinzuzufügen. Denkbar wäre eine Abstraktion über vulkan pipelines: Ich möchte z.B. eine bestimmte Art des forward renderings austesten und erstelle dafür einen neuen render-mode (z.B. indem ich eine neue Klasse rForwardStylized von RenderMode ableite); fortan wäre dieser render-mode bei der erstellung eines viewports auswählbar. Dabei würde ein neuer render-mode eine vulkan pipeline definieren, in der man jeden bereits vorhandenen shader nutzen kann sowie neue shader schreiben und möglichst leicht und übersichtlich den I/O zwischen shadern und render targets definieren.

Für uni-interne Projekte wäre das quasi ein Sandkasten in dem Studenten für Übungsaufgaben relativ schnell mit eigenem shader code experimentieren können, selbst erstellte Szenen analysieren oder für größere Projekte in Seminaren oder Praktika auch mal ganze Renderer (in Form von neuen render-modes) erstellen.

Außerdem denkbar wäre es, die Szene und deren Objekte über ein interface so weit wie möglich auch außerhalb der shader Zugänglich zu machen; beispielsweise jeses Mesh als winged-edge-struct iterierbar zu machen. Das würde es erlauben diverse Techniken aus der CG2/3 auszuprobieren indem man irgendwas an der Topologie herumspielt und einen vorhandenen render-mode nutzt um das Ergebnis anzuzeigen.

So wie du die Details von deiner Tool-Idee beschreibst hab ichs mir auch in etwa vorgestellt.

Eine weitere Idee wäre vielleicht auch etwas in Richtung Shader Toy. Das kann man dann auch mit @vaka1997 's Idee vom Shader Graphen verbinden.

Wenn ich mich recht erinnere ist shader-toy limitiert auf einen einzelnen ESSL-shader und die Freiheit beschränkt sich auf eine vielzahl an inputs.

Eine mögliche Erweiterung in Bezug auf Vulkan wäre es, die pipeline vom user definieren zu lassen und dabei auch compute shader und raytracing zu ermöglichen.

Es kann allerdings gut sein, dass ich shadertoy Unrecht tue; ist lange her dass ich damit herumgespielt habe.

Ich glaube zumindest Raytracing und Compute-Shader sollten auch mit dem Tool SHADERed abgedeckt werden. Vermutlich sollten wir auch mehr berücksichtigen, was einem beim entwickeln und programmieren hilft.

Für relativ schnelles Testen von Shadern gibt es bereits ein paar Tools. SHADERed ist auch frei und open-source. Für das Debuggen kann man NSight, CodeXL oder Renderdoc verwenden.

Ich würde daher vermuten Hauptaufgaben für das Framework wären die Reduzierung der Komplexität und Verringerung der Fehlerquellen. Also z.B. wenn man eine Pipeline anlegt und ein Shader nicht richtig funktioniert, könnte man einbauen, dass man zu einem Fallback Shader wechseln kann, der funktioniert.

Management von Fenstern oder UI bei der Nutzung des Frameworks sollte auch möglichst reduziert werden. Vermutlich verwenden wir sowas wie ImGUI, allerdings sind auch da noch potentiell Probleme.

Ich persönlich finde auch Multi-Threading sehr spannend und fände interessant, dass ins Framework zu integrieren, ohne dass man später beim verwenden selbst auf Synchronization achten muss.

Also das Hauptaugenmerkt sollte bei unserem Projekt eh nicht sein ein tool zu entwickeln das zwingend neu, oder zu bestehenden tools wie renderdoc konkurrenzfähig, ist. In erster Linie geht es darum, das wir alle etwas lernen (und dazu gehört, dass wir an etwas arbeiten, was für alle irgendwie motivierend ist und dessen Entwicklung sich auch gut aufteilen lässt). Für mich steht an zweiter Stelle der Nutzen für die CG bzw. den Studiengang, aber das ist schon wieder subjektiv und sollte nicht als echte Vorraussetzung für eine Projektidee gesehen werden (oder?).

Ich persönlich finde auch Multi-Threading sehr spannend und fände interessant, dass ins Framework zu integrieren, ohne dass man später beim verwenden selbst auf Synchronization achten muss.

Dito. Ich hatte da die Idee, dass jeder viewport in einem eigenen thread läuft und einen eigenen secondary command buffer hat.

added 🤯 Discussion label

added 🍪 ToDo label

removed 🍪 ToDo label

added 🍪 ToDo label

removed 🍪 ToDo label

closed

mentioned in issue #6 (closed)