OpenGL 3 & DirectX 11: Der Krieg ist vorbei

Shadermodell 5 Mit Shader Model 5 wendet Microsoft bestimmte Konzepte der objektorientierten Programmierung auf seine Shader-Sprache HLSL an. Im Gegensatz zu früheren Versionen, die neue Funktionen (Dynamic Branching, Integer-Unterstützung usw.) eingeführt haben, soll hier die Arbeit der Programmierer erleichtert werden, indem ein gängiges Problem in aktuellen Spielengines gelöst wird: nämlich die Zunahme der Shader aufgrund der großen Anzahl der Permutationen. Wir n

Shadermodell 5

Mit Shader Model 5 wendet Microsoft bestimmte Konzepte der objektorientierten Programmierung auf seine Shader-Sprache HLSL an. Im Gegensatz zu früheren Versionen, die neue Funktionen (Dynamic Branching, Integer-Unterstützung usw.) eingeführt haben, soll hier die Arbeit der Programmierer erleichtert werden, indem ein gängiges Problem in aktuellen Spielengines gelöst wird: nämlich die Zunahme der Shader aufgrund der großen Anzahl der Permutationen. Wir nehmen ein konkretes Beispiel: Angenommen, ein Motor verwaltet zwei Arten von Materialien, Kunststoff und Metall, und zwei Arten von Licht: Spot und Omni . Ein Programmierer muss vier Shader schreiben, um alle Fälle zu behandeln:

renderPlasticSpot () ... // Rendering von Plastik mit Spotlight ...

renderPlasticOmni () ... // rendering plastic mit omni light ...

renderMetalSpot () ... // Rendering von Metall mit Spotlicht ...

renderMetalOmni () ... // rendering metal mit omni light ...

Dieses Beispiel ist sehr einfach, da es nur zwei Materialien und zwei Arten von Licht gibt, aber in der Praxis kann es mehrere Dutzend geben. Offensichtlich kann es auf diese Weise schnell unübersichtlich werden. Es gibt eine enorme Menge an Code-Duplikation und jedes Mal, wenn ein Fehler korrigiert wird, muss er in allen anderen Shadern korrigiert werden. Um dieses Problem zu lösen, verwenden Programmierer einen so genannten Über-Shader, der alle Kombinationen zusammenfasst:

Render () #ifdef METAL // spezifischer Code für Metallmaterial #elif PLASTIC // spezifischer Code für Kunststoffmaterial #endif #ifdef SPOT // spezifischer Code für Spotlight #elif OMNI // spezifischer Code für Omni Light #endif

Diese Lösung löst das Problem, indem sie im laufenden Betrieb Shader aus gängigen Codefragmenten generiert. Der Nachteil ist, dass es das Lesen der Shader erschwert und zusätzlichen Aufwand erfordert, um sicherzustellen, dass alle Fragmente dort eingefügt werden, wo sie sein müssen. Aber mit Direct3D 11 ist es jetzt möglich, Ihren Code viel lesbarer zu machen, indem Sie eine abgeleitete Schnittstelle und Klassen verwenden:

Licht myLight; Material myMaterial; Render () myMaterial.render (); myLight.shade ();

Light und Material sind Interfaces und der Code ist in den abgeleiteten Klassen OmniLight und SpotLight, PlasticMaterial und MetalMaterial enthalten. Der Code ist also an einem einzigen Ort, was die Fehlerkorrektur erleichtert. Gleichzeitig leidet die Lesbarkeit nicht durch die Organisation des Codes, der dem Konzept der virtuellen Funktionen in objektorientierten Sprachen ähnelt. Diese Funktion wird von Programmierern gern gesehen, hat aber für die Spieler keinen wirklichen Einfluss.

Sonstiges

Wie Sie sich vorstellen können, haben wir nur die Oberfläche der neuen Funktionen von Direct3D 11 überflogen und Microsoft hat noch nicht einmal alle Details veröffentlicht. Zu den Themen, die wir nicht erwähnt haben, gehören die Erhöhung der maximalen Texturgröße von 4K x 4K auf 16K x 16K und die Möglichkeit, die Anzahl der im VRAM geladenen Mipmaps zu begrenzen. Es besteht auch die Möglichkeit, den Tiefenwert eines Pixels zu ändern, ohne die Funktionalität zu deaktivieren, z. B. frühes Z-Prüfen, Unterstützung für Gleitkommaarten mit doppelter Genauigkeit, Scatterspeicher-Schreibvorgänge usw.

Top