Prodedurales Enviroment Bumpmapping mit Pixel Shader 1.3

[aths]

Sehe ich das richtig, dass prozedurales Bumpmapping beim PS < 1.4 mindestens 2 Passes erfordert? Wenn die zu sampelnden Textur-Koordinaten erst durch einen Shader bestimmt werden, kann man ja offensichtlich nicht im gleichen Shader diese Koordinaten nutzen um aus einer anderen Textur zu sampeln? Für Material Shader ist das doch eine ziemliche Einschränkung?

[Demirug]

Was du meinst sind "dependent Texture reads".

Alle PS 1.x shader haben da ein Limit von 1. Aus dieser Aussage kann man schon erahnen das es auch mit den PS 1.1 - 1.3 funktioniert.

Der unterschied zwischen PS 1.1-1.3 und PS 1.4 ist dabei das bei den 1.4 Shadern alle mathematischen operationen die für Farboperationen zur verfügung stehen auch für Texturkoordinaten benutzen kann. Bei den 1.1 - 1.3 Shadern gibt es nur eine begrentzte Auswahl von Operationen und für manche dieser Operation verliert man Textursamples.

Reicht dir das als Information?

[aths]

Ja, ich meine dependent texture reads. Die sind afaik ab 1.0 möglich, nur kann man eben nur eine andere Textur als Displacement nutzen, und dieses nicht erst vorher im Shader berechnen, weil erst die Textursample-Anweisungen kommen und dann die Instruktionen.

Meine Frage zielte eher darauf ab, wie schlimm der Zwang zum Dual Pass für Material Shader ist.

[Demirug]

Originally posted by aths
Ja, ich meine dependent texture reads. Die sind afaik ab 1.0 möglich, nur kann man eben nur eine andere Textur als Displacement nutzen, und dieses nicht erst vorher im Shader berechnen, weil erst die Textursample-Anweisungen kommen und dann die Instruktionen.

Meine Frage zielte eher darauf ab, wie schlimm der Zwang zum Dual Pass für Material Shader ist.

ja erst kommen die Texturanweisungen und dann die Coloranweisungen. Es gibt allerdings ein paar Texturanweisungen welche bevor sie das Sample auslesen noch eine Berechung mit den Texturcoordinaten vornehmen.

z.B.

PS 1.2

tex t1
texdp3 t2, t1

1. Wert aus einer Texture mit den ersten Texturekoordinaten auslesen und in t1 speichern

2. Bildet das Dot Produkt zwischen t1 und den zweiten Texturekoordinaten repliziert den Skalar auf alle 4 Elemente und benutzt diese dann als Texturkoordidaten für das Sample das in t2 gespeichert wird.

oder PS 1.1

tex t0
texm3x3pad t1, t0
texm3x3pad t2, t0
texm3x3tex t3, t0

macht folgendes.

t0 wird ganz normal gesampelt.

u = Textcoord1.UVW dot T0.RGB
v = Textcoord2.UVW dot T0.RGB
w = Textcoord3.UVW dot T0.RGB

t3 = Sampel aus dem Sampler 3 mit den Koordinaten (u v und w)

Ein bischen rechnen geht also schon ;)

Und nun zu deiner Frage. Multipass ist immer schlecht. Man verliert Genauigkeit muss die Geometrie zweimal durchrechnen und sich vorallem überlegen was den nun die besten stellen zum spliten sind.

In der Praxsis sind aber nicht unbedingt die eingeschränken rechenmöglichkeiten hinderlich sonder das man nur 4 Texturen (oder weniger) zur verfügung hat.

[aths]

Ich habe studiumsbedingt leider praktisch keine Zeit, und vom Pixelshading auch wenig Ahnung. Was mir allerdings seit einiger Zeit so im Kopf herumspukt, ist ein "Material Creator". Da stelle ich mir vor, bis zu 4 Texturen (per Drop-Down-Liste) für wählen zu können und verschiedene Verknüpfungen zu wählen. Das Programm "compiliert" daraus den Pixel Shader. Anwendungsmöglichkeit: Ich bastel mir einmal ein "poliertes Metall" zusammen, und kann das später variieren. Oder ich bau mir einmal Wolken, die dann durch andere Perlin-Noise-Texturen verändert werden können. Oder Holz, Marmor... eben eine Möglichkeit, möglichst viele Texturen durch Materialen zu ersetzen.

Dabei ist prozedurales Bumpmapping sicherlich nützlich, z.B. für Wasser. Ich finde, dass man von Texturen langsam mal wegkommen sollte, weil sie viel Speicher fressen und nicht gerade vielseitig verwendbar sind. (Gemeint ist natürlich nicht, auf Lookup-Texturen oder gewisse Basis-Texturen zu verzichten. Doch wenn man z.B. einen abwechslungsreich gestalteten Marmor-Fußboden redern möchte, müsste man mit der Multitexturing-Methode erst mal massig vorgerenderte Texturen haben. Die dann auch unveränderbar sind. Daher denke ich, sollte man Polygone mit Materialen versehen statt sie zu texturieren.)

[Demirug]

aths, solche "Materialeditoren" gibt es für Profi 3D Engines schon lange (spätestens seit den DX7 Engines). Und solange man nur mit Lightmaps gearbeitet hat waren diese Teile auch echt gut.

Seit man aber nun mit so wiederlichen sachen wie dynamisches per Pixel Light angfängt funktioniert das ganze irgendwie nicht mehr so richtig. Das Problem liegt darain das der Pixelshader ja nicht nur die Materialfarbe bestimmen muss sondern auch noch die Wirkung einer (oder mehrere) Lichtquelle auf dieses Material. Das hat dann auch wieder rückwirkungen auf den Vertexshader da dieser bestimmte Grunddaten liefern muss.

Und bei prozeduralen Shadern ist mit zusammen klicken sowieso nichts mehr drin weil man ja die Oberflächeneigenschaften des Materials als Formel ausdrücken muss.

Und genau an dieser Stelle kommen nun die neuen Shaderhochsprachen ins Spiel.

Man schreibt sich zum Beispiel eine Funktion welche die wichtigen Eigenschaften (Farbe für Diffuses und Spekulares Licht, Bumpvektoren, ...) einer Holzoberfläche berechnen kann.

Genauso schreibt man für die Lichtquellen entsprechende Funktionen welche die Lichtmenge und den Vektor berechnen mit dem das Licht auf einen Variablen Punkt auftrift.

In der eigentlichen Shaderhauptfunktion ruft man dann nur noch diese Funktionen auf. Damit kann man dann durch austauschen von nur wenigen Funktionsaufrufen ganz schnell den Type der Lichtquelle ändern. Oder mit Copy und Paste und Edit für eine Oberflächenmaterial einen zweiten schader mit einem anderen Lichtquelletype erzeugen.

Und damit man noch etwas unabhängier vom Technologielevel der Karte wird kann man die Funktionen welche die Oberflächen und Lichtdaten liefern durch entsprechende Präprozessor anweisungen dazu bringen unterschiedliche Dinge zu tun. (Zum Beispiel bei DX8-Karten Holz als Texture und bei DX9-Karten Holz als Mathematische-Funktion)

Die ganze Sache hat allerding noch ein paar Hacken. Man programmiert immer noch die Pixel und Vertexshader getrennt und muss die Schnittstellen zwischen den Funktonseinheiten (Vertexinput und Vertextoutput/Pixelinput) genau festlegen. Dadurch ist der Compiler nicht in der Lage globale Optimierungen für einen Shader durchzuführen. Das heist er ist nicht in der Lage eine Berechnung vom Pixel in den Vertexshader zu verschieben wenn eine per Pixel Berechnung gar nicht notwendig wäre. Oder Vertexdaten die gar nicht gebraucht werden aus den Inputs zu entfernen. Solche fälle können sehr schnell auftreten wenn man das gleiche Material einmal mit einer komplexen und einmal mit einer einfache Lichtquelle beleuchtet. Und dann muss man leider doch wieder Hand anlegen. Und was überhaupt nicht geht ist Teile der Berechnung die nur einmal pro Primtive oder für alle Dreiecken welche mit einem Shader in einem Frame gebraucht werden in der Shadersprache (HLSL, Cg oder gslang) zu schreiben und dann beim selektieren des Shader bzw. bei jeden Drawprimtive Call von der CPU ausführen zu lassen.

Es gibt also noch viel zu tun um mich zufrieden zu stellen. ;)

PS: Nachdem was ich gehört habe hat sich Faktor 5 für den Gamecube für das Spiel Star Wars: Rogue Leader einen Shader generator gebaut welcher aus Material und Licht teilen den Code für die Shaderpipeline erzeugt. Das ganze soll sogar zum Teil in Realtime funktionieren.

PPS: das wurde jetzt etwas viel Text