SSS Frust

[starvald]

Hallo liebes Forum,

Frust. Stichwort Translucent Shadow Maps und Subsurface Scattering. Ich will mich einfach nur mal auskotzen ;-)

Ich versuche seit einiger Zeit, Echtzeit-Subsurface Scattering auf non-konvexe Objekte zu übertragen. Hintergrund ist der, dass die diffus dipole Approximation von Jensen nicht mehr greift, wenn zwischen der gedachten Verbindung von Oberflächenpunkt in der Shadow Map und dem Sichtbaren Punkt vom Betrachter aus nicht nur das Material durchlaufen wird (also z.B. eine hohle Kugel).

Meine Idee war deshalb, die Sichtbarkeit von jedem Punkt zu jedem anderen vorzuberechnen, aber natürlich nur von jedem Vertex aus. Genauer gesagt von jedem Vertex zu einem Oberflächenpatch (konkret: 10.000 Vertizen, aber nur max. 2000 Patches). Das lässt sich dank Cuda in 0.25s berechnen und stellt den "Flux" innerhalb des Objektes dar. Das sieht dann so aus (je dunkler der Oberflächenpunkt, desto weniger andere Oberflächenpunkte können durch eine direkte Verbindung erreicht werden).



Der jetzige Brute-Force Algorithmus berechnen nun SSS pro Vertex, indem die diffus dipole Approximation (~~ Energiefluss) zu jedem Patch berechnet wird, aber NUR WENN dieser sichtbar ist. Das Ergebnis ist SCHEISSE!! (das Licht kommt von rechts hinten)



Zum Vergleich der naive Ansatz:



Beim naiven Ansatz ohne Sichtbarkeit gibt es viel weniger Artefakte und das ganze Bild wirkt smoother. Dabei hat der Ansatz mit der Sichtbarkeit durchaus seine Existenzberechtigung, wie man am linken unteren Fuß dess Buddha sehen kann: Der naive Ansatz ist hier fälschlicherweise zu hell)

Also: Viel Arbeit, bislang wenig Erfolg :-( Ich habe derzeit keine Idee, wie ich die Smoothness-Problem in den Griff bekommen kann. Ich habe aber eine Ahnung, woran es liegen könnte: Die Subsurface-Scattering-Funktion ist offenbar sehr stetig und "weich", während meine Sichtbarkeit binär ist. Ich kombiniere also eine stetige Funktion mit einer unstetigen - dann ist das Ergebnis (Multiplikation) natürlich auch unstetig. blabla.

Danke fürs Zuhören! Über Ideen würde ich mich freuen :)

Starvald

[starvald]

Hier kann man die (potentielle) Bedeutung von Sichtbarkeit beim SSS nochmal besser erkennen. Licht wieder von hinten rechts.

Klassisch:



Mit Sichtbarkeit:

[Krishty]

Für mich klingt das, als hättest du das als entweder-oder gelöst (entweder sichtbar oder nicht), was imo falsch ist. Licht fließt ja auch, wenn zwischendurch das Medium gewechselt wird; für die nicht direkt erreichbaren Patches solltest du also nur einen dem Außenmedium (Luft?) angepassten Fluss angeben anstatt ihn völlig zu unterbrechen. So wie in deinen Beispielen sähe das Modell aus, wenn außerhalb des Körpers kein Licht übertragen werden könnte.

Ich kenne das noch von der Atmosphärenberechnung, wo alles erst ab Streuung dritter Ordnung gut aussah.

[starvald]

Für mich klingt das, als hättest du das als entweder-oder gelöst (entweder sichtbar oder nicht), was imo falsch ist. Licht fließt ja auch, wenn zwischendurch das Medium gewechselt wird; für die nicht direkt erreichbaren Patches solltest du also nur einen dem Außenmedium (Luft?) angepassten Fluss angeben anstatt ihn völlig zu unterbrechen. So wie in deinen Beispielen sähe das Modell aus, wenn außerhalb des Körpers kein Licht übertragen werden könnte.

Ich kenne das noch von der Atmosphärenberechnung, wo alles erst ab Streuung dritter Ordnung gut aussah.

Danke für Dein schnelles Feedback!
Da hast Du auf jeden Fall Recht. Die billigste Variante wäre ja wohl, für jeden Strahl die Strecke des durchwanderten Innenmediums und des durchwanderten Außenmediums zu akkumulieren, bis der Zielpunkt erreicht ist. Wie sich dann daraus ein "schöner Sichtbarkeitskoeffizient" ableiten lässt, wäre noch offen.

Schade auch, wenn ich zur Speicherung der Sichtbarkeit dann von uchar auf float umsteigen müsste, dann explodiert der VRAM bald ;-)

[eXile]

Meine Hypothesen, warum es nicht wie gewünscht aussieht:

• Der Lichttransfer im Körper ist falsch eine Approximation: Von einem Vertex ausgehen, wird das Licht auf seinem Wege immer wieder gestreut; es kann dabei auch um Ecken wandern. Jede dieser Streuungen trägt zum diffusen Aussehen des Objekts bei.
• Du hast keine Interreflexionen, daher sehr hochfrequente Beleuchtung. Das richtige Stichwort dazu ist PRT, und da kannst du dir mal die SH-Samples aus dem Direct3D-SDK anschauen.
• Du berechnest den Beleuchtungstransfer nur pro Vertex; du kannst aber auch eine Textur draufmappen und pro Texel den Transfer berechnen. Dies ist aber nicht notwedig, wenn du korrekte niederfrequente Beleuchtung hast.