Physically Based Rendering

[Top-OR]

Hallo Freunde der Computer(grafik(entwicklung))!

In der letzten Zeit lese ich immer wieder von Physically Based Rendering. Alles, was Rang und Namen hat, kann das wohl inzwischen ... inklusive des neuen Landwirtschaftssimulators. -.-

Würde mir mal jemand in verständlichen Worten erklären, WAS GENAU damit gemeint ist?

Ich meine, die Bestrebungen, fotorealistisch zu rendern, gibts ja auch schon ewig. Und Shader, die bestimmte Materialien darstellen (inkl. entsprechendem Lichthandling) ist doch auch nix Neues.
WAS GENAU verbirgt sich dahinter? Oder ist das nurn neues Buzzword, was man auf (s)eine Engine schreiben muss, um dabei zu sein?

Wenn ich google, komme ich immer wieder auf ein Buch (http://www.amazon.de/Physically-Based-R ... 0123750792), was eher die Gesammtheit eines Rendersystems/Engine beschreibt bzw. ich bekomme nur auf verschiedene Artikel, denen ich immer nur grob entnehme, dass es um "Fotorealismus" geht (verschiedenen Eigenschaften verschiedener Materialien).

Verbirgt sich dahinter eine bestimmte (Render-)technik bzw. ein Algorithmus oder ist das eher ein Name für Bestrebungen allgemein, möglichst Fotorealistisch zu rendern?

Kann mir das jemand zusammengefasst erklären?

Ich danke schonmal im Voraus für eure Gedanken!

Sonnige Grüße,
Jens

[Krishty]

Früher wurden Farben in virtuellen Welten als dimensionslose Zahlen zwischen 0 und 1 dargestellt, und Beleuchtung sowie Gamma wurden so hingehackt, dass sie irgendwie reinpassen.

Heute rechnen Engines intern mit Leuchtdichten, die sich in physikalisch etablierten Einheiten wie cd/m² ausdrücken lassen. Die Materialien werden so realisiert, dass sie nicht nur realistisch aussehen, sondern physikalische Phänomene (Reflexion, Refraktion, Streuung) und deren tatsächlichen Formeln möglichst weit annähern.

Wo früher gesagt wurde, „dieser Pixel ist 30 % rot und 15 % grün und 10 % blau“, wird heute gesagt, „aus Richtung dieses Pixels erreicht das Auge Licht mit einer Intensität von 4000 cd/m² im roten Bereich, 800 cd/m² im grünen Bereich, und 360 cd/m² im blauen Bereich“. Diese Daten kann man dann direkt mit tatsächlichen Aufnahmen vergleichen. Ebenso braucht man als Eingabe nicht mehr Texturen, die man irgendwie zusammengemalt hat, sondern Reflexionsdaten in kalibrierten Farbräumen, die mit den verwendeten Formeln kompatibel sind.

Das kann nach dem Tonemapping an das Gamma des Ausgabegeräts angepasst werden und nun hat man eine an physikalischen Gesetzen orientierte Lichtsimulation statt einfach ein Durcheinandermischen von Farben.


Ganz spezielles Beispiel: Früher hat man glänzende Materialien realisiert, indem Diffuse und Specular addiert wurden. Das ist schonmal völlig verkehrt weil es die Energieerhaltung verletzt: Das einkommende Licht kann doppelt so stark reflektiert werden (wenn Diffuse und Specular beide 1 ergeben). Rendern auf physikalischer Grundlage müsste Diffuse und Specular so kombinieren, dass die Energie erhalten wird. Dann wird schnell klar, dass Diffuse und Specular beide auf der selben Formel aufbauen, wie sich Licht beim Übergang zwischen zwei Medien verhält. (Tatsächlich sind beides Spezialfälle, in denen sich die Formel durch günstige Koeffizienten vereinfacht hat.) Nähert man nun diese Formel möglichst nah an (lösen kann man sie nicht, weil Dinge wie Polarisation, Interferenz, und Leitfähigkeiten der Materialien mit reinspielen und es dann schnell unwirtschaftlich komplex wird), ergibt sich automatisch ein sehr natürliches Aussehen, weil die Reflexionseigenschaften und Gesetze denen der Natur sehr ähnlich geworden sind. Diese Dinge zu erarbeiten ist die Theorie beim Rendern auf physikalischer Grundlage. Die Praxis ist meist, die Farbräume durch die ganze Pipeline hindurch konsistent zu halten, damit die Ergebnisse nicht durch Gamma/sRGB verfälscht werden.

[Top-OR]

Früher wurden Farben in virtuellen Welten als dimensionslose Zahlen zwischen 0 und 1 dargestellt, und Beleuchtung sowie Gamma wurden so hingehackt, dass sie irgendwie reinpassen.

Yupp, so mach ich das auch. Das klingt so „willkürlich“, aber es stimmt schon. Es hat mehr mit „Probieren“ zu tun, ob das Endergebnis gut aussieht, als mit zielgerichtetem Berechnen ... ja.

Heute rechnen Engines intern mit Leuchtdichten, die sich in physikalisch etablierten Einheiten wie cd/m² ausdrücken lassen. Die Materialien werden so realisiert, dass sie nicht nur realistisch aussehen, sondern physikalische Phänomene (Reflexion, Refraktion, Streuung) und deren tatsächlichen Formeln möglichst weit annähern.

Ich verstehe das so, dass die Engines eher Daten entgegen nehmen, die vergleichbar mit „realen physikalischen Daten“ sind, als einfach mal so „hingemalte“ Texturen.

Wo früher gesagt wurde, „dieser Pixel ist 30 % rot und 15 % grün und 10 % blau“, wird heute gesagt, „aus Richtung dieses Pixels erreicht das Auge Licht mit einer Intensität von 4000 cd/m² im roten Bereich, 800 cd/m² im grünen Bereich, und 360 cd/m² im blauen Bereich“. Diese Daten kann man dann direkt mit tatsächlichen Aufnahmen vergleichen. Ebenso braucht man als Eingabe nicht mehr Texturen, die man irgendwie zusammengemalt hat, sondern Reflexionsdaten in kalibrierten Farbräumen, die mit den verwendeten Formeln kompatibel sind.

Das kann nach dem Tonemapping an das Gamma des Ausgabegeräts angepasst werden und nun hat man eine an physikalischen Gesetzen orientierte Lichtsimulation statt einfach ein Durcheinandermischen von Farben.

Aber TUN nicht genau das Farbtexturen auf ihre abstrakte Art; nur eben nicht an reale natürliche Größen angelehnt, sondern abstrahiert, indem aus den genormten Farbkanälen (0.0 – 1.0) der Textur eine Farbe (gerne auch gemischt, beleuchtet, schattiert, benebelt oder was weiß ich) eine Endfarbe ermittelt wird, die der User dann sieht? [gerne auch Im Spektrum 0.0 – x.x (>1.0), was dann auf normales LDR RGB ge(tone)mappt wird]?!?!???
Die Grafikkarte als Solche rechnet ja auch nur mit abstrakten Werten.

Oder geht’s dabei WIRKLICH darum, dass die Engine/Grafiktreiber/-karte eben nicht in ihren genormten Werten rechnen, sondern soweit wie möglich mit Werten rechnen, die im direkten Zusammenhang zu physikalischen Größen stehen? (auch, wenn das Endergebnis u.U. gleich aussieht).

Ganz spezielles Beispiel: Früher hat man glänzende Materialien realisiert, indem Diffuse und Specular addiert wurden. Das ist schonmal völlig verkehrt weil es die Energieerhaltung verletzt: Das einkommende Licht kann doppelt so stark reflektiert werden (wenn Diffuse und Specular beide 1 ergeben). Rendern auf physikalischer Grundlage müsste Diffuse und Specular so kombinieren, dass die Energie erhalten wird. Dann wird schnell klar, dass Diffuse und Specular beide auf der selben Formel aufbauen, wie sich Licht beim Übergang zwischen zwei Medien verhält. (Tatsächlich sind beides Spezialfälle, in denen sich die Formel durch günstige Koeffizienten vereinfacht hat.) Nähert man nun diese Formel möglichst nah an (lösen kann man sie nicht, weil Dinge wie Polarisation, Interferenz, und Leitfähigkeiten der Materialien mit reinspielen und es dann schnell unwirtschaftlich komplex wird), ergibt sich automatisch ein sehr natürliches Aussehen, weil die Reflexionseigenschaften und Gesetze denen der Natur sehr ähnlich geworden sind. Diese Dinge zu erarbeiten ist die Theorie beim Rendern auf physikalischer Grundlage. Die Praxis ist meist, die Farbräume durch die ganze Pipeline hindurch konsistent zu halten, damit die Ergebnisse nicht durch Gamma/sRGB verfälscht werden.

Okay, ich versuche, dir gerade zu folgen und denke, das issn gutes Beispiel. Gibts noch andere?

[Krishty]

Wo früher gesagt wurde, „dieser Pixel ist 30 % rot und 15 % grün und 10 % blau“, wird heute gesagt, „aus Richtung dieses Pixels erreicht das Auge Licht mit einer Intensität von 4000 cd/m² im roten Bereich, 800 cd/m² im grünen Bereich, und 360 cd/m² im blauen Bereich“. Diese Daten kann man dann direkt mit tatsächlichen Aufnahmen vergleichen. Ebenso braucht man als Eingabe nicht mehr Texturen, die man irgendwie zusammengemalt hat, sondern Reflexionsdaten in kalibrierten Farbräumen, die mit den verwendeten Formeln kompatibel sind.

Das kann nach dem Tonemapping an das Gamma des Ausgabegeräts angepasst werden und nun hat man eine an physikalischen Gesetzen orientierte Lichtsimulation statt einfach ein Durcheinandermischen von Farben.

Aber TUN nicht genau das Farbtexturen auf ihre abstrakte Art; nur eben nicht an reale natürliche Größen angelehnt, sondern abstrahiert, indem aus den genormten Farbkanälen (0.0 – 1.0) der Textur eine Farbe (gerne auch gemischt, beleuchtet, schattiert, benebelt oder was weiß ich) eine Endfarbe ermittelt wird, die der User dann sieht? [gerne auch Im Spektrum 0.0 – x.x (>1.0), was dann auf normales LDR RGB ge(tone)mappt wird]?!?!???
Die Grafikkarte als Solche rechnet ja auch nur mit abstrakten Werten.

Oder geht’s dabei WIRKLICH darum, dass die Engine/Grafiktreiber/-karte eben nicht in ihren genormten Werten rechnen, sondern soweit wie möglich mit Werten rechnen, die im direkten Zusammenhang zu physikalischen Größen stehen? (auch, wenn das Endergebnis u.U. gleich aussieht).

Klar kannst du das Ergebnis auch auf anderem Wege erreichen, nur wird es dann auf lange Sicht noch komplexer. Autodesk hatte auf Siggraph eine Präsentation wie sie den Look mit Raten und Ausprobieren hinkriegen, und das will ich nicht wirklich in der Engine haben.

Wie radikal anders physikalisch fundierte Werte in den Texturen aussehen, kannst du hier ab Seite 24 sehen: Pierre-Yves Donzallaz & Tiago Sousa — The Art and Technology behind Crysis 3
Auf Seite 25, 28, und 31 siehst du die Unterschiede sehr deutlich. (Auch wenn Crysis 3 imho ein sehr schlechtes Beispiel ist, weil das Endergebnis alles andere als realistisch aussieht.)

Okay, ich versuche, dir gerade zu folgen und denke, das issn gutes Beispiel. Gibts noch andere?

Das einfachste Beispiel ist, vergessen, Gamma rauszurechnen. Wenn man eine 08-15-Direct3D-9-Engine hat, die keine sRGB-Reads aktiviert hat, lädt sie deine 32-Bit-RGBA-Textur und multipliziert sie mit dot(normal, light). Und das ist dann schon falsch weil das RGB der Textur kein linearer Wert ist, sondern vom Textur-Gamma abhängt, während das dot() physikalischen Ursprungs ist und lineare Helligkeit ausspuckt. Man kann trotzdem hinkriegen, dass es gut aussieht; aber nur, wenn man dafür so Sachen macht wie die Ambient Occlusion überall zur 2,5ten Potenz zu nehmen weil es dann zufällig den Effekt nahezu ausgleicht. Was du wirklich willst ist, dass die Reflexionswerte aus der Textur und deine Lichtwerte in der selben Einheit vorliegen wenn du sie verrechnest.

[Top-OR]

Hi Krishty!

Danke für deine Erläuterungen. Ich denke, ich habe es im Großen und Ganzen verstanden:

Es geht im Grunde darum, natürliches (Licht-)verhalten besser nachzustellen, um ein natürliches Ergebnis zu erhalten, anstatt rumzuprobieren, bis man etwas hat, was "nur irgentwie" so aussieht.

Falls du/jemand nochn Beispiel parat hat, nur her damit.

Noch eine Offtoppic-Frage zum sRGB-Format. Welche Fileformate unterstützen sRGB bzw. vorher weiß ich, ob meine Texturen "lineares RGB" haben oder "sRGB"?
Oder sind die Daten, die ich z.B. ausm "handelsüblichen TGA" lese, sRGB?

Beste Grüße, Jens

[xq]

Im Endeffekt kannst du das nie wirklich wissen. Faustregel: Texturen sind immer sRGB (da sie ja auf deinem bildschirm passen müssen), Specular- und Normalmaps sind immer lRGB (da sie vom Computer erzeugt wurden).
Wenn ein Bild fotografiert != RAW oder von einem Artist erstellt wurde, kannst du davon ausgehen, dass es sRGB ist.
Bei computergenerierten Grafiken ist die Chance für lRGB höher.
Sicher sein kannst du dir nicht.

Was auch funktionieren könnte: Textur aufmachen, schauen ob es scheiße beleuchtet aussieht. Wenn ja, ist es sRGB. :D

[Top-OR]

@MasterQ32: Verstehe, ich (glaube ich) kann dir folgen.

Ich frage mich nur, ob ICH den Unterschied wirklich sehe.... :-D
Wo kann ich mir neue Augen runterladen?

[Krishty]

Das deutlichste Merkmal von physikalischen Werten ist ja der hohe Kontrastumfang: Der blaue Himmel an einem sonnigen Tag scheint mit ungefähr 1.000–10.000 cd/m². Wenn er in ein Zimmer hineinscheint, ohne dass die Sonne draufsteht, hast du drinnen 10–500 cd/m². Noch größer ist der Kontrast zwischen Sternenhimmel (0,001 cd/m²) und Sonnenscheibe (um 1.000.000.000 cd/m²).

Darum die Faustregel: Wenn in Texturen die dunklen Stellen gut tausend Mal kleinere Zahlenwerte haben als die hellen, dann sind es höchstwahrscheinlich physikalische Werte. Bei 8-Bit-pro-Kanal-Farbtiefe findest du sowas eher selten.

Links hast du ein Foto in sRGB. Rechts hast du es im linearen Farbraum, wo ein doppelter Zahlenwert auch die doppelte Lichtmenge bedeutet.

[David_pb]

Hier ein kurzer Überblick:

Die Motivation hinter PBR kann man, finde ich, ganz gut mit Plausibilität, Konsistenz und Einfachheit beschreiben. Dabei geht es nicht darum ein möglichst realistisches Ergebnis zu erzielen. Prominentes Beispiel dafür ist z.B. Disney, die für viele ihrerer neueren Animationsfilme PBR verwenden (Wreck-it Ralph & Co) [5]. Es geht viel mehr darum ein Plausibles Ergebnis zu erhalten und dafür möglichst viele Fehlerkomponenten zu eliminieren.

Um das zu erreichen wird versucht ein Framework zu erzeugen das vieles was früher von Hand eingestellt werden musste automatisiert vornimmt. Außerdem wird versucht die Menge der einstellbaren Eigenschaften möglichst klein zu halten; sowie nur intuitive/verständliche Eigenschaften zu verwenden (siehe auch [5]). Beispielsweise wird häufig der 'obligatorische' Phong-Exponent durch andere, besser verständliche, Werte ausgedrückt (z.B. Glossiness, Roughness, ...). Im Rückschluss wird das Einstellen von Materialien dadurch extrem vereinfacht und wird nicht reduziert auf wildes Reglerverschieben.

Schlussendlich macht das auch vom Produktionsstandpunkt Sinn, da Iterationszeiten im Idealfall stark verkürzt werden. Stell dir vor du baust ein Asset das du in verschiedenen Levels bzw verschiedenen Lichtsituationen verwenden willst. Mit 'traditionellen' [1] Methoden war das häufig nicht möglich. Viele Materialien die für eine bestimmte Lichtstimmung perfekt getweakt waren sahen in anderen Szenen komplett falsch aus. Dazu kamen dann noch weitere Fehlerquellen, z.B. in die Diffusemap gebackenes Ambientocclusion usw... D.h. diejenigen Assets mussten im zweifel für jeden Anwendungsfall neu eingestellt und geklont werden. Ziel ist es Assets in einer Szene mit neutraler Lichtstimmung Einzustellen und diese Assets überall wiederverwenden zu können, egal wie die Lichtsituation sich ändert.

Aus dieser Motivation heraus ist der PBR Trend entstanden. Um all das zu erreichen sagt man, dass BRDFs physikalisch plausibel sein müssen. Dafür müssen diverse Kriterien erfüllt werden, u.A. muss die BRDF energierhaltend sein, d.h. die totale Energie des reflektierten Lichts (von einer Oberfläche) muss weniger oder gleich groß sein wie die Energie des einfallenden Lichts. Verwendete BRDFs basieren außerdem auf 'Microsurface Models' [2]. Großer beliebtheit erfreut sich aktuell das Cook-Torrance Modell das relativ flexibel Konfigurierbar ist. Genauer gesagt wird das Model über drei Terme beschrieben, nämlich Fresnel (F), Normal Distribution (D) und Shadow-Masking (G). Flexibel heißt in diesem Fall das die Terme sich theoretisch einfach austauschen lassen. Beispielsweise verwendet die Unreal Engine Trowbridge Reitz (GGX) als NDF andere verwenden Blinn-Phong usw... Wenn du tiefer in die Theorie schauen willst kann ich dir Naty Hoffman's Background-Talk von der Siggraph 2013 empfehlen [3].

Ziel ist es schließlich das alle Komponenten diesem Framework folgen, d.h. alle analytischen Lichtquellen, IBL, indirektes Licht etc... Außerdem wird oft versucht mit kalibrierten Daten zu arbeiten um das Ergebnis nicht zu verfläschen (viele Studios verwenden dennoch unkalibrierte Daten).

So viel zur Kurzübersicht. Im Anhang (ab Punkt 3) hab ich mal noch einige Links angehängt, falls du etwas tiefer in die Materie eintauchen möchtest. Falls du eine Highlevel-Einführung haben willst gibts mittlerweile schon einige "Tutorials" die versuchen das ganze einfach und verständlich zu Vermitteln, z.B. "Physically Based Real-time Rendering for Artists" [9].

[1] Mit traditionell meine ich den 'quasi' Standard als (Blinn-) Phong als Specular- und Lambert als Diffuse BRDF zu verwenden.
[2] Microsurface Models beschreiben Oberflächen als mikroskopisch kleine perfekte Reflektoren. Vereinfacht gesagt beschreibt das Modell die Verteilung/Ausrichtung der Normalen der einzelnen Facetten.
[3] http://blog.selfshadow.com/publications ... _notes.pdf
[4] http://blog.selfshadow.com/publications ... ng-course/
[5] http://blog.selfshadow.com/publications ... tes_v2.pdf
[6] http://blog.selfshadow.com/publications ... ng-course/
[7] http://renderwonk.com/publications/s201 ... ng-course/
[8] http://seblagarde.wordpress.com/ (viele Artikel bzgl PBR)
[9] https://www.youtube.com/watch?v=LNwMJeWFr0U

[Krishty]

Exzellent!

[Top-OR]

Schön erklärt, danke für die ganzen Infos. Das Youtube-Video hatte ich schon vorher gesehen, aber zusammen mit den Erläuterungen hier komme ich der Sache gedanklich näher. Thanks.

[Schrompf]

Sehr coole Erklärung! Danke!

[Stephan Theisgen]

Von mir auch vielen Dank für die gute Erklärung...

[David_pb]

Super, freut mich! :)

[eXile]

Kleinste Anmerkungen:

Beispielsweise wird häufig der 'obligatorische' Phong-Exponent durch andere, besser verständliche, Werte ausgedrückt (z.B. Glossiness, Roughness, ...).

Na dann versuchen wir mal, den \($F_0$\)-Term irgendjemanden „intuitiv“ beizubringen. ;) Und nein, das ist nicht „direkte Reflektanz“ oder dergleichen.

Großer beliebtheit erfreut sich aktuell das Cook-Torrance Modell das relativ flexibel Konfigurierbar ist.

Das konfigurierbare Modell ist Torrance-Sparrow; Cook-Torrance legt bereits die Terme fest.

Versteckte Geheimnisse, die niemand euch sagen will:

Normalerweise nimmt man ja einen Diffusterm mit Faktor \($\mathbf{k_d}$\) der zum Spekularterm mit Faktor \($\mathbf{k_s}$\) draufaddiert wird; aber man darf nicht einfach zwischen den beiden Termen linear interpolieren (sonst hat man zu wenige Materialien abgedeckt), und man darf auch beide Faktoren nicht zu groß werden lassen (sonst ist es nicht energieerhalten). Ersteres sagen einem die analytischen Parameterfits an die MERL-Database, letzteres ist klar (einfach beide Faktoren auf 1 setzen, schon kaputt). Da will man am liebsten aus dem Fenster springen.

[Alexander Kornrumpf]

Mal eine eher praktische Frage: Wie stellt man die "korrekten" Texturen her? Also wie ist der Prozess dafür typischerweise?

[Tiles]

Ich würde mal sagen so wie immer. An der Diffuse ändert sich ja durch das physikalische Material nichts.

Der Substance Designer bietet inzwischen die Möglichkeit physikalisch basierte Materialien zu erstellen und gleich ans Spiel zu schicken sofern die Engine PBR und Substances beherrscht.

[Krishty]

Ich würde mal sagen so wie immer. An der Diffuse ändert sich ja durch das physikalische Material nichts.

Wie radikal anders physikalisch fundierte Werte in den Texturen aussehen, kannst du hier ab Seite 24 sehen: Pierre-Yves Donzallaz & Tiago Sousa — The Art and Technology behind Crysis 3
Auf Seite 25, 28, und 31 siehst du die Unterschiede sehr deutlich.

[Tiles]

Naaa guuuuut.

Bissi anders ist es tatsächlich. Aber es gibt immer noch eine art Diffuse, auch wenn sie nun wohl Albedo heisst, und eine Normalmap: http://www.artisaverb.info/PBT.html

[starcow]

Ich gebe Tiles recht.
Und, ich lehne mich aus dem Fenster und behaupte:

Das Beispiel auf Seite 25 ist kein gutes:

Denn rein aus der Perspektive des 3D-Artisten wird man mit einer solchen Albedo-Textur kein wirklich gutes Ergebnis zustande bringen.
Ich sehe auf was man hier herauswill. Man möchte eine "netto" RGB-Information die alle dem spezifschen Licht geschuldeten Effekte - also Abdunkelungen und Schatten - ausschliesst.
Abdunkelungen und Schatten, werden dann in Echtzeit mittels Normalmap (Bumpmap, Displacementmap o. ä.) und SSAO direkt in Echtzeit erzeugt.
Nur führt das in der Praxis zu keinem visuell überzeugenden Ergebnis.
Und daran ändert PBR auch nichts (respektive ist diese Überlegung genauso auf das alte "Diffuse-Specular-Normalmap-Modell" übertragbar).
Solange man kein wirklich sehr, sehr genaues GI in der Render-Engine drin hat, muss man auch weiterhin Lichtinformationen direkt in die Textur baken.
SSAO ist da leider bei weitem kein Ersatz.
Daher kann ich mit den auf Seite 24 aufgelisteten "mistakes of artists" zumindest in den Punkten "Too much AO baking" und "Overly dark cavities" nicht zustimmen.
Ich habe verschiedene Methoden getestet und diese Aussagen decken sich nicht mit meinen persönlichen Erfahrungen. Und wenn ich mir Texture-Maps zu Environments und Charakters von Artists ansehe (die meiner Meinung nach salop gesagt über jeden Zweifel erhaben sind) - scheine ich damit nicht alleine zu sein.

Ich sehe daher nicht, an welcher Stelle eine Modifizierung der Diffuse-Textur nötig sein sollte, um damit eine PBR-Engine zu füttern.

Gruss starcow

[Alexander Kornrumpf]

Let me rephrase the question:

Könnt ihr den "klassischen Prozess" zum Erstellen von Texturen kurz umreißen?

[Tiles]

Vorweg, ich habe es noch nicht gemacht. Unity hat ja noch kein PBR. Ich berufe mich auf den Link den ich da eingefügt habe. Vielleicht liege ich also auch komplett falsch. Aber was ich da so lese ist im Grunde nichts revolutionär neues was das Erstellen der Texturen angeht. Die Revolution liegt hier wohl eindeutig im PBR Material. Den Shadern also.

Meine übliche Methode: Man nehme CGTextures, lade die passenden Basetexturen runter. Die werden nun auf die UV Patches draufgeklatscht. Und entsprechend angepasst und nachgearbeitet. Verschmutzungen, Worn Edges ( Kanten sind meist abgegriffen), Kratzer, etc. . All die Kleinigkeiten eben die zum Realismus beitragen. Das kann im 2D Malprogramm passieren, oder auch in einem 3D Programm wie 3D Coat. Das ist eigentlich schon das was die Diffuse hauptsächlich ausmacht.

Was folgt ist das Seams säubern damit man die Nähte nicht sieht. Und wenn es ein Character ist dann wird da nun noch Ambient Occlusion reingebacken. Denn sich bewegenden Content kann man eben nicht in der Engine lightmappen. Wers brauch bäckt in die Diffuse nun auch noch eine Cavity Map mit rein. Der Rest passiert dann wieder im Shader in der Engine. Dirtmap, Specularmap, was es eben alles so gibt.

Somit ist eigentlich aus meiner Sicht der Arbeitsschritt um die Albedo zu erstellen fast identisch mit dem Arbeitsschritt für das Erstellen einer Diffuse. Nur dass man nun für dynamischen Content nichts mehr in die Diffuse bäckt. Und so Sachen wie Worn Edges in die Roughnessmap wandert. Gleiches gilt für die Normalmap. Auch die wird eigentlich so wie immer erstellt. High Poly, Low Poly, backen. Oder auch eine 2D Textur entsprechend in eine Normalmap umwandeln.

Was ein wenig anders ist ist die Specular / Metallic Map. Sowie die Roughness / Glossymap. Aber auch die Techniken um sowas zu erstellen sind eigentlich nichts so ungewöhnliches. Es gab ja bisher auch schon Specularmaps und Cavitymaps.

Unterm Strich heissen die Babys ein wenig anders, und tun auch ein wenig was anderes.Was man eben beim Erstellen dann berücksichtigen muss. Der Artist in dem Link spricht ja da von einer Evolution von Diffusemap zur Albedomap. Die Techniken um zu diesen Ergebnissen zu kommen sind aber alle schon bekannt.

[NoFake3D]

Ich habe dazu als PBR-Anfänger auch noch ein paar grundsätzliche Fragen zu PBR:

Wie sieht es aktuell mit der Physically Based Rendering-Unterstützung aus?

Nach meinem Wissen unterstützen zur Zeit die folgenden Game-Engines PBR:

Unreal Engine 4
CRYENGINE 3.6.4
Unity 4.52 mit Hilfe von "Lux physically based shader framework"

Aber wie sieht es mit 3D-Modeler mit PBR-Unterstützung aus?

PBR-Unterstützung vorhanden:

Marmoset Toolbag 2 (ist aber nur ein Echtzeit-3D-Vorschau-Tool mit PBL-Pixelshader für 3D-Modelle mit Normal- Albedo-, Rauheit- Metallisch-Texturen)
Substance Designer 4.2 (Testversion bricht bei meinen PC leider beim Start ab)
Autodesk Maya 2015 mit PBR-Plugin: Kodde's PBR Maya shader

Keine PBR-Unterstützung vorhanden:

Blender 2.71
Mudbox?
Autodesk 3DS MAX 2015 (Die kostenlose 30-Tage-Testversion lässt sich leider nicht herunterladen, da es Probleme mit Windows 8.1 und Internet Explorer 11 gibt)?
http://www.autodesk.de/products/3ds-max/free-trial

Brauche ich für PBL-Unterstützung in meinen Pixel-Shadern dann für jedes 3D-Modell jeweils 4 Texturen (Normal- Albedo-, Rauheit- Metallisch-Texturen) und eine Cube-Map bzw. Environment-Map?

Welche DDS-Block-Kompression ist ab besten (für die folgenden Maps ohne Alpha)?:

Normal-Map: BC5?
Albedo-Map: BC7 oder BC1?
Roughness-Map: BC7 oder BC1?
Metallic-Map: BC7 oder BC1?

Environment-Map: ?

Welchen Specular-Powerwert gebe ich für alle Materialien in der BRL-Pixel-Shader-Implementierung an?

Specular_power = 1.5F ??

Wie berechne ich die Diffuse Körper-Brechung (Fresnel-Reflektion bzw. Refraktion an der Oberfläche für eine Mikrofacette)?:

Teil 1:

Eventuell so?:

Code: Alles auswählen

FLOAT Rauheit_Oberflaeche_Mikro_Facette_aktuell = pow((n1 - n2) / (n1 + n2), 2.0F);

Oder so?:

Code: Alles auswählen

FLOAT Rauheit_Oberflaeche_Mikro_Facette_aktuell = BaseColor?? * Lambertsches_Gesetz_aktuell;

Teil 2:

Code: Alles auswählen

FLOAT Basis_aktuell = 1.0F - dot(Vektor_Reflektion_Halber_Winkel_aktuell, Vektor_Richtungslicht_Position_aktuell);

So?:

Code: Alles auswählen

FLOAT Fresnel_Reflektion_Oberflaeche_Mikro_Facette_aktuell = specular_color + ((1.0F - specular_color) * pow((1.0F - Basis_aktuell), 5.0F));

Oder so?:

Code: Alles auswählen

FLOAT Fresnel_Reflektion_Oberflaeche_Mikro_Facette_aktuell = specular_color + ((1.0F - specular_color) * pow((1.0F - Basis_aktuell), 5.0F) * (1.0F - Rauheit_Oberflaeche_Mikro_Facette_aktuell)); 

Oder so?:

Code: Alles auswählen

FLOAT Fresnel_Reflektion_Oberflaeche_Mikro_Facette_aktuell = Rauheit_Oberflaeche_Mikro_Facette_aktuell + ((1.0F - Rauheit_Oberflaeche_Mikro_Facette_aktuell) * pow(1.0F - Basis_aktuell, 5.0F));

Gruß,
Daniel Klein

[David_pb]

Hi,

ich weiß, ein altes Thema! :) Allerdings hatte ich die Antwort von eXile total vergessen und wollte noch ein paar Gedanken dazu schreiben:

Das konfigurierbare Modell ist Torrance-Sparrow; Cook-Torrance legt bereits die Terme fest.

Soweit ich mich erinnere, schlagen Torrance & Sparrow konkrete Terme vor, z.B. eine Normalverteilung für die D (oder P im Paper). Für F wird direkt auf die Fresnel'sche Gleichung verwiesen. Auch die geometrische Attenuierung wird (anhand von einem riesen Satz Annahmen) vorgegeben und hergeleitet. Außer das die Terme getrennt aufgeführt werden, ist an dem Modell erstmal wenig konfigurierbar*, vermutlich auch deshalb, weil es bis Dato (1967) kaum Alternativen gab. Das Modell war ja mehr oder weniger "neu" (naja, nicht ganz neu).

James Blinn schlug in seiner (allseits bekannten) Veröffentlichung von 1975 (von der hautpsächlich die Modifikation von der, von Phong vorgeschlagenen Verteilungsfunktion hängen geblieben ist) diverse Alternativen bzgl des NDF Terms vor, u.A. die von Torrance & Sparrow vorgeschlagene Gaußsche Verteilung, bzw die (überall bekannte) Verteilung nach Phong. Allerdings weist Blinn hauptsächlich auf eine Verteilungsfunktion hin, die von Trowbridge & Reitz im selben Jahr veröffentlicht wurde, da diese Verteilung, seiner Meinung nach, am besten experimentelle Daten von damals approximieren würde.

Viel später (1982) wurde von Cook & Torrance ein Modell, basierend auf Torrance Sparrow, vorgestellt. Es werden u.A. ziemlich deutlich unterschiedliche Ansätze zitiert um das Modell flexibel konfigurierbar zu machen (z.B. für "D" Blinn, Davies, Torrance Sparrow, Beckmann, ...). Speziell für den Fresnel-Term wird eine Approximation vorgeschlagen, allerdings hauptsächlich um das Problem fehlender Eingabe-Daten (n, k) zu umschiffen. Cook Torrance ist Basis von diversen Erweiterungen und das sicher am weitest verbreitete Modell in PBR Renderpipelines (oftmals in der Konfiguration D = GGX, F = Schlick, G = Smith).

Na dann versuchen wir mal, den \($F_0$\)-Term irgendjemanden „intuitiv“ beizubringen. ;) Und nein, das ist nicht „direkte Reflektanz“ oder dergleichen.

Du hat absolut recht: der F0-Term ist sicher nicht intuitiv erklärbar. Die Modellvorstellung weicht auch ganz drastisch von der Realität ab, ich vermute mal du beziehst dich auf John Hable's Blog (http://www.filmicworlds.com/2014/03/17/ ... flectance/), wozu es auch eine ganz Interessante Diskussion auf Twitter gab (https://twitter.com/renderwonk/status/4 ... 2726715393).

Vermutlich kann man sich in das Thema auch ziemlich reinsteigern, aber leider sind wir aktuell daran gebunden uns, im Grafikbereich, an Modellvorstellungen zu halten. Dass das der Realität nicht entspricht ist wohl jedem klar, aber es ist aktuell die beste Möglichkeit die Realität zu beschreiben. In der Modellvorstellung entspricht F0 der direkten Reflektanz bzgl einem normalem Einfallswinkel unter berücksichtigung einer Fresnel'schen Oberfläche (aka perfekter Reflektor, aka eines Microfacet [in diesem Kontext]). In der Praxis mag F0 etwas komplett anderes wiederspiegeln, das ist sicher richtig.

Das lässt sich vermutlich keinem Artist (oder überhaupt irgendjemandem?) ohne weiteres intuitiv vermitteln, deshalb wird oft versucht Parameter zu finden die einfach verständlich sind, und diese später zu remappen. Generell bedarf eine PBR Pipeline trotzdem viel Schulung (es gibt z.B. massig Cheatsheets, die das Konzept bildlich vermitteln sollen z.B.: http://peetlee.com/UnityChartsPreview.png oder http://cdn-ak.f.st-hatena.com/images/fo ... 020324.jpg), aber die Grundidee, dass Paramet einfach verständlich und intuitiv** sein sollen trotzdem erhalten bleiben.

* Konfigurierbar im Sinne von, es gibt Veröffentlichungen zu alternativen Komponenten
** Intuitiv im Sinne von, was auch immer eingestellt wird, das Ergebnis bleibt plausibel