spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Geht nicht.

Natürlich geht das.

Der erste PS zeichnet in ein RT, der zweite bekommt diesen als Textur und rendert dann entweder die Szene neu und adressiert durch die Image-Space coordinates des aktuellen Pixels die RT-Texture, oder du nutzt gleich nen ganzen G-Buffer (z.B. Albedo + Depth) und somit eine Art Deferred Rendering.

Wenn du mehrere passes vermeiden möchtest, bietet HLSL auch includes an.

Mit ein paar Umwegen ist auch ein Uber-shader nützlich.

Es ist aber schon sehr selten, dass ein Shadercode so lang wird, dass man ihn kaum mehr lesen kann - schließlich gibt es funktionen auf in HLSL

Zitat von »iSmokiieZz«

Natürlich geht das.

Aber eben nicht so, wie er sich das gewünscht hätte. Das geht leider eben noch immer nicht.

Ist Dynamic Shader Linkage nicht für genau sowas da? Eine Schnittstelle für Beleuchtung in den Shader schreiben und zur Laufzeit die Version mit oder ohne Normal Mapping binden, je nachdem ob es fürs Modell nötig ist?

Zitat von »Krishty«

Ist Dynamic Shader Linkage nicht für genau sowas da?

Richtig, die Frage ist, wie effizient es ist...

Für Effizienz ist Trennung sowieso der Killer … Dice haben für Battlefield 3 alle Einzelschritte des Deferred Renderers in einen *wirklich* gigantischen Über-Shader gepackt und in einem Draw Call ausgeführt weil allein das Shader-Setup für 3 oder 4 Einzelschritte viel teurer gewesen wäre. Die Shader haben die Ergebnisse der Einzelschritte im Group-Shared Memory gehalten und sind dann einfach gekreist bis keine Arbeit mehr übrig war.