lowkey42 / mirrage Goto Github PK

Voxelisierung und Sichtbarkeitsberechnung implementieren und Qualität/Performance evaluieren.

evtl. relevant => Globale Beleuchtung im Bildraum unter besonderer Berücksichtigung der
Sichtbarkeitsbestimmung

Basierend auf: http://casual-effects.com/research/McGuire2016Transparency/McGuire2016Transparency.pdf

Referenziertes Schatten-Verfahren: http://casual-effects.com/research/McGuire2011CSSM/McGuireI3D11Shadows.pdf

Die globale Beleuchtung könnte sich evtl. ausreichend über Berechnung eines Ambient-Lights basierend auf der durchschnittlichen diffusen GI approximieren lassen.
Alternativen wären noch:

• Sampling der Nachbarschaft und Durchschnitt der besten Matches (Position + Normale). Aber vermutlich zu langsam. evtl. auf höherem MIP-Level?
• Fallback zu Light-Probes. Wäre aber wahrscheinlich ein zu auffälliger Bruch mit der restlichen GI und würde viel zusätzlichen Aufwand bedeuten

Aufbau ähnlich wie im GDW-Prototyp, ggf. noch weitere Unterteilung in Sound-Boards (z.B. eins pro Gegner-Typ jeweils mit Angriffs, Treffer, etc. Sounds), die dynamisch geladen werden können.

Möglicherweise gute Basis dafür: https://github.com/jarikomppa/soloud

• Velocity-Buffer generieren und für Reprojektion heranziehen
• Interpolationsfaktoren für TAA und GI-Glättung reevaluieren

https://knarkowicz.wordpress.com/2016/01/09/automatic-exposure/

• Avg. Luminance über Histogram bestimmen und übermäßig dunkle+helle Bereiche abschneiden, damit die relevanten Teile korrekt belichtet werden. Evtl. mit einem Storage-Buffer performant machbar.
• ggf. zusätzliche Gewichtung nach Distanz zum Zentrum des Bildschirms, falls das nicht ausreich
• "Exposure compensation curve" wäre dabei ebenfalls eine sinnvolle Erweiterung

Evaluierung und ggf. Integrierung von PhysX:

http://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/BuildingWithPhysX.html

• Stateful asset::Loader für Modelle/Texturen/etc.. Evtl. über "static constexpr" Variable festlegen und der Asset-Manager hält intern eine Map von weak_ptr auf die entsprechenden Loader-Instanzen, die von außen gesetzt werden können/müssen.
• Ersatz für die intern verwendete unordered_map finden, der Thread-Safe und möglichst effizient ist.
• Boost-ASIO für das eigentliche laden der Assets evaluieren. Async++ integrieren (einfachere API und Fork/Join der Task erlaubt einfachere Abbildung komplexerer Assets). Auflösung der AIDs und Lokalisierung der Dateien aber denke ich auf jeden Fall erstmal synchron lassen.
• Update auf PhysicsFS 3.0 ( https://icculus.org/pipermail/physfs/2017-September/001247.html )
• evtl. Möglichkeit vorsehen das selbe Asset mit unterschiedlichen Typen zu laden
• evtl. Bessere Möglichkeit um Anwendung über Reload/Änderungen zu benachrichtigen (z.B. Shader-Reload => Pipeline/Renderer neu bauen)
• evtl. zusätzlich asset::Locator einführen um auch andere Quellen als PhysicsFS zu erlauben (z.B. fehlende Daten von einem Server anfordern). Lässt sich evtl. auch über neue Funktionen in PhysicsFS erschlagen

Untersuchen ob höhere MIP-Level evtl. mehr/weniger zum Gesamtausgaben beitragen und ggf. die Sample-Anzahl entsprechend Variieren.

Klassisches Importance-Sampling ist vermutlich nicht direkt mit dem aktuellen Sampling-Pattern vereinbar aber eine einfache Verbesserung der Trefferquote könnte evtl. bereits dadurch erzielt werden, dass die Winkel der Punkte (in Polarkoordinaten) in Richtung der Screen-Space Normale des Ausgangspunktes verschoben (gewichtet mit 1-Z).

Unterstützung für Hot-Reloading von Vulkan-Ressourcen (Texturen, Modelle, Shader, etc.). d.h. asynchrones laden der neuen Daten, austausch mit alten (threadsafe!) und ggf. neu bauen von Abhängigkeiten (Pipelines, etc.).

ggf. muss dafür die aktuelle Architektur der Reload-Funktion auch nochmal überdacht werden.

Allgemein:

• Zumindest die wichtigsten Module (ecs, core, asset-manager und input) kommentieren und ggf. aufräumen.

ECS:

• Iterator über mehrere Components. z.B.: for(auto&&[transform, mesh] : ecs.list<Transform_comp, Mesh_comp>()) {...}
• Vereinfachte Syntax für simple Components (nur public Member), die ohne manuelle Serialisierung auskommt.
• Small_component (ohne Referenz zu Owner/Manager), die nur in Iteration benutzt werden können
• Tag_component, mit T=[void, int, enum, ...] für Zeug wie Enemy_tag, Culling, ...
• Laden/Speichern von Entities noch mal checken (sollte nur ein Diff zum Blueprint sein, falls vorhanden) und einen Converter Ogre-Scene => Entity-File schreiben damit Blender-Scenen zumindest indirekt importiert werden können.

Input:

• Input-System besser in Screen-Manager integrieren, so das Eingaben nur dann an vorherige Screens weitergereicht werden, wenn der letzte sie nicht verarbeitet hat. Vor allem auch für UI-Inputs. Idealer Weise ähnliche Funktionalität auch innerhalb eines Screens (erst UI, dann Steuerung, ...).

Als Alternative zu Lambert evaluieren (Performance vs. Qualität)

Einfaches Animationssystem. Beispiel: https://youtu.be/LNidsMesxSE

Anschließend erweitern um:

• Blending zischen mehreren Animationen (optional synchronisiert)
• Einfache Schnittstelle zur Steuerung + Priorisierung von Animationen aus Gameplay-Code (evtl. mit State-Machine)
• Optionen für unterschiedliche Interpolationsverfahren (Linear, Bicubic, Feder, ...)
• Programmatische Animationen: Look-At (getrennt für Oberkörper/Kopf/...), evtl. auch einfaches IK-System

Könnte beim Offset der Sampels für Diffuse-GI und SAO und evtl. auch bei den direkten Schatten potentiell bessere Ergebnisse liefern:

• https://www.solidangle.com/research/dither_abstract.pdf
• https://cseweb.ucsd.edu/~ravir/6160/papers/importancesampling.pdf
• http://momentsingraphics.de/?p=127
• https://80.lv/articles/ssrtgi-toughest-challenge-in-real-time-3d/

Simpler Level-Editor mit Basisfunktionalität:

• Laden/ Speichern von Leveln: https://github.com/mlabbe/nativefiledialog
• Einfügen/ Entfernen/ Verschieben/ Skalieren und Rotieren von Entities
• Undo/Redo
• Snap to Grid, etc.
• Optional mehrere Kameras (3D + Wireframe von X,Y,Z Richtung), evtl. auch für Debugging interessant wenn auf beliebige Kameras/RenderTargets erweiterbar
• Optional editieren von Entity-Components über UI-Menü

Außerdem Nice-To-Have: Integration mit Mesh-Converter, d.h.

• eine möglichst einfache Oberfläche um Modelle zu laden, die Material-Texturen zuzuordnen (ggf + Defaults für alles Metall/Nichtmetall) und die Animationen auf IDs zu mappen
• eine obj/fbx Datei direkt in das Editor-Fenster ziehen können um es in einem Schritt zu konvertieren, einen Dummy Entity-Blueprint zu erzeugen und in das Objekt in das Level einzufügen

evtl. basierend auf:

• https://users.cg.tuwien.ac.at/zsolnai/gfx/separable-subsurface-scattering-with-activision-blizzard/
• https://users.cg.tuwien.ac.at/zsolnai/wp/wp-content/uploads/2014/12/ssss.pdf
• http://www.iryoku.com/translucency/downloads/Real-Time-Realistic-Skin-Translucency.pdf

siehe: http://www.cim.mcgill.ca/~derek/files/McGuire2017LightField-GDCSlides.pdf

Könnte eine gute Möglichkeit sein um die Artefakte in First/Third-Person Situationen stark zu reduzieren.
Die meisten Artefakte in diesen Situation sind darauf zurück zu führen, dass (a) Lichtquellen nicht im Sichtbaren Bereich liegen oder (b) Bereiche so wenig erfolgreiche Samples haben, dass in den ersten Frames, in denen sie sichtbar werden, nicht relevante Bereiche aus früheren Frames durch den temporalen Filter mit einfließen.

Die Kosten liegen in einem zu vernachlässigenden Bereich. Das ganze ist zwar auf statische Light/Shadow-Caster beschränkt aber das sollte durch die zusätzlichen Bounces durch das SSGI auszugleichen sein.