Hypothetische Frage zu einem Shader

[starcow]

Eine Frage an die Grafikexperten hier.

Wäre es mit einem vertretbaren Aufwand möglich einen Shader zu programmieren, welcher - anstatt der eigentlichen Textur - die Texel des Polymeshes mit einer Farbe nach folgedem Konzept coloriert?
Das Konzept sieht folgendes vor:
Der Shader schaut sich an, wie gross der dargestellte Texel im final gerenderten Bild ist, und färbt ihn entsprechend der Grösse ein. Ist die Fläche auf welcher der Texel sitzt der Kamera stark abgewandt, soll das die Coloration nicht beeinflussen.
Ist der Texel 1 Pixel oder kleiner, wird er weiss dargestellt.
Ist der Texel zwischen 1 Pixel und 2 Pixel, wird er als Gradient (je nach genauem Wert) zwischen Weiss und Grün dargestellt
Ist der Texel zwischen 2 Pixel und 4 Pixel, wird er als Gradient (je nach genauem Wert) zwischen Grün und Rot dargestellt
Ist der Texel zwischen 4 Pixel und 8 Pixel, wird er als Gradient (je nach genauem Wert) zwischen Rot und Blau dargestellt

Gruss starcow

[Krishty]

ddx() & ddy() geben den Gradienten der Texturkoordinate an, nach dem das Mip-Level berechnet wird :)

[unbird]

Oder du samplest normal mit einem linearen Filter aber machst eine Textur mit miplevel 0 komplett weiss, miplevel 1 grün, miplevel 2 rot etc.

[Krishty]

Der Shader schaut sich an, wie gross der dargestellte Texel im final gerenderten Bild ist, und färbt ihn entsprechend der Grösse ein. Ist die Fläche auf welcher der Texel sitzt der Kamera stark abgewandt, soll das die Coloration nicht beeinflussen.

Falls mit „stark abgewandt“ eigentlich „in sehr flachem Winkel“ gemeint ist, wird das schwer, weil ein linearer Filter dann ungewollt in niedrigere Mip-Levels runterschaltet. Klingt für mich wirklich danach, als sei max(length(ddx(uv)), length(ddy(uv))), was er braucht.

[starcow]

Ich danke euch für die wertvollen Antworten. :-)

Falls mit „stark abgewandt“ eigentlich „in sehr flachem Winkel“ gemeint ist, wird das schwer, weil ein linearer Filter dann ungewollt in niedrigere Mip-Levels runterschaltet. Klingt für mich wirklich danach, als sei max(length(ddx(uv)), length(ddy(uv))), was er braucht.

Ja, genau, das war so gemeint! Anders formuliert: Die Entfernung hat Einfluss, nicht aber die Polygon-Normale.
Der Ansatz, das ganze einfach per MIP-Map zu lösen erscheint sehr einfach und praktisch - nur sehe ich neben deinem Einwand noch den Umstand, dass mit einer vorbereiteten MIP-Map der Farbverlauf fehlen würde.

Ist dein Vorschlag auch unter OpenGL oder Vulcan realisierbar?

Edit:
Oder sind das gar keine DirectX Funktionen, die du gepostet hast? :>

Gruss starcow

[Schrompf]

ddx/ddy gibt es sowohl unter DirectX / HLSL als auch unter OpenGL / GLSL. Vulkan benutzt auch eine Art GLSL, und ich bin ziemlich sicher, dass es so grundlegende Funktionen wie ddx/ddy da auch gibt. Ich bezweifle aber, dass Du Vulkan bereits benutzen kannst. Selber schreiben wäre ein mehrtägiges Unterfangen, und fertige Engines mit Vulkan gibt es sicher noch nicht.

[Krishty]

Der Übergang wäre mit Mip-Levels schon weich, wenn der Filter trilinear ist (also zwischen Mips interpoliert). Aber wie gesagt, Mip-Maps hängen von der Neigung der Fläche ab. Mit ddx() / ddy() kannst du halbwegs drum herum bauen.

[dot]

Aber wie gesagt, Mip-Maps hängen von der Neigung der Fläche ab. Mit ddx() / ddy() kannst du halbwegs drum herum bauen.

Wie genau funktioniert das, ddx()/ddy() der Texcoords hängen doch genauso von der Neigung der Fläche ab!? Deine obige Formel mir max(length(ddx(uv)), length(ddy(uv))) ist doch exakt, was die Mip-Map Selection macht!?

[Krishty]

Die Mip-Selection nimmt doch min(), oder? Mom ich male was

[dot]

Nope, nimmt das hier:

\($\rho = \max\left\{\sqrt{\left(\frac{\partial u}{\partial x}\right)^2 + \left(\frac{\partial v}{\partial x}\right)^2}, \sqrt{\left(\frac{\partial u}{\partial y}\right)^2 + \left(\frac{\partial v}{\partial y}\right)^2}\right\}$\)

Edit: LaTeX wieder mal kaputt?

[Krishty]

Ja; ist wieder kaputt :(

Mein Denkfehler war, dass ich vergessen hatte, dass dd größer wird, wenn die Textur gestaucht wird (nicht kleiner). Da muss man sich an min() halten, da hast du völlig recht :)

Beispiel von hier (weil’s so scheiße schwer ist, solche Screenshots als was anderes als JPG zu finden); ddx() und ddy() stark überhöht reingemalt:

1. der problemlose Fall
2. der gestauchte Fall

[Chromanoid]

Ja; ist wieder kaputt :(

Nee, man muss es nur richtig benutzen :P ich hab mal einen Hinweis in den Tooltip gepackt.

[starcow]

Super, danke für deine Zeichnung Krishty :-) So wird sofort klar was gemeint ist!

Ich versuche das nun entsprechend euren Tipps umzusetzen.

Vielen Dank und Gruss! :)

starcow