Im folgenden Beitrag möchten wir über die kommende Echtzeit-Engine mit der Bezeichnung Eevee von Blender 2.8 sprechen. Eevee wird dem Trend der Spielindustrie folgen und High-End-Grafiken in Verbindung mit einem reaktionsschnellen Echtzeit-Viewport unterstützen.
Das folgende Video veranschaulicht die Features von Eevee:
Damals war es noch etwas früh, um die Besonderheiten des Projekts zu diskutieren. Aber diese Zeit ist nun vorbei, die Ideen sind ausgereift und es ist jetzt an der Zeit, offen über die Eevee-Roadmap zu sprechen.
Beleuchten der Szenen.
Das erste Ziel ist es, alle realistischen Blender-Lichttypen zu unterstützen.
Wir beginnen mit der Unterstützung von diffusen Punktlichtern. Im Gegensatz zur PBR-Branche stellen wir sicher, dass das Hinzufügen/Entfernen von Lichtern in der Szene nicht zu einer Verlangsamung führt. Für den Technikfanatiker: Wir verwenden UBO (Uniform Buffer Object) mit den Szenenlichtdaten, um ein erneutes Kompilieren der Shader zu verhindern.
Als nächstes können wir die Spiegelung in den Shadern unterstützen und die Lichtunterstützung um Flächenlichter erweitern. Die Implementierung bedeutet, dass wir den GGX-Shader erweitern, um die UBO-Daten zu berücksichtigen.
Wir werden auch die Lichtpaneele für die Eevee Einstellungen überarbeiten müssen, da nicht alle Einstellungen in Echtzeit sinnvoll sind.
Soft Shadows.
Wie alle mögen wir unsere Shadows auch so glatt wie es nur möglich ist. Aber realistische glatte Shadows sind rechnerisch teuer. Für den Echtzeitmodus von Eevee folgen wir der Shadow Buffer Implementierung, die wir jetzt in Blender haben. Für das Offline-Eevee-Rendering (z.B. Playblast) können wir die Messlatte höher legen.
Reguläre Materialien.
Uber Shaders.
Die Dinge sind hell und gut, aber wir brauchen noch Materialien, um darauf zu reagieren.
Wir werden das Konzept der Uber Shader in Anlehnung an die Unreal Engine (UE) 4 PBR Materialien umsetzen. Da das Ziel von Eevee nicht die Feature Parität mit UE4 ist, sollten Sie nicht erwarten, alle UE4 Uber Shader hier zu sehen.
Ein Uber Shader ist hauptsächlich ein Output Node. Damit dies effektiv funktioniert, müssen wir auch das PyNode-Shader-System implementieren. Auf diese Weise kann jeder (Python-) Nodes seinen eigenen GLSL-Shader haben, der von der Engine verwendet werden kann.
Mehrere Engines, ein Material, was tun?
Ein Material, das für Cycles eingerichtet wurde und noch keinen Eevee PBR Node hat, sollte für Eevee noch funktionieren, auch wenn es etwas anders aussieht. Obwohl wir also Eevee eigene Output Nodes unterstützen wollen, planen wir eine Fallback-Lösung, bei der anderen Engine Nodes unterstützt werden.
Konvertieren / Blender intern ersetzen
Nachdem wir eine funktionierende Pipeline mit Eevee haben, sollten wir uns mit der Kompatibilität alter Blender-Render-Dateien befassen. Allerdings sollte die Cycles-Fallback-Option ausreichen, um die Benutzer dazu zu bringen, von Anfang an in Eevee einzusteigen.
Erweiterte Materialien.
Fortgeschrittene Techniken werden später unterstützt, wie z.B.:
- SSS
- Clear Coat
- Volumetric
Image Based Lighting.
Wir werden vorgerenderte HDRIs unterstützen, gefolgt von in-scene on-demand generierten Sonden. Dadurch beeinflussen sich die Szenenobjekte gegenseitig (Reflexionen, diffuses Licht …)
Wie benötigen das Ansichtsfenster, um immer ansprechbar zu sein und etwas zu zeigen, während die Sonden berechnet werden. Sphärische Oberschwingungen können im .blend gespeichert werden, um eine schnelle Belastung während der Sondengenerierung zu ermöglichen.
Time Cache sollte auch für die Reaktionsfähigkeit unbedingt berücksichtigt werden.
Glänzende Rough Shader.
Wir können Hochglanz mit Roughness Reflections nicht ohne Vorfilterung der Sonden unterstützen. Ansonsten erhalten wir ein furchtbares Ergebnis.
Diffuse Approximation.
Es gibt mehrere Möglichkeiten, die Bestrahlungsstärke der Szene darzustellen, wie z.B. Cubemaps und sphärische Obertöne.
Der genauere Weg ist die Verwendung einer Cubemap, um das Ergebnis des diffusen Shaders zu speichern. Dies ist jedoch langsam, da es die Berechnung der Diffusion für jeden Text erfordert.
Ein bekannter Kompromiss ist die Speicherung von niedrigfrequentierten Lichtinformationen in einer Reihe von Koeffizienten. Dies ist zwar schneller (und einfach zu handhaben), scheitert aber in Eckfällen (wenn sich die Lichter selbst auslöschen).
Eevee unterstützt Spherical Harmonics, so dass Cubemaps nur für gebakte Speculars zur Verfügung stehen.
Probe-Objekte.
Wie Kraftfelder sollten auch Sonden leere Objekte mit eigenem Zeichencode sein.
Environment Map Array.
Große Objekte können mehrere Sonden benötigen, um die Umgebung korrekt darzustellen. In der Unreal-Umgebung behandelt das Map-Array dies auf unterstützter Hardware. Dies ist nicht kompatibel mit OpenGL 3.3 Core. Wir können dies auf modernen Grafikkarten weiterhin unterstützen. Aber wir sollten nach Alternativen suchen, die mit alter und neuer Hardware kompatibel sind, wie z.B. tetraedrische Maps.
Post-Process-Effekte.
Für die Siggraph-Deadline benötigen wir folgende Effekte:
- Motion Blur
- Bloom
- Tone Map
- Depth of Field
- Grund Truth Ambient Occlusion
Weitere Effekte, die wir gerne umsetzen würden:
- Temporale Anti-Alias ( um die lärmenden Glühwürmchen zu reparieren, die wir durch den Glanz erhalten)
- Screen Space Refelction (genauere Reflexion, hilft bei der Erdung der Objekte)
Nachwort.
Der Kern der hier genannten Features soll von Siggraph 2017 umgesetzt werden, mit einer ausgefeilteren Version von der Blender Conference.
Das Viewport-Projekt (zu dessen Kernstück Eevee gehört) wird in Blender 2.8 entwickelt. Es ist noch ein bisschen früh für massive Benutzertests, aber halten Sie sich über weitere Updates immer auf dem Laufenden.