fork hat geschrieben:SV_POSITION: Wofuer steht SV? (ShaderVertex?)
System Value; siehe
http://msdn.microsoft.com/en-us/library ... stem_Value.
fork hat geschrieben:Unterschied SV_POSITION und POSITION?
SV_POSITION wird als Systemwert von der Laufzeitumgebung bzw. Hardware bereitgestellt
, während es sich bei POSITION um einen Wert handelt, den der Anwendungsprogrammierer über die Deklaration seines Vertex-Formats bereitstellt..
POSITION ist ein Direct3D-9-Register, das dir die Hardware bereitstellt, um die Position des Vertex im Objektkoordinatensystem aus dem Vertex- in den Pixel-Shader zu übertragen.
fork hat geschrieben:(Wieso) Gibt es fuer Normalen keinen "spezifizierer", da hier ueber "TEXCOORDS2" ausgewichen wird? Fuer FOG gibts doch auch einen, und Normalen werden doch sicher haeufiger als fog gebraucht.
Die Texturkoordinatenregister haben sich zu Allzweckregistern etabliert, in denen alles übergeben wird, was nicht direkt durch die Hardware bereitgestellt wird. Da die Berechnung von Vertex Fog in Hardware geschieht, wird sie in einem eigenen Register bereitgestellt (wie auch die Vertexposition für den Pixel-Shader in
SV_POSITION, die nach dem Vertex Shader von der Hardware für jedes Sample in Bildschirmkoordinaten umgerechnet wird!). Afaik gab es mal ein
NORMAL-Register zu Direct3D-9-Zeiten, das immer nur zwecks Abwärtskompatibilität da war.
fork hat geschrieben:Ist es sinnvoll, World -, View-, und Projectionmatrix einzeln zu uebergeben oder besser eine einzige "worldviewprojection"-Matrix zu uebergeben? Vor- und Nachteile?
Matrixmultiplikationen kosten enorm viel; darum solltest du sie im Shader vermeiden. Es gibt allerdings auch Anwendungsbereiche, in denen eine Aufteilung zwingend nötig ist – beispielsweise bei Fällen von Vertex Skinning und Beleuchtung, wo du vom Objekt- ins Weltkoordinatensystem umrechnen können musst.
fork hat geschrieben:Was spezifiziert "SV_Target0"? Vermutlich das "Standardziel". Was genau ist damit gemeint, was sind alternative Werte (SV_Target2?) und was ist damit erreichbar?
Es besagt, welches Render Target mit dem Pixel beschrieben werden soll. Damit kannst du in mehrere Render Targets schreiben; bspw. um eins mit Farben zu füllen und weitere mit Normalen und Materialinformationen (für Deferred Shading), oder um die sechs Seiten einer Würfeltextur in einem Rutsch zu zeichnen.
fork hat geschrieben:Muss die Reihenfolge der Member des Constant Buffers in Cpp-Datei und Shader uebereinstimmen?
Nein. Falls die Reihenfolge unterschiedlich ist, musst du aber via
packoffset() die tatsächliche Position der Daten von Hand angeben (bspw.
float3 vec : packoffset(c3); um zu sagen, dass
vec das vierte 16-Byte Register der Konstanten belegt, also 64 B vom Anfang deiner Daten beginnt). Der Shader Compiler kann halt nicht raten, wie der C++-Text aussieht, von dem der Shader irgendwann mal aufgerufen werden wird. (Wie es dabei mit dem FX-Framework aussieht, weiß ich nicht.)
fork hat geschrieben:Was muesste ich tun, moechte ich das ganze Programm in einen sepia-ton versetzen? Muss ich dafuer extra ein 4-eck anlegen, das dann vor die kamera halten, einfaerben und mit transparenz rendern?
Genau. Oder das Programm in eine Textur zeichnen lassen, die du im Pixel-Shader des Vierecks lädst, manipulierst und rausschreibst.
Ich muss bei meinem HDR Rendering sowieso erst alles in einen internen Puffer zeichnen, da die Farbtiefen von keinem Bildschirm unterstützt werden und deshalb nicht als Swap Chain zur Verfügung stehen. Am Ende setze ich einen Shader, der diese internen Daten ausliest, Tonemapping anwendet, Anti-Aliasing und Farbkorrektur darauf anwendet, und das dann in die Swap Chain im gewöhnlichen 32-Bit-RGB-Format schreibt. (Nur als Beispiel.)