Dot3 Lighting

[aths]

Könnte einer der Cracks (Demi?) einen Pixelshader (so klein wie möglich, am besten 1.0) schreiben, der Dot3 Lighting macht? Am besten eine Version ohne und eine mit Normalisierung der Normalen?

[Demirug]

Ohne Normalisierung


ps.1.1
tex t0 ; Farbe
tex t1 ; Bumpmap
dp3 r1, t1_bx2, v0_bx2 ; dot(Bumpmap, Licht)
mul r0,t0, r1 ; mit Farbe Verrechen


Mit Normalisierung


ps.1.1
tex t0 ; Farbe
tex t1 ; Bumpmap
tex t2 ; Cube
dp3 r1, t1_bx2, t2_bx2 ; dot(Bumpmap, Licht)
mul r0,t0, r1 ; mit Farbe Verrechen


Müsste stimmen

[aths]

... und das ganze ohne Textur? :D (Oder brauchts da auch 'ne Bumpmap?)

Braucht es zum normalisieren unbedingt 'ne Cubemap??

Wofür steht der _bx2 Modifier?

[Demirug]

Original geschrieben von aths
... und das ganze ohne Textur? :D (Oder brauchts da auch 'ne Bumpmap?)

Ich habe doch eine textur?

Braucht es zum normalisieren unbedingt 'ne Cubemap??

Ja

Wofür steht der _bx2 Modifier?

(x-0.5) * 2

Edit: bx2 ist zusammengesetzt aus bias (-0.5) und x2 (*2)

[Xmas]

Original geschrieben von aths
... und das ganze ohne Textur? :D (Oder brauchts da auch 'ne Bumpmap?)

Braucht es zum normalisieren unbedingt 'ne Cubemap??

Wofür steht der _bx2 Modifier?
Es geht natürlich auch ohne Bumpmap, dann muss der Vertex Shader allerdings die Vertex-Normalen in die zweite Farbe (oder eine Texturkoordinate) packen, so dass sie quer über das Dreieck linear interpoliert werden.

Die Normalisierung braucht bei [-1, 1] Zahlenbereich auf jeden Fall eine Cubemap, bei [-8, 8] kann bereits eine 1D-Divisions-Lookuptabelle reichen, bringt aber eigentlich keine Vorteile. Mit PS2.0 sind dann auch Divisionen möglich, da braucht es keine Cubemap mehr.

[aths]

Original geschrieben von Demirug
Ich habe doch eine textur?Zunächst meinte ich das ganz normale Lighting: Eine Materialfarbe bekommt quasi einfaches Phong Shading.

Braucht man hierfür schon eine Bumpmap?
Original geschrieben von Demirug
(x-0.5) * 2

Edit: bx2 ist zusammengesetzt aus bias (-0.5) und x2 (*2) Aha, und das erledigt der PS "nebenbei", ohne einen Instruktionsslot zu belegen?


Bekommt man in einem Pass auch gleichzeitiges Dot3 Specular Lighting hin?

[aths]

Original geschrieben von Xmas
Die Normalisierung braucht bei [-1, 1] Zahlenbereich auf jeden Fall eine Cubemap, bei [-8, 8] kann bereits eine 1D-Divisions-Lookuptabelle reichen, bringt aber eigentlich keine Vorteile. Mit PS2.0 sind dann auch Divisionen möglich, da braucht es keine Cubemap mehr. Die Cubemap muss vorberechnet sein, fürchte ich? Ist das aufwändig, ein Cubemap für einen Torus zu berechnen?

[Demirug]

Original geschrieben von aths
Zunächst meinte ich das ganz normale Lighting: Eine Materialfarbe bekommt quasi einfaches Phong Shading.

Braucht man hierfür schon eine Bumpmap?

Hat Xmas ja schon geschrieben da kommt man auch ohne Bumpmap aus indem man die Flächennormale interpoliert.


ps.1.1
tex t0 ; Farbe
dp3 r1, v1_bx2, v0_bx2 ; dot(Normale, Licht)
mul r0,t0, r1 ; mit Farbe Verrechen


Aha, und das erledigt der PS "nebenbei", ohne einen Instruktionsslot zu belegen?

Ja das fällt unter Eingangsskalierung und die ist kostenfrei (Bei 2.0 fallen aber die meisten Skalierungsoptionen flach).

Bekommt man in einem Pass auch gleichzeitiges Dot3 Specular Lighting hin?

Das hängt von einigen Faktoren ab.

- Mit oder ohne normalisierung?
- Monochrome oder Farbige Specularmap?
- Bumpmap?
- ...

[Demirug]

Original geschrieben von aths
Die Cubemap muss vorberechnet sein, fürchte ich? Ist das aufwändig, ein Cubemap für einen Torus zu berechnen?

Die Cubemap ist für den Lichtvektor und hat zur Geometrie des Körpers überhaupt keinen Bezug.

[aths]

Original geschrieben von Demirug
Hat Xmas ja schon geschrieben da kommt man auch ohne Bumpmap aus indem man die Flächennormale interpoliert.


ps.1.1
tex t0 ; Farbe
dp3 r1, v1_bx2, v0_bx2 ; dot(Normale, Licht)
mul r0,t0, r1 ; mit Farbe Verrechen
Wieso kommt die Farbe hier aus einer Textur? Wie benutzt man die interpolierte Farbe des Vertex'?
Original geschrieben von Demirug
Ja das fällt unter Eingangsskalierung und die ist kostenfrei (Bei 2.0 fallen aber die meisten Skalierungsoptionen flach).Immerhin eine Addition und ein Shifting sind "kostenfrei" drin? Gibt es dazu eine Art "Vor-Combiner" oder welche Logik wird da benutzt?
Original geschrieben von Demirug
Das hängt von einigen Faktoren ab.

- Mit oder ohne normalisierung?
- Monochrome oder Farbige Specularmap?
- Bumpmap?
- ... Mit normalisieren, farbiges Diffuse Light und farbiges Specular Light ermöglichen, ohne Bumpmap.

Original geschrieben von Demirug
Die Cubemap ist für den Lichtvektor und hat zur Geometrie des Körpers überhaupt keinen Bezug. Hm. Jetzt bin ich verwirrt. Ich dachte, die Cubemap enthielte vorberechnete Normalisierungs-Faktoren.

[Demirug]

Original geschrieben von aths
Wieso kommt die Farbe hier aus einer Textur? Wie benutzt man die interpolierte Farbe des Vertex'?

Soll der ganze Körper nur eine Konstante Oberflächenfarbe haben?

In den Vertexfarben wird der Lichtvektor und die Normale übergeben.

Immerhin eine Addition und ein Shifting sind "kostenfrei" drin? Gibt es dazu eine Art "Vor-Combiner" oder welche Logik wird da benutzt?

Das ist die Scalelogik die sich darum kümmert. Es gibt da aber nur ganz bestimmte Ops die zur Verfügung stehen.

Mit normalisieren, farbiges Diffuse Light und farbiges Specular Light ermöglichen, ohne Bumpmap.

Ja ohne Bumpmap liegt das noch im machbaren bereich.

Hm. Jetzt bin ich verwirrt. Ich dachte, die Cubemap enthielte vorberechnete Normalisierungs-Faktoren.

Die Cubemap enthält Vorberechnete normalisierte Lichtvektoren und die sind für alle Lichtquellen gleich.

[aths]

[code]ps.1.0
tex t0 ; Farbe
dp3 r1, v1_bx2, v0_bx2 ; dot(Normale, Licht)
mul r0,t0, r1 ; mit Farbe Verrechen[/core]Habe mal 1.0 statt 1.1 genommen. Da meint er:

(Statement 3) (Validation Error) 2 different input registers (v#) read by instruction. Max. different input registers readable per instruction is 1.

Wie splittet man das auf?
Original geschrieben von Demirug
Soll der ganze Körper nur eine Konstante Oberflächenfarbe haben?Erstmal ja.
Original geschrieben von Demirug
Das ist die Scalelogik die sich darum kümmert. Es gibt da aber nur ganz bestimmte Ops die zur Verfügung stehen. Ist das eine PS-Eigenart, oder können das schon Register Combiner?
Original geschrieben von Demirug
Ja ohne Bumpmap liegt das noch im machbaren bereich.Würdest du so nett sein, und fix den Shader dazu schreiben?
Original geschrieben von Demirug
Die Cubemap enthält Vorberechnete normalisierte Lichtvektoren und die sind für alle Lichtquellen gleich. Hm, hm, hmmmm.

[Demirug]

Original geschrieben von aths
Habe mal 1.0 statt 1.1 genommen. Da meint er:

(Statement 3) (Validation Error) 2 different input registers (v#) read by instruction. Max. different input registers readable per instruction is 1.

Wie splittet man das auf?

Über ein Temp register. Aber warum 1.0? Ist doch sowieso tot.

ps.1.0
tex t0 ; Farbe
mov r0, v0;
dp3 r1, v1_bx2, r0_bx2 ; dot(Normale, Licht)
mul r0,t0, r1 ; mit Farbe Verrechen

Erstmal ja.

Dann die Farbe auf eine Konstate (c0) setzte.

ps.1.1
dp3 r1, v1_bx2, v0_bx2 ; dot(Normale, Licht)
mul r0,c0, r1 ; mit Farbe Verrechen

Ist das eine PS-Eigenart, oder können das schon Register Combiner?

Ob die optionen jetzt genau gleich sind habe ich nicht im Kopf aber die Regcombiner können das im Prinzip auch.

Würdest du so nett sein, und fix den Shader dazu schreiben?


ps.1.1
tex t0 ; Light
tex t1 ; Light(halb)
dp3 r0,v0_bx2,t1_bx2 ; dot(normal, light(halb))

mul r1,r0,r0; x hoch 16
mul r0,r1,r1;
mul r1,r0,r0;
mul r0,r1,r1;

dp3 r1, v0_bx2, t1_bx2 ; dot(normal,light)
mul r0, c0, r0;
mad r0, c1, r1, r0;


Keine Funktiongewährleistung da ich die Dinger normalweise nicht mehr von Hand schreibe.

Fehlt aber noch der passende Vertexshader.

[Xmas]

Original geschrieben von aths
Hm, hm, hmmmm.
Eine Cubemap simuliert ja üblicherweise eine Rundumsicht um einen gedachten Ursprung. Da macht es Sinn, dass nur die Richtung, nicht aber die Länge des Texturkoordinaten-Vektors Einfluss auf die gesampelte Stelle hat. Deswegen beinhaltet die TMU auch eine Divisionslogik (bzw. RCP-Lookup). Mit anderen Worten, die Texturkoordinaten (0, 0, 1) bezeichnen genau denselben Texel wie (0, 0, 1000). Deswegen reicht es zum Normalisieren, dass man an eben jener Stelle in der Textur den normalisierten Vektor (0, 0, 1) hinterlegt.

[aths]

Das mit der Cubemap zur Normalisierung musst du mir mal bei nächster Gelegenheit aufmal0rn.