Fragen an die 3D Gurus zum Thema Shader

[SynchroM]

Hallo,
ich hab' mir neulich den Artikel über die 3Dc und Pixelgenaue Beleuchtung durchgelesen. Sehr guter Artikel, aber ich kann einige Schlagworte bzw Technologien nicht richtig einordnen. Besonders die Artikel von Wikipedia zu diesen Themen wirken nicht wirklich schlüssig.

Hier mal ein paar einfache Fragen für die Gurus:

- Seit wann gibt es Pixelgenaue Beleuchtung bzw. was sind die technischen Vorraussetzungen dafür und ist Per-Pixel-Lighting das genau gleiche?

- Hat „Vertexshading“ etwas mit den Vertex-Shader Einheiten auf GPU’s zu tun?
Ist die Aussage von Wikipedia richtig: „Dank des Vertex-Shaders sind 3D-Effekte wie Bump Mapping möglich“?

- Werden mit einem Pixel-Shader Programm Pixel oder Texel verändert? Wenn Pixel: welche? (die vom Framebuffer?)

-Was hat Pixel-Shader mit HDR zu tun?

Bitte Bitte keine Pauschalantworten wie zb. „mit PS werden Materialeigenschaften verändert“, so was kann ich überall lesen.

Vielen dank für eure Mühen

[Neomi]

- Seit wann gibt es Pixelgenaue Beleuchtung bzw. was sind die technischen Vorraussetzungen dafür und ist Per-Pixel-Lighting das genau gleiche?

Pixelgenaue Beleuchtung gibt es eigentlich schon, seit es Computergrafik gibt. Damals in Software, inzwischen in Hardware. Ansatzweise ist eine pixelgenaue Beleuchtung in Hardware möglich, seit es Cubemapping gibt, dann werden die Normalen über das Dreieck interpoliert und pro Pixel mit dem Ergebnis ein Lookup in die Beleuchtungscubemap gemacht. Seitdem es Shader gibt, ist die Sache flexibler geworden.

Per-Pixel-Lighting ist nur die englische Übersetzung von pixelgenauer Beleuchtung. Allerdings ist pixelgenaue Beleuchtung nicht gleich pixelgenauer Beleuchtung, es gibt verschiedene Methoden. Sie alle haben gemein, daß die (nicht alle, aber manche) Berechnungen für jeden Pixel einzeln ausgeführt werden.

- Hat „Vertexshading“ etwas mit den Vertex-Shader Einheiten auf GPU’s zu tun?
Ist die Aussage von Wikipedia richtig: „Dank des Vertex-Shaders sind 3D-Effekte wie Bump Mapping möglich“?

Der Begriff "Shader" ist da wirklich ein wenig irreführend für Laien. Die OpenGL-Bezeichnungen "Vertex Program" und "Fragment Program" sind da schon passender. Vertexshading wird manchmal als beliebige Berechnung per Vertexshader verstanden, ist aber eigentlich die Beleuchtung pro Vertex, die dann über das Dreieck interpoliert wird.

Bumpmapping ist auch ohne Vertexshader möglich. Streng genommen ist Bumpmapping grundsätzlich ein pixelbasierter Effekt, hat also mit den Vertexeinheiten nicht viel zu tun. Die werden bei einigen Methoden allerdings benötigt, um Vorarbeit (z.B. Interpolation des Vektors zur Lichtquelle im Tangent-Space) zu leisten.

- Werden mit einem Pixel-Shader Programm Pixel oder Texel verändert? Wenn Pixel: welche? (die vom Framebuffer?)

Weder noch. Es werden Pixel generiert, die dann an die ROPs weitergereicht werden, um im Framebuffer die vorhandenen Pixel zu verändern (Alphablending) oder zu überschreiben. Texel sind "Texturpixel" und dienen nur als Input für Pixelshader bzw. seit Shadermodel 3 auch für Vertexshader. Man kann zwar auch in Texturen rendern, aber zu diesem Zeitpunkt ist die Textur nicht als solche nutzbar, deshalb kann man Texel als unveränderbar betrachten.

-Was hat Pixel-Shader mit HDR zu tun?

Erstmal gar nichts. HDR ist in dem Sinne nur ein Floatingpoint-Format für Texturen bzw. den Framebuffer, ähnlich 16 Bit und 32 Bit. In Floats können allerdings deutlich größere Bereiche als nur 0.0 bis 1.0 gespeichert werden. Wenn man die Daten dann aus einer Textur in einen Shader einspeist, ermöglicht das interessante Effekte. Shader haben mit HDR also genau das zu tun, was die Engine will, sind aber generell eigenständig.

[SynchroM]

Danke ersma!
was sind den die HW Vorrausetztungen für Dot3 BM?
Der Wikipediaeintrag zu Per-Pixel-Lighting kann ja ned stimmen: "Da das Verfahren relativ neu ist, wird es nur von wenigen DirectX 9-kompatiblen Grafikkarten unterstützt." oder? Zumindest dachte ich mal Dot3 BM von 'ner GF2 gesehen zu haben...

[ScottManDeath]

Dot3 Bumpmapping funktioniert ( in einer limitieren Weise) mit Karten auf dem DX 7 Niveau, also z.B. Radeon 7500 oder GeForce 1.


Bezüglich dem Per Pixel Lighting: dies ist nicht ganz korrekt so. Es wird die Lichtberechnung per Fragment durchgeführt. Der Unterschied zw. Pixel & Fragment:

Ein Pixel repräsentiert den Inhalt des Framebuffers an einer bestimmten Position nebst allen zugehörigen Daten wie der Farbe, dem Tiefenwert und sämtlichen anderen Werten die damit verbunden sind. Ein Fragment hingegen umfasst all diejenigen Daten die benötigt werden um möglicherweise einen Pixel an einer bestimmten Stelle zu verändern. Die Fragmentdaten umfassen die Pixelposition, den Tiefenwert sowie die zwischen den Vertices interpolierten Daten wie Farben und Texturkoordinaten. Wenn die Fragmente die Rasteroperationen passiert haben aktualisieren sie Pixel im Framebuffer. Fragmente sind demzufolge "potentielle" Pixel.

[Coda]

Pixelgenaue Beleuchtung gibt es eigentlich schon, seit es Computergrafik gibt. Damals in Software, inzwischen in Hardware. Ansatzweise ist eine pixelgenaue Beleuchtung in Hardware möglich, seit es Cubemapping gibt, dann werden die Normalen über das Dreieck interpoliert und pro Pixel mit dem Ergebnis ein Lookup in die Beleuchtungscubemap gemacht. Seitdem es Shader gibt, ist die Sache flexibler geworden.Sorry, aber da sind einige Fehler drin. Bitte kein Halbwissen verbreiten.

Pixelgenau war bevor es DOT3 Berechnungen gab (seit GeForce 256) gar nix. Davor konnte man nur das Licht an den Vertices berechnen und dann über das Polygon interpolieren. UT2004 macht das z.B. immer noch bei den "Static Meshes".

Damit ist durch eine zusätzliche Normalmap natürlich auch Bumpmapping möglich, aber DOT3 braucht man auch für normales PP-Lighting.

Außerdem ist die Cubemap sicher nicht das entscheidende Feature für Per-Pixel-Lighting sondern eben die DOT3 Fähigkeit. Du schmeißst da übel was durcheinander, die Cubemap wird nur gebraucht um die interpolierten Normalen wieder zu normalisieren.

Ein Vertexshader nimmt Daten vom Vertexstream und Konstanten (darunter auch meistens die Modelview-Projection-Matrix) entgegen und berechnet a) die Position des Eckpunkts und b) die Daten die über das Dreieck interpoliert werden sollen (z.B. Texturkoordinaten oder eine Farbe)

Der Pixelshader nimmt dann die Interpolierten Werte vom Vertexshader und Konstanten entgegen und berechnet daraus die Farbe und eventuell den Z-Wert an diesem Punkt im Dreieck, dabei kann er z.B. mit den interpolierten Texturkoordinaten Texturen samplen.

Danach geht das Ganze dann an die ROPs die es vielleicht noch mit dem Framebuffer vermischen.

-Was hat Pixel-Shader mit HDR zu tun?Nicht sehr viel. Die Shader müssen halt mit Floating-Point-Zahlen rechnen können, was bei allen DX9-Karten der Fall ist. Allerdings braucht man sie für das Postprocessing das HDR erst sinnvoll macht (diese Glow Effekte etc.).

- Hat „Vertexshading“ etwas mit den Vertex-Shader Einheiten auf GPU’s zu tun?
Ist die Aussage von Wikipedia richtig: „Dank des Vertex-Shaders sind 3D-Effekte wie Bump Mapping möglich“?Geht auch ohne, deshalb finde ich das Beispiel etwas schwach. Aber mir fällt spontan auch kein besseres ein.

[SynchroM]

...die Cubemap wird nur gebraucht um die interpolierten Normalen wieder zu normalisieren.
hä, ich dachte die Cubemap ist ein Textur-Kubus, von welchen die Spiegelungen abgeleitet werden...

Heist "Texturen Sampeln" das errechnen eines Pixels aus Texeln?

Allerdings braucht man sie für das Postprocessing das HDR erst sinnvoll macht (diese Glow Effekte etc.).
Heißt das daß PS-Effekte mit HDR besser aussehen?

[Coda]

hä, ich dachte die Cubemap ist ein Textur-Kubus, von welchen die Spiegelungen abgeleitet werden...Dafür kann man sie auch verwenden.

Es ist einfach eine Textur die mit einem Richtungsvector gesampled wird. Stell dir vor du stehst in der Mitte eines Würfels und zeigst in eine Richtung (die Richtung ist der Vektor), dann ist die Farbe an dem Punkt wo du hinzeigst das Resultat des Samplings.

Wenn du die Umgebung in der Cubemap gespeichert hast und du mit dem Oberflächenvektor des Dreiecks samplest, bekommst du natürlich eine wunderbare Reflexion.

Zurück zur Normalisierung: Da bei der Cubemap die Länge des Vektors nicht relevant ist, sondern nur die Richtung kann man sich damit eine Funktion basteln die die Normale eines Vektors zurückgibt indem man einfach zu jeder Richtung die normalisierte Richtung in der Cubemap speichert.

Heute macht man das ganze natürlich per Rechnung im Shader, das geht deutlich schneller und belastet die Bandbreite nicht.

Heist "Texturen Sampeln" das errechnen eines Pixels aus Texeln?Nicht direkt. Es ist einfach das lesen eines Wertes aus einer Textur an einem bestimmten Punkt/Richtung. Der Shader kann damit machen was er will.

Heißt das daß PS-Effekte mit HDR besser aussehen?Das Resultat wird erstmal genauer gespeichert und kann dadurch besser beim Postprocessing verarbeitet werden. Ohne Postprocessing ergibt sich durch HDR eh kein sichtbarer Unterschied, außer das eventuell das Banding etwas reduziert wird.

[Neomi]

Sorry, aber da sind einige Fehler drin. Bitte kein Halbwissen verbreiten.

Pixelgenau war bevor es DOT3 Berechnungen gab (seit GeForce 256) gar nix. Davor konnte man nur das Licht an den Vertices berechnen und dann über das Polygon interpolieren. UT2004 macht das z.B. immer noch bei den "Static Meshes".

Damit ist durch eine zusätzliche Normalmap natürlich auch Bumpmapping möglich, aber DOT3 braucht man auch für normales PP-Lighting.

Außerdem ist die Cubemap sicher nicht das entscheidende Feature für Per-Pixel-Lighting sondern eben die DOT3 Fähigkeit. Du schmeißst da übel was durcheinander, die Cubemap wird nur gebraucht um die interpolierten Normalen wieder zu normalisieren.

Sorry, aber da sind dir ein paar Interpretationsfehler unterlaufen. Halbwissen ist das nicht, was ich da geschrieben habe.

Mit einer Cubemap ist pixelgenaue Beleuchtung machbar, wenn natürlich auch nicht die besseren Methoden. Deshalb steht da ja auch "ansatzweise" dabei. Phongshading ist definitiv möglich per Cubemap und es sieht deutlich besser aus als Gouraudshading. Der Großteil der Beleuchtung ist zwar schon vorab in die Cubemap gewandert, aber trotzdem ist es pixelbasiert. Oder hängst du dich daran auf, daß das Licht nicht vollständig berechnet, sondern nur pro Pixel gesampelt wird?

Daß eine Cubemap für pixelgenaues Licht entscheidend ist, habe ich jedenfalls nie behauptet. Sie war aber die erste Möglichkeit, sowas zu realisieren, bevor bessere kamen.

Ein Vertexshader nimmt Daten vom Vertexstream und Konstanten (darunter auch meistens die Modelview-Projection-Matrix) entgegen und berechnet a) die Position des Eckpunkts und b) die Daten die über das Dreieck interpoliert werden sollen (z.B. Texturkoordinaten oder eine Farbe)

Der Pixelshader nimmt dann die Interpolierten Werte vom Vertexshader und Konstanten entgegen und berechnet daraus die Farbe und eventuell den Z-Wert an diesem Punkt im Dreieck, dabei kann er z.B. mit den interpolierten Texturkoordinaten Texturen samplen.

Danach geht das Ganze dann an die ROPs die es vielleicht noch mit dem Framebuffer vermischen.

Und wo widerspricht das jetzt dem, was ich geschrieben habe?

[Coda]

Mit einer Cubemap ist pixelgenaue Beleuchtung machbar, wenn natürlich auch nicht die besseren Methoden. Deshalb steht da ja auch "ansatzweise" dabei. Phongshading ist definitiv möglich per Cubemap und es sieht deutlich besser aus als Gouraudshading.Das must du mir jetzt genauer erklären. Ich kenne keinerlei solches Verfahren.

Und wo widerspricht das jetzt dem, was ich geschrieben habe?Nirgends, war nur eine genauere Ausführung für SynchroM.

[SynchroM]

Dafür kann man sie auch verwenden.
Zurück zur Normalisierung: Da bei der Cubemap die Länge des Vektors nicht relevant ist, sondern nur die Richtung kann man sich damit eine Funktion basteln die die Normale eines Vektors zurückgibt indem man einfach zu jeder Richtung die normalisierte Richtung in der Cubemap speichert.
hmmm blick' ich ned so richtig. Soll das heißen dass der Kubus eine Normal-Map enthält?

[Coda]

Ja. Aber wie gesagt, das Verfahren verwendet heute keiner mehr. NV40 kann eine genauere Normalisierung in nur einem Takt per Arithmetik machen.

[Neomi]

Das must du mir jetzt genauer erklären. Ich kenne keinerlei solches Verfahren.

Na denn, pixelgenaue Beleuchtung per Fixed Function Pipeline...

Diffuse:

Eine Basistextur in Stage 0, die Phongmap (Beleuchtung in Worldspace enthalten) in Stage 1. D3DTSS_TEXCOORDINDEX für Stage 1 wird auf D3DTSS_TCI_CAMERASPACENORMAL gesetzt. Ob D3DTSS_TEXTURETRANSFORMFLAGS noch auf D3DTTFF_COUNT3 gesetzt werden muß, weiß ich jetzt nicht mehr genau, die Variante habe ich nämlich schon länger nicht mehr genutzt. Eine Texturtransformationsmatrix kann und muß man auch noch setzten, und zwar den Rotationsteil (invertiert) der Viewmatrix. Damit bekommt man die Cameraspace-Normalen wieder in Worldspace und kann die Beleuchtung aus der Cubemap sampeln. Die Beleuchtung mit der Basistextur moduliert ergibt dann die finale Farbe, natürlich kann man aber die anderen Stages nach eigenem Ermessen auch anders nutzen.

In der Cubemap steht für jede Richtung logischerweise das Licht, das aus dieser Richtung kommt. Nicht nur Zwischenwerte zur Renormalisierung, sondern direkt das finale Licht. Das funktioniert zwar nur für paralleles Licht wie z.B. die Sonne, aber damit eben pixelbasiert. Und man kann beliebig viele Lichtquellen in die Cubemap packen.

Specular:

Genau so wie oben, nur mit D3DTSS_TCI_CAMERASPACEREFLECTIONVECTOR. Natürlich kann man dann nicht die gleiche Cubemap wie oben nutzen, sondern braucht eine mit vorberechneten Glanzlichtern.

Nirgends, war nur eine genauere Ausführung für SynchroM.

Soll man etwa bei so grundlegenden Fragen gleich 20 Seiten Detailerklärungen schreiben?

[Coda]

Das funktioniert zwar nur für paralleles Licht wie z.B. die Sonne, aber damit eben pixelbasiert. Ah ok, ich hab mich nur gewundert was mit dem Falloff passiert :)

Soll man etwa bei so grundlegenden Fragen gleich 20 Seiten Detailerklärungen schreiben?Das war kein Angriff gegen dich. Der Absatz stand rein zufällig darunter.

[SynchroM]

noch eine dumme Frage zum Vertex-Shadern: Ein Vertexshader nimmt Daten vom Vertexstream und Konstanten (darunter auch meistens die Modelview-Projection-Matrix) entgegen und berechnet a) die Position des Eckpunkts und b) die Daten die über das Dreieck interpoliert werden sollen (z.B. Texturkoordinaten oder eine Farbe)

Ich dachte Vertices sind schon Eckpunkte?

Ist es richtig dass ein Vertex-Programm dazu da ist Dreiecke zu bewegen?
Wenn ja: Könnte man dann nicht auch Physikberechnungen machen? z.b. Position = 1/2*(m*g)*t*t (ein fallender Gegenstand)

Was kann man sonst noch mit Vertex-Programmen verändern? Viele sagen daß T&L der Vorgänger von den Vetex-Shadern ist. Ich dachte T&L hat eine feste Aufgabe und macht immer das gleiche. Ein Programm ist für mich was anderes!
Kann jemand mal ein Beispiel von einem Vertex-Programm machen (z.B. in Pseudocode)

[Neomi]

Ah ok, ich hab mich nur gewundert was mit dem Falloff passiert :)

Tja, das wäre dann die erste große Einschränkung für dieses Verfahren. Halbwegs realistische Beleuchtung war damit natürlich nicht machbar, aber immerhin das Beste, was machbar war. Deutlich besser als Gouraud, und Shader gab es eben noch nicht.

Das war kein Angriff gegen dich. Der Absatz stand rein zufällig darunter.

Ah, OK, dann hatte ich das falsch aufgeschnappt.

[Coda]

Tja, das wäre dann die erste große Einschränkung für dieses Verfahren. Halbwegs realistische Beleuchtung war damit natürlich nicht machbar, aber immerhin das Beste, was machbar war. Deutlich besser als Gouraud, und Shader gab es eben noch nicht.Naja, dann doch besser Vertexlight. Also gar kein Falloff ist unbrauchbar, außer für Sunlight eben.

[Demirug]

Naja, dann doch besser Vertexlight. Also gar kein Falloff ist unbrauchbar, außer für Sunlight eben.

IIRC gab es da noch einen Trick mit einer 1D Texture über die man einen Falloff hinbekommen hat.

[Coda]

Dann belastet man aber mindestens noch die CPU mit den Distanzberechnungen zum Licht - aber lassen wir das.

Gibt es überhaupt Hardware die Cubemaps aber kein DOT3 können?

[Neomi]

Naja, dann doch besser Vertexlight. Also gar kein Falloff ist unbrauchbar, außer für Sunlight eben.

Ansichtssache, obwohl ich es auch so sehe. Vertexlight für Punktlichtquellen, pixelgenaues Cubemapgetrickse für Sonnenlicht. Man kann ja kombinieren...

[Xmas]

Ich dachte Vertices sind schon Eckpunkte?
Ja, Eckpunkt ist einfach nur das deutsche Wort. Nun gibt es aber transformierte (nach dem VS) und untransformierte (vor dem VS) Eckpunkte.

Ist es richtig dass ein Vertex-Programm dazu da ist Dreiecke zu bewegen?
Wenn ja: Könnte man dann nicht auch Physikberechnungen machen? z.b. Position = 1/2*(m*g)*t*t (ein fallender Gegenstand)
Das funktioniert nur so lange wie Objekte nicht miteinander interagieren(also hauptsächlich: kollidieren). Nun ist aber genau das gerade das Interessante bei den Physikberechnungen. Konstante Beschleunigung ist eine einfache Berechnung pro Objekt, diese dann pro Eckpunkt zu machen wäre Verschwendung.


Was kann man sonst noch mit Vertex-Programmen verändern? Viele sagen daß T&L der Vorgänger von den Vetex-Shadern ist. Ich dachte T&L hat eine feste Aufgabe und macht immer das gleiche. Ein Programm ist für mich was anderes!
Kann jemand mal ein Beispiel von einem Vertex-Programm machen (z.B. in Pseudocode)
T&L ist trotzdem der Vorgänger, weil Vertex Shader T&L komplett ersetzt.

Ein Vertex Shader berechnet mindestens die Position des Eckpunktes im Projection Space, dazu kommen optional Farben, Texturkoordinaten und Vertex-Fog welche dann über die Dreiecke interpoliert werden, sowie Point Size wenn man Point Sprites rendert.
Dabei ist zu sagen dass die interpolierten Größen wie z.B. Texturkoordinaten auch beliebig anders interpretiert werden können. Häufig beispielsweise als Normalen.

Ein bisschen simples HLSL:

struct vs_input
{
float4 Position : POSITION; // vertex position
float4 Normal : NORMAL; // vertex normal
};

struct vs_output
{
float4 Position : POSITION; // vertex position
float3 Normal : TEXCOORD0; // vertex normal
};

void SceneVS(in vs_input IN, out vs_output OUT,
uniform float4x4 ModelViewProj,
uniform float4x4 ModelViewIT)
{
OUT.Position = mul(IN.Position, ModelViewProj);
OUT.Normal = mul(IN.Normal, ModelViewIT);
}