Displacement Mapping?

[Tannjew]

Was genau ist displacement mapping? Ist es eine Erfindung von nVidia oder ATI, ist es eine Art Shader oder Script in einer Programmiersprache? Ich höre nämlich immer nur "vom kommenden Feature displacement mapping"...

[Aquaschaf]

displacement mapping ist ein bestandteil von DX9 , es ist keine Erfindung von ATI oder NVidia . Es ist vergleichbar mit Bump-Mapping , welches "Dellen" oder Kratzer in Oberflächen mithilfe einer Graustufen-Bitmap vortäuschen kann . Displacement Mapping arbeitet auch mit Graustufen-Bitmaps , jedoch wird damit die Geometrie tatsächlich verändert , also es wird keine Oberflächenstruktur mehr nur vorgetäuscht .

[Demirug]

Displacement mapping geht auf Matrox zurück und wurde, wie Aquaschaf schon gesagt hat, in die DX9 Specifikation aufgenommen.

Allerdings benutzt man keine Graustufen-Bitmaps sonder Normal-Vektoren-Maps. Als BMP sehen diese sehr bunt aus, da die X,Y und Z-Werte als RGB Werte hinterlegt sind.

So wie die Lage derzeit aber aussieht würde ich dieses Feature aber in keinem Spiel erwarten.

-NVIDIA beherscht diese Technik nur durch einen Trick der keine gute Performances erwarten läst.

-ATI unterstützt nur eine stark eingeschränkte Variante und diese ist mit den aktuellen Treibern noch sehr CPU lastig da grosse Teile nicht vom Chip gerechnet werden.

-Matrox beherscht das Verfahren zwar aber aufgrund der geringen Anzahl von Matroxkarten in spielerhänden ist es für die Entwickler uninteresant.

-Der neue Vertex-Shader 3.0 enthält Features die DM überflüssig machen. Derzeit gibt es zwar noch keinen Chip der VS 3.0 beherscht aber diese dürften relative schnell verfügbar werden.

[Xmas]

Originally posted by Demirug
Allerdings benutzt man keine Graustufen-Bitmaps sonder Normal-Vektoren-Maps. Als BMP sehen diese sehr bunt aus, da die X,Y und Z-Werte als RGB Werte hinterlegt sind.
Man benutzt beides. Eine Heightmap für das Displacement und eine Normalmap für die Normalen.

[Demirug]

Xmas, wir liegen beide etwas daneben. Ich habe mir jetzt extra nochmal die entgültige Spec angeschaut.

Das ganze funktioniert nach dem Prinzip das auf ein Input element des Vertexshaders der Sample wert gelegt wird. Im Vertexbuffer müssen für diesem Stream die UV-Koordinaten der Textur als Float2 Wert gespeichert sein. Dabei wird aus dem RGBA Wert der Textur das XYZW des VS-Inputs. Im Prinzip ist jedes Texturformat erlaubt. Der Treiber darf allerdings einschrängungen vornehmen. Man kann also entweder eine Highmap oder eine Normalmap benutzen aber es ist immer nur eine Textur für das DM erlaubt. Man könnte allerdings wenn der Chip RGBA Texturen als DM-Input erlaubt den Vector in den RGB Teil und die Höhe in den Alpha Teil packen. Wenn man aber möchte kann man auch ganz andere wilde Dinge damit anstellen.

[Gohan]

Originally posted by Demirug
So wie die Lage derzeit aber aussieht würde ich dieses Feature aber in keinem Spiel erwarten.


Falsch ;) Earth & Beyond nutzt es schon :)

[robbitop]

wie siehts denn mit dem Veature in den VS 3.0 Shadern aus?
funktioniert das genauso? Wenn nicht worin unterscheidet es sich?
UND: wie CPU lastig ist das dann?

Ausserdem sollen die VS/PS 2.0 extendet bis auf ein paar features schon an PS/VS 3.0 Specs dran sein habe ich gehört...

[ow]

Originally posted by Gohan


Falsch ;) Earth & Beyond nutzt es schon :)


Quelle?
Ich glaub´s nämlich nicht, da es AFAIK noch gar keine DX9 Games gibt.

[nggalai]

Hi robbitop,Originally posted by robbitop
wie siehts denn mit dem Veature in den VS 3.0 Shadern aus?
funktioniert das genauso? Wenn nicht worin unterscheidet es sich?
UND: wie CPU lastig ist das dann?

Ausserdem sollen die VS/PS 2.0 extendet bis auf ein paar features schon an PS/VS 3.0 Specs dran sein habe ich gehört... VS3.0 lassen Texturzugriffe in einem Vertex Shader zu. Dann noch eine Tesselation-Einheit oder ein vernünftiges LOD-Verfahren, und Du hast dein Displacement Mapping.

Mit VS2.0 (+) läuft das bei NV anders--die GFFX hat ja keine Tesselationseinheit, und kann keine Texturwerte im Vertex Shader sampeln. Aber: man kann in einen Vertex-Array rendern und so mitm VS und PS zusätzliche Vertexstreams erzeugen, um Displacement Mapping zu unterstützen. Nachteil: braucht mehr Passes (ich glaube 2 passes anstelle eines mit einer "richtigen" DM-Engine), wird also u.U. ziemlich schnell ziemlich langsam.

ta,
-Sascha.rb

[Gohan]

Originally posted by ow
Quelle?
Ich glaub´s nämlich nicht, da es AFAIK noch gar keine DX9 Games gibt.

Es muss auch nicht über DX9 angesprochen werden. Die Parhelia DM Demos brauchen's ja auch nicht.
Stand afaik irgendwo mal im Matrox Support Forum.

[Xmas]

Originally posted by Demirug
Xmas, wir liegen beide etwas daneben. Ich habe mir jetzt extra nochmal die entgültige Spec angeschaut.

Das ganze funktioniert nach dem Prinzip das auf ein Input element des Vertexshaders der Sample wert gelegt wird. Im Vertexbuffer müssen für diesem Stream die UV-Koordinaten der Textur als Float2 Wert gespeichert sein. Dabei wird aus dem RGBA Wert der Textur das XYZW des VS-Inputs. Im Prinzip ist jedes Texturformat erlaubt. Der Treiber darf allerdings einschrängungen vornehmen. Man kann also entweder eine Highmap oder eine Normalmap benutzen aber es ist immer nur eine Textur für das DM erlaubt. Man könnte allerdings wenn der Chip RGBA Texturen als DM-Input erlaubt den Vector in den RGB Teil und die Höhe in den Alpha Teil packen. Wenn man aber möchte kann man auch ganz andere wilde Dinge damit anstellen.
Man braucht dennoch Displacement und Normale getrennt, weil das Displacement nichts über die Normale und umgekehrt die Normale nichts über das Displacement aussagt. Schließlich kann man nicht auf Nachbar-Vertices zugreifen.

Ob man nun beides in eine Textur packt oder nur das Displacement im VS benutzt und eine Normalmap im PS, ist dann eben vom gewünschten Lighting abhängig.

[Demirug]

Originally posted by Gohan


Es muss auch nicht über DX9 angesprochen werden. Die Parhelia DM Demos brauchen's ja auch nicht.
Stand afaik irgendwo mal im Matrox Support Forum.

Ja es gibt einen Trick wie man das DM auch mit DX8 nutzen kann.

[Demirug]

Originally posted by Xmas

Man braucht dennoch Displacement und Normale getrennt, weil das Displacement nichts über die Normale und umgekehrt die Normale nichts über das Displacement aussagt. Schließlich kann man nicht auf Nachbar-Vertices zugreifen.

Ob man nun beides in eine Textur packt oder nur das Displacement im VS benutzt und eine Normalmap im PS, ist dann eben vom gewünschten Lighting abhängig.

Beim DM wird ja vor dem Texturzugriff erst mal eine ganz normale Tesselation nach dem N-Patch Verfahren durchgeführt. Dabei werden ja die Positionen, Normalen und Textur-Koordinaten berechnet.

Arbeit man jetzt nur mit einer Highmap wird der Punkt im VS in richtung der normalen verschoben. Enthält die Textur zusätzlich noch eine Vektor Information kann man die normale ebenfalls noch verändern.

Ein zusätzliche Bumpmapping im Pixel-Shader ist davon ja weitgehend unabhängig. Wobei ich da noch ein Problem sehe. Die Bumpmap ist ja für die Grund-Geometrie berechnet. Verändert man jetzt die Geometrie durch ein HOS-Verfahren hat das ja auch auswirkungen auf die Normalen und damit stimmt dann die Bumpmap nicht mehr richtig.

[Xmas]

Originally posted by Demirug
Beim DM wird ja vor dem Texturzugriff erst mal eine ganz normale Tesselation nach dem N-Patch Verfahren durchgeführt. Dabei werden ja die Positionen, Normalen und Textur-Koordinaten berechnet.

Arbeit man jetzt nur mit einer Highmap wird der Punkt im VS in richtung der normalen verschoben. Enthält die Textur zusätzlich noch eine Vektor Information kann man die normale ebenfalls noch verändern.

Ein zusätzliche Bumpmapping im Pixel-Shader ist davon ja weitgehend unabhängig. Wobei ich da noch ein Problem sehe. Die Bumpmap ist ja für die Grund-Geometrie berechnet. Verändert man jetzt die Geometrie durch ein HOS-Verfahren hat das ja auch auswirkungen auf die Normalen und damit stimmt dann die Bumpmap nicht mehr richtig.
Klar, erst wird die Tessellation durchgeführt, dann im VS das Displacement entlang der bei der Tessellation berechneten Normale. Die aus dem Displacement resultierende Normale wird aber dabei nicht berechnet. Und diese ist ja abhängig von den Nachbarwerten, kann deshalb im VS nicht bestimmt werden.

Dafür nimmt man dann eine Normal Map, die die passenden Normalen zum Displacement liefert.

[ow]

Originally posted by Demirug


Ja es gibt einen Trick wie man das DM auch mit DX8 nutzen kann.

Trick = Verletzung der Spezifikation, oder?

[Demirug]

Xmas, jetzt weis ich auf was du hinaus möchtest. Ich hatte da die ganze Zeit noch den ShaderCode von Matrox für das 8.1 DM im Kopf.


vs.1.1
; Matrox Displacement mapping shader.
;
; Displacement value stored in v3.w in hardware mode.
; In software mode, we put it in the same location
; for consistency.
;
; Constants:
;
; c0-c3 - World+View+Projection matrix
;
; c4 - Reserved in hardware mode for setting the displacement parameters. Note
; that the register is user selected.
;
; c5.x - Displacement scale
;
; V Registers
;
; v0 - position
;
; v3 - displacement vector + displacement value
;
; v7 - texture uv

; Decompress position
mov r0, v0

; Scale displacement vector
mul r1, v3, c5.x

; Displace vertex
mul r1.xyz, r1.xyz, v3.w
add r0.xyz, r0.xyz, r1.xyz

; Set displacement as color
mov oD0, v3.w

; Fix for n-patch bug
sge r0.w, v0, v0

; Transform position
m4x4 oPos, r0, c0

; Set texture coordinates
mov oT0.xy, v7


Bei DX9 sieht das allerdings etwas anders aus.


// Shaders used by the BumpEarth D3D sample

// Displacement mapping + bump mapping shader
//
// Float constants used:
// C0 - C3 - transformation matrix
// C4.x - scale factor
//
VertexShader EarthBumpMap = asm
{
vs_1_1
// Input declaration
dcl_position0 v0
dcl_texcoord0 v1
dcl_sample0 v2
dcl_normal0 v3
dcl_texcoord1 v4

// Main function
mul r0, v3, c4.x // Multiply normal by a scale factor
mul r0, r0, v2.x // Multiply normal by the displacement value
add r0, v0, r0 // Add normal to position
mov r0.w, v0.w // W component is taken from the input position
m4x4 oPos, r0, c0 // Transform new position to the projection space
mov oT0, v4 // Copy input texture coordinates
mov oT1, v4 // Copy input texture coordinates
mov oT2, v1 // Copy input texture coordinates
};

// Displacement mapping + no bump mapping shader
//
// Float constants used:
// C0 - C3 - transformation matrix
// C4.x - scale factor
//
VertexShader EarthNoBumpMap = asm
{
vs_1_1
// Input declaration
dcl_position0 v0
dcl_texcoord0 v1
dcl_sample0 v2
dcl_normal0 v3
dcl_texcoord1 v4

// Main function
mul r0, v3, c4.x // Multiply normal by a scale factor
mul r0, r0, v2.x // Multiply normal by the displacement value
add r0, v0, r0 // Add normal to position
mov r0.w, v0.w // W component is taken from the input position
m4x4 oPos, r0, c0 // Transform new position to the projection space
mov oT0, v4 // Copy input texture coordinates
mov oT1, v1
};

technique DisplacementMapping {}


Das mit dem Displacement-Vector hat man also scheinbar wieder fallen gelassen.

Deswegen muss ich dir auch recht geben das man scheinbar wirklich nur einen Skalar sampeln kann. Das macht die Sache doch noch etwas unflexibler als ich dachte.

[ice cool69]

wen juckts?

[Demirug]

Originally posted by ow


Trick = Verletzung der Spezifikation, oder?

Nicht unbedingt. Es ist aber hart an der Grenze.

NVIDIA hat ja auch für die Shadowmaps ein bischen an der Spec gebastelt.

[MeLLe]

Originally posted by ice cool69
wen juckts?
Toller Post.
Entweder bist Du von Silvester noch net wieder auf den Beinen, oder aber Du verstehst von dem, was hier diskutiert wird, nicht die Bohne. Oder Du bist heute aufm PostSchind-Trip.
Suuuuuuuuuuuuuuper. :|

[Gohan]

Originally posted by ow


Trick = Verletzung der Spezifikation, oder?

Mal angenommen ein Spielehersteller nutzt für sein Spiel die tollen shader des GeForceFX die weit mehr als das bieten was DX9 verlangt. Das wäre doch auch eine Verletzung der Spezifikation, oder?

[ow]

Originally posted by Demirug


Nicht unbedingt. Es ist aber hart an der Grenze.

NVIDIA hat ja auch für die Shadowmaps ein bischen an der Spec gebastelt.

Ja ich denke, das tun beide.
Wenn ich mich recht erinnere, sagtest du mal, dass die D3D Specs auch etwas 'unscharf' formuliert sind.
Und ich glaube, dass es daher auch möglich ist, proprietären Code in Treiber und Applikationen unterzubringen, der nicht ganz 'Spec-konform' ist.


@Gohan: AFAIK bietet der GFFX nichts, was über die DX9 Specs (VS/PS3.0!) hinausgeht.

[Demirug]

ow, ja es gibt Stellen die etwas ungenau sind. Diese werde aber eher weniger.

Die GFFX hat in den Shader ein paar Spielereien die man nur unter OpenGL erreichen kann.

[nggalai]

Originally posted by ice cool69
wen juckts? Da wir hier im Technologie-Forum sind--so ziemlich alle Leser? ???

Oder was meintest Du konkret mit dieser Aussage?

ta,
-Sascha.rb

[aths]

Originally posted by Demirug
Die GFFX hat in den Shader ein paar Spielereien die man nur unter OpenGL erreichen kann. Könntest du in ein paar Stichpunkten kennen, was das wäre? Das wäre nett.

[MeLLe]

Originally posted by aths
[...] kennen [...]
aths meint damit "nennen". Nicht "kennen". ;)

[Demirug]

Originally posted by aths
Könntest du in ein paar Stichpunkten kennen, was das wäre? Das wäre nett.

Ich habe jetzt noch nicht alles im Detail betrachtet.

Bei einer schnellen Übersicht ist mir folgenden aufgefallen:

- Sinus und Cosinus werden nach der 2.0 Norm mit Tayler Reien berechnet. Die dafür notwendigen Daten müssen in Konstanten hinterlegt sein. Die FX kann Sinus und Cosinus auch ohne diese Daten berechnen (laut 3.0 norm).

- Die FX übergibt dem Pixelshader die Position des Fragments (x,y,z,1/w). Die Pixelshader 3.0 sehen nur die übergabe von x und y vor.

-Dann gibt es noch ein paar zusätzliche Instructionen.

[mapel110]

Originally posted by Gohan


Mal angenommen ein Spielehersteller nutzt für sein Spiel die tollen shader des GeForceFX die weit mehr als das bieten was DX9 verlangt. Das wäre doch auch eine Verletzung der Spezifikation, oder?

nö, dx9 unterstützt auch die shader der geforceFX.

[aths]

Originally posted by MeLLe
aths meint damit "nennen". Nicht "kennen". ;) Stümmt.