Hey Leute,

ich hab mal wieder n Shader-Problem und zwar hab ich mir einen Deferred Renderer gebaut. Der muss im Fragment-Shader 7 Lookups in verschiedenen Texturen machen. TexCoord ist bei allen Lookups gleich. Kann ich die Lookups da irgendwie optimieren? Ich hatte an ein Texture2D-Array gedacht, aber da müsste ich die ja erst von der Graka in den RAM laden und dann als richtiges Texture-Array wieder auf die Graka packen. Kann ich das vlt. schon irgendwie beim generieren der Texturen optimieren, sodass ich's dann beim Lookup einfacher hab?

MfG & Thx Bergmann.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.

7 Lookups hört sich nach 7 Texturen im G-Buffer an … was speicherst du denn da alles? Ich komme wunderbar mit 4 aus (Diffuse Color, Position, Normal, Specular Color).
Ich weis dass man da noch ohne Probleme weitere aufnehmen könnte für hübsche Effekte und so, aber das sind denk ich die grundlegenden.

Eine Möglichkeit direkt in ein Texture Array zu schreiben (außer evtl mit Compute shadern) ist mir nicht bekannt. Ich würde versuchen die Anzahl der Texturen zu minimieren.
Du könntest z.B. werte packen. Z.B. Werte zw. -1 und 1 in ein 16bit float und dann jeweils 2 in einem kanal speichern. Dabei wirst du aber unweigerlich Genauigkeit verlieren. Ich hab mal ausprobiert alle 3 Komonenten einer Normale in einen Kanal zu packen, das war aber ne blöde Idee

Du solltest auch darauf achten für die Beleuchtung den Depth-Buffer der Scene zu benutzen um Fragmente der Light-Volumes, die nicht gezeichnet werden, auch nicht beachten zu müssen.
Zusätzlich könntest du den Stencil buffer benutzen um Pixel zu maskieren die tatsächlich in einem Light-Volume liegen, dadurch würdest du das überflüssige Berechnen eines Haufen pixels durch 2 maliges Zeichnen des Volumes in den Stencil buffer ersetzen. siehe http://ogldev.atspace.co.uk/www/tutoria ... ial37.html

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Position kann man sich auch sparen, wenn man die Position aus dem Depthwert und der X/Y-Position des Pixels berechnet

Hey,

@Shaijan:
ich hab folgende Buffer:

Das mit dem packen ist ne gute Idee. Bei den ganzen Farben brauch ich das eh nich so genau. Hast du nen guten Algo dafür? Ich hab auf anhieb den hier gefunden:

@OpenglerF:
Die Position brauch ich doch aber für die Lichtbrechnung im ModelView. Wenn ich Fragment.xy + depth nehme dann ist das ja im ProjectionView. Die Matrix zum zurück rechnen hab ich nicht mehr, oder kann ich die Normalen vorher mit der Projektions-Matrix multiplizieren und dann einfach alles im ProjectionView rechnen?


€: Hab das mit dem packen grad mal durchgerechnet. Wenn ich mit ner Genauigkeit von 2^8 = 256 packe, dann hab ich einen maximalen Wert von 2^8^2 = 65535. Bei half-precision (16bit) floats werden Werte zwischen 32769 und 65536 auf ein Vielfaches von 32 gerundet. Heißt die beiden Werte würden unterschiedlich genau gespeichert werden: einer mit 8bit und einer mit 3bit = 10bit fraction + 1bit = 11bit. Wenn ich hingegen eine "normale" Textur mit 16bit Kanälen nutze, dann hab ich die vollen 16bit zur Verfügung und ich hätte kein Verlust. Natürlich müsste dann die pack und unpack Function noch etwas angepasst werden:

Seh ich das richtig, oder hab ich noch irgendwo nen Denkfehler?

MfG Bergmann.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.

Die Buffer scheinen mir deutlich überdimensioniert.
Welcher Wer steht überhaupt in "shadow"? Unter den Werten des 7. Buffers kann ich mir ebenfalls nicht vorstellen.
Ich denke nicht, dass es sinnvoll ist, die Materialwerte in RGB zu speichern. (Außerdem ist der Alphawert sowieso ungenutzt)
Ich würde besser nur einen Luminanzwert speichern und die Farbe weglassen. Alleine physikalisch betrachtet, ergibt es keinen Sinn. Das Licht trifft auf eine Oberfläche auf und wird in Teilen absorbiert und der rest wieder zurückreflektiert. Das gibst du bereits mit der "Color" an. Glanzlicht ist einfach die "Rauheit". Den Ambientwert würde ich ebenfalls nicht im Material hinterlegen sondern diesen Wert global für die Szene setzen. Er hat ja den Sinn, das indirekte Licht der Natur zu ersetzen und das ist auch nicht an Materialien gebunden sondern wird durch die Umgebung bestimmt. Auch den Diffusewert kann man dann noch mathematisch herauskürzen, in dem man die Farbe einfach schon damit vormultipliziert und man den Glanzlichtparameter dadurch teilt. Bei einen Licht führt man ja im Prinzip folgende Rechnung aus:
PixelFarbe = Color * Diffuse * SceneAmbient + Color * Diffuse * Licht + Color * Specular * LichtReflektion
Du kannst "Color * Diffuse" ausklammern:
PixelFarbe = (Color * Diffuse) * SceneAmbient + (Color * Diffuse) * Licht + (Color * Diffuse) * (Specular / Diffuse) * LichtReflektion

Jetzt gibt es nur noch zwei Pixelweise-Parameter: (Color * Diffuse) und (Specular / Diffuse)
Wenn die Modelldaten unter Berücksichtigung dieser kleinen Änderung erstellt worden sind, fällt nichtmal weiterer Rechenaufwand an.

Die Position könnte man über die Inverse der ViewMatrix(Perspektive+Kamera) zurückrechnen aus den Pixelkoordinaten. Ob das performancemäßig sinnvoll ist, weiß ich aber nicht. Wenn der Shader aber durch den Durchsatz der Textureunit limitiert ist, wäre es vorstellbar.

Zum Packing: Seit längerer Zeit gibt es ja auch Integerberechnungen auf der GPU. Die besten Packraten wirst du erzielst du vermutlich, wenn du es einfach mit Shift und Bitweisen And die Komponenten extrahirst, wie du es auch auf der CPU machen würdest.

Seit GLSL 4.10 gibts ein paar packing Funktionen (pack/unpack).
In GLSL 3.30 kann man die gut emulieren weil es ab da Funktionen zum umwandeln von floats in deren bit-darstellung und andersrum gibt.
Alles drunter habe ich mich selber noch nicht mit beschäftigt.

Ich hab das für mein aktuellen Projekt einmal gemacht für GLSL 3.30+ (siehe Anhang)
Vll hilft dir das ja weiter. Neben den von GLSL 4.10 bereitgestellten Versionen für 2x16 und 4x8 habe ich auch 3x10 hinzugefügt, die ich z.B. für meinen Versuch mit den Normalen benutzt habe.
Die Umwandlungen sind ziemlich straigt forward und ich habe keine Ahnung ob man da noch irgendwas tricksen kann

Wie OpenglerF auch schrieb:
Die Ambient Farbe halte ich auch für zu viel, die würde ich global einstellen.
Allerdings würde ich die Spec Color auch extra speichern, da das einem Artist ein schönes Maß an Freiheit gibt. Muss man halt wissen ob man die Kosten dafür wirklich zahlen will.

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Ich klemm mich mal kurz rein, wenn ich schonmal wach bin
Weniger hätte ich auch gern. Lach nicht, ich bin grad an einer Möhre, die nur 4 Buffer kann, muss das mal so einkürzen dass alle weiteren nicht mehr wichtig sind, nur noch "verschönern"
"shadow" ist der Verdeckungswert aus der Shadowmap (1->hell .. 0->Kernschatten), und der letzte Buffer ist die vormultiplizierte Emissive Map (vgl. Leuchttafeln).

Hatte ich auch mal gedacht, dann aber in die Materialsammlung geguckt und festgestellt dass man fast nichts nur damit darstellen kann... Ambient hast du natürlich Recht, das ist vom globalen Pseudolicht, das kann man rausmultiplizieren. Die anderen brauchen wir aber noch ihn Rohform, um sie im LA-Pass mit den jeweiligen Lichtquelleneigenschaften zu verrechnen. Sonst wäre das so wie du beschreibst einfacher, ja.

Die Positionsberechnung wäre dann (Pseudocode aus'm Gedächtnis):

Oder? Hatten wir mal kurz so drin, stimmte aber irgendwie nicht. Deswegen wieder diese doofe Map...

_________________
Gott sei Dank bin ich Atheist!

Emissive Color ist möglicherweise sinnvoll. Ich glaube, mit minimalen Einsparungen ganz ohne Packing sollten hier 4 Buffer im Moment auch vollkommen reichen.

"Specular"-Farbe ist unnötig. Einfach weil es in der Realität außer vielleicht bei extra speziell hergestellten künstlichen Oberflächen keinen diesen Effekt nicht gibt. "Könnte man irgendwie irgendwann mal brauchen" ist eine schlechte Ausrede. Und wenn der Designer die Werte braucht für gute Ergebnisse, dann stimmt irgendetwas anderes mit dem Renderer nicht. Freiheiten sind gut und schön aber nur da, wo es auch Sinn machen.

Ich wollte außerdem nochmal schnell daraufhinweisen, dass mit Packing sämtliche Texturefilterung zum Supergau wird. Das ist zwar bei solchen Texturen zum Deferred Shading nicht unbedingt notwendig, könnte aber auch manchmal sinnvoll sein.
Ansatt Floats in Integer im Shader umzuwandeln, wäre es doch sinnvoller, gleich eine Integertexture zu erstellen.

Ich bin kein Experte auf dem Gebiet aber specular colors haben durchaus ihren Anwendungsfall, z.B. bei Metallen.
Hab vor ner Weile mal diesen Artikel gelesen über lighting in Ryse. Fand ihn zwar nicht besonders bahnbrechend, aber die benutzen auch spec colors, allem Anschein nach aber auch nur für Metalle und wie im Artikel beschrieben wenige vorgegebene Farbwerte.

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Und man muss ihnen ja eins lassen: das Gameplay ist eher nix, aber Ryse sieht ziemlich toll aus.
Die Idee mit dem was die "Roughness" nennen hatte ich auch schon, so als Verhältnis zwischen Diffuse und Specular. Das könnte sogar passen, ich bin jetzt auf 4 Maps ohne Specular runter und habe noch den Alphakanal der Diffusemap übrig.

_________________
Gott sei Dank bin ich Atheist!

Nein, eigentlich nicht. Metalle sind auch nur ganz normale Objekte die Licht reflektieren.
Das es noch recht viele machen, ist wohl hauptsächlich historisch bedingt. Die Fixed Pipeline hatte augrund der eingeschränkten Möglichkeiten und Hardwaregegebenheiten volle Farben für Materiallien. Wenn man sich physikalisch den Effekt anschaut, dann gibt es dass einfach nicht.

"Roughness" ist eine gute Idee auch ein Schritt zur physikalischen Korrektheit. Ziemlich änlich, was ich vorhin bereits vorgeschlagen habe... "Color, Diffuse zusammenfassen"

Heute mit Shadern ist das alles möglich. Früher hat man sich in der Grafik scheinbar zu wenig an der Realität orientiert. Warum auch normales Alpha und Emission eigentlich Quatsch ist, hat Krishty hier mal schön erklärt: zfx.info\Premultiplied Alpha

Lack kann allerdings so einen Einfluss haben. Da kann die Specular-Color anders sein als die Diffuse-Color. Und das ist garnicht so selten! (nicht matte) Weihnachtskugeln haben diesen Effekt schon. Meist ist es da dann so, dass Specular im gegensatz zu Diffuse nicht Rot ist.

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Ja, es gibt Ausnahmen.
Für Weihnachtkugelrendering wäre eh ein eigener spezieller Shader angebracht, wenn man wirklich gute Ergebnisse erzielen will. Man denke auch an die Reflektionen unten an einer CD. Es gibt halt auch spezielle Materialien die aus dem Muster fallen, die würde ich allerdings auch speziell behandeln und es nicht krankhaft versuchen, alles mit einen allgemeinen Fall abzudecken.

Soweit ich das verstanden habe, ist das aber genau gegen den Sinn von Deferred Shading.

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Nein, Deferred Shading soll sicherstellen, dass (Licht)berechnungen nur einmal pro Fragment ausgeführt werden und nicht mehrmals, wenn die einzelnen Objekte getrennt gerendert werden. (Mehrere Objekte hintereinander können überzeichnet werden, dann wäre an der Stelle die Rechenarbeit umsonst gewesen.)
Alles über einen Kamm scheren, funktioniert eh nicht, beziehungweise würde es stark rinschränken.
Dinge wie transparente Objekte und speziale Shader funktionieren prinzipiell nicht im deferred Pass.