Work in progress

The content of this page was not yet updated for Godot 4.2 and may be outdated. If you know how to improve this page or you can confirm that it's up to date, feel free to open a pull request.

Beleuchtung mit hohem Dynamikbereich (HDR)

Einführung

Normalerweise macht ein Künstler die gesamte 3D-Modellierung, dann die Texturierung, schaut sich sein fantastisch aussehendes Modell in der 3D-Modellierungssoftware an und sagt: "Sieht fantastisch aus, bereit für die Integration!", dann geht er ins Spiel, die Beleuchtung wird eingestellt und das Spiel läuft.

Ab wann kommen die ganzen "HDR" Sachen ins Spiel? Um die Antwort zu verstehen, müssen wir uns ansehen, wie sich Displays verhalten.

Ihr Display gibt lineare Lichtverhältnisse von maximaler bis minimaler Intensität aus. Moderne Spiele-Engines führen komplexe Berechnungen mit linearen Lichtwerten in ihren jeweiligen Szenen durch. Also, was ist das Problem?

Das Display hat je nach Displaytyp einen begrenzten Intensitätsbereich. Die Spiele-Engine rendert jedoch auf einen unbegrenzten Bereich von Intensitätswerten. Während "maximale Intensität" für ein sRGB-Display etwas bedeutet, hat es keinen Einfluss auf die Spiele-Engine. Pro Rendering-Frame wird nur ein potenziell unendlich großer Bereich von Intensitätswerten generiert.

Dies bedeutet, dass eine gewisse Transformation der Szenenlichtintensität, auch als szenenbezogene Lichtverhältnisse bezeichnet, transformiert und abgebildet werden muss, um in den bestimmten Ausgabebereich des ausgewählten Displays zu passen. Dies kann am einfachsten verstanden werden, wenn wir annehmen unsere virtuelle Game-Engine-Szene wird mit einer virtuellen Kamera fotografiert. Hier würde unsere virtuelle Kamera eine bestimmte Kamera-Rendering-Transformation auf die Szenendaten anwenden und die Ausgabe wäre bereit für die Anzeige auf einem bestimmten Displaytyp.

Bemerkung

Godot unterstützt noch kein Ausgabe mit hohem Dynamikbereich. Es kann nur eine Beleuchtung in HDR durchführen und das Ergebnis einem Bild mit niedrigem Dynamikbereich zuordnen.

Für fortgeschrittene Benutzer ist es weiterhin möglich, ein Bild ohne Tone-Mapping des Viewports mit vollständigen HDR-Daten zu erhalten, das dann in einer OpenEXR-Datei gespeichert werden kann.

Computerbildschirme

Fast alle Displays erfordern eine nichtlineare Codierung für die an sie gesendeten Codewerte. Das Display "decodiert" wiederum unter Verwendung seiner einzigartigen Übertragungscharakteristik den Codewert in lineare Lichtverhältnisse der Ausgabe und projiziert die Verhältnisse aus den einzigartig gefärbten Lichtern an jeder rötlichen, grünlichen und bläulichen Ausgabestelle.

Für die meisten Computer-Displays sind die Spezifikationen des Displays gemäß IEC 61966-2-1, auch als sRGB-Spezifikation von 1996 bekannt, aufgeführt. Diese Spezifikation beschreibt wie sich ein sRGB-Display verhalten soll, einschließlich der Farbe der Lichter in den LED-Pixeln sowie der Übertragungseigenschaften des Eingangs (OETF) und des Ausgangs (EOTF).

Nicht alle Displays verwenden dieselbe OETF und EOTF wie ein Computer-Display. Beispielsweise verwenden Fernsehsendungen den BT.1886 EOTF. Derzeit unterstützt Godot jedoch nur sRGB-Displays.

Der sRGB-Standard basiert auf der nichtlinearen Beziehung zwischen der Strom- und Lichtleistung gängiger Kathodenstrahl-Displays.

../../_images/hdr_gamma.png

Die Mathematik eines szenenbezogenen Modells erfordert, dass wir die Szene mit verschiedenen Werten multiplizieren, um die Intensitäten und die Belichtung mit verschiedenen Lichtbereichen anzupassen. Die Übertragungsfunktion des Displays kann den breiteren Dynamikbereich der Szenenausgabe der Game Engine mithilfe der einfachen Übertragungsfunktion des Displays nicht angemessen rendern. Ein komplexerer Ansatz für die Codierung ist erforderlich.

Szenenlinear- und Asset-Pipelines

Das Arbeiten in szenenlinearem sRGB ist nicht so einfach wie das Betätigen eines Schalters. Zunächst müssen importierte Bildelemente beim Import in lineare Lichtverhältnisse konvertiert werden. Selbst wenn sie linearisiert sind, sind diese Assets möglicherweise nicht perfekt für die Verwendung als Texturen geeignet, je nachdem wie sie generiert wurden.

Dies kann auf zwei Arten erledigt werden:

sRGB-Übertragungsfunktion zur Anzeige linearer Verhältnisse beim Bildimport

Dies ist die einfachste Methode zur Verwendung von sRGB-Assets, aber nicht die idealste. Ein Problem dabei ist der Qualitätsverlust. Die Verwendung von 8 Bits pro Kanal zur Darstellung linearer Lichtverhältnisse reicht nicht aus, um die Werte korrekt zu quantisieren. Diese Texturen können auch später komprimiert werden, was das Problem allerdings verschlimmern kann.

Hardware-sRGB-Übertragungsfunktion zur Anzeige der linearen Konvertierung

Die GPU führt die Konvertierung durch, nachdem das Texel mit Float-Werten gelesen wurde. Dies funktioniert gut auf PCs und Konsolen, aber die meisten Mobilgeräte unterstützen es generell nicht oder nicht auf komprimierten Texturformaten (z.B. iOS).

Szenenlinear nach Display-bezogen nichtlinear

Nachdem das Rendern abgeschlossen ist, muss das lineare Rendern der Szene in eine geeignete Ausgabe wie ein sRGB-Display umgewandelt werden. Aktivieren Sie dazu die sRGB-Konvertierung in der aktuellen Environment (mehr dazu weiter unten).

Beachten Sie, dass die Konvertierungen sRGB -> Displaylinear und Displaylinear -> sRGB immer beide aktiviert sein müssen. Wenn einer von ihnen nicht aktiviert wird, führt dies zu schrecklicher Grafik, die nur für avantgardistische experimentelle Indie-Spiele geeignet ist.

Parameter von HDR

HDR-Einstellungen finden Sie in der Ressource Environment. Meistens befinden sich diese in einem WorldEnvironment-Node oder in einem Kamera-Node. Weitere Informationen finden Sie unter Environment und Post-Processing.