PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Material-Shader


aths
2003-12-30, 00:18:55
Original geschrieben von Demirug
Das mit den Materialshader wird noch etwas dauern. Zum einen ist die Rechenleistung der Chips noch nicht hoch genug dafür. Auf der anderen Seite sind die derzeigten Shaderkonzepten der 3d APIs auch eher unbrauchbar für sowas. Was steht dem denn da entgegen? Erste (noch recht einfache) Konzepte hielte ich sogar schon mit Pixelshader 1.1 für zu verwirklichen. Konkret mit (vorberechneten, oder beim Level-Start per CPU und Render-to-Texture erzeugten) Perlin-Noise-Texturen, welche als "EMBM"-Lookup genutzt werden. Treibt man das weiter, könnte man mit PS.2.0 dank mehrerer Abhängigkeitstufen dieses Perlin Noise noch mit anderen Funktionen (sin, cos, exp, log, ...) modifizieren, um bestimmte Strukturen zu bekommen. Die Oberflächen-Rauheit wird dann beim Pixel-Lighting eingerechnet, um von stumpf bis glatt skalieren zu können.

Gast
2003-12-30, 00:37:47
Es dürfte wohl an der Länge der Shader und an der Rechenleistung liegen. Mit Perlin Noise allein lassen sich nur begrenzt Procedural Shader realisieren. Es gibt dutzende von Noisearten, die teilweise recht rechenaufwendig sind. Dazu kommen Splineberechnungen bei Noisegenerierung und Farbbestimmung hinzu. Oftmals muss man sogar noch zusätzlich noch andere Strukturen erzeugen und diese dann mit dem Noise verrechnen (schon bei einem einfachen Holzshader). Cellular Texturing ist sogar noch komplizierter vom Programmablauf her (bei den vielen Sprüngen freut sich der GPU ;) ), bringt aber meistens imo die schönesten Effekte.
Noch eine unschöne Sache, ist dass man Aliasing eigentlich schon bei der Generierung der Texturen verhindern sollte. Supersampling würde hier schon Besserung bringen ist aber auch nicht auf heuten Grafikkarten vernünftig verfügbar :(

Demirug
2003-12-30, 01:10:28
Die Shaderlänge und die Geschwindigkeit sind einmal nebensächlich. Da holt uns die Zeit schon von aleine ein.

Das Problem ist wie die APIs Shader verwalten. Shader werden nach einem lokalitäts Prinzip verwaltet. Es geht also darum wo der Shader ausgeführt werden soll. Derzeit gibt es da ja nur die Vertex und die Pixelebene und daher auch Vertex- und Pixelshader.

Shading gehört nun aber eigentlich in die Hand der Designer. Ein Designer weiss wie es aussehen soll. Allerdings denkt ein Designer nicht nach einem lokalitäts Prinzip sondern funktionsorientiert. Er weiss das diese Objekt eine Holzoberfläche bekommen soll. Er weiss das er an einer bestimmten Stelle eine Lichtquelle braucht und er weiss auch noch das sein Objekt in sich selbst unbeweglich ist. Für diesen 3 Funktionen muss man jetzt einen passende Vertex- und Pixelshader programmieren. Braucht man das einmal gibt das kein Problem. Will man das gleiche aber jetzt mit einer anderen Lichtquelle braucht man wieder eine neues Shaderpaar. Mit HLSL geht das zwar alles etwas einfacher aber das wahre ist das immer noch nicht.

Wenn man sich einmal vor augen führt wie viele Kombinationsmöglichkeiten sich ergeben. Wenn der Editor dem Designer 5 Lichtquellen, 5 Oberflächenmaterialen und 5 Geometrieeffekte zur verfügung stellt ergeben sich schon 125 verschieden Kombinationsmöglichkeiten wenn man jeweils nur eine Lichtquelle benutzt. Das man mit 5 Oberflächen nicht weit kommt dürfte klar sein und so werden es mehr und mehr Kombinationen.

Im Offlinerenderbereich ist man dem ganzen gleich aus dem Weg gegangen indem man mit Funktionsorientieren Shadern arbeitet die da automatisch richtig kombiniert werden.