OGL - wie Textur downsamplen (für Tonemapper)

[Top-OR]

Moin Spezialisten,

ich habe mal eine konzeptionelle Frage auf eher niedrigem Niveau für einige hier. Nicht lachen:

Wie gehabt, bezieht sich mein Problem auf OpenGL – eventuelle spezielle DX-Lösungen tun es also nicht.

Ich tu mich gerade damit schwer mit dem Downsampling einer Textur. Im Kontext geht es darum, dass ich für nen Tonemapper ja Infos über die „aktuelle“ Helligkeit des Bildes/der Szene brauche.

Die Idee ist dann ja, das aktuelle Bild, welches ja in Form einer Textur vorliegt (Deferred Rendering), downzusamplen, bis es die Größe 1x1 hat. Dann kann ich im späteren Rendershader diesen Wert dieser Textur einfach mittig samplen, wenn ich den Wert für die „aktuelle“ Helligkeit brauche.

Die Frage ist: Wie bekomme ich die Textur mit meiner Scene möglichst schnell klein genug (auf 1x1)?

Ich könnte ja automatische Mipmaps generieren lassen mittels glGenerateMipmap. Da dies aber LAHM ist und ich ja nicht alle Mipmaps brauche, sondern „NUR“ die 1x1-Stufe, finde ich diese Idee doof. Weiterhin solls wohl auch nicht der besonders schnelle Weg sein, es geht wohl auch nur bei power-of-two-Texturen und ist nicht von besonders hoher Qualität.

Dann gibt’s noch die Idee, das aktuelle Bild mit nem selbstgeschriebenen Filter-Shader immer um die Hälfte zu verkleinern (1024x1024->512x512->256x256->…->1x1). Da habe ich dann aber eben nen Sack voll Verkleinerungs-Passes, ganz davon abgesehen brauch ich ja auch für jede Größe ein passendes FBO inkl. Textur(en).

Ist das der „richtige“ Weg oder gibt’s noch nen „richtigeren“ Weg? Oder gibts nen ganz anderen Weg, diese Werte für den Tonemapper zu bekommen?

Ich bedanke mich im Voraus für ein wenig Licht (<-- hahah, Tonemapping) in meinem Dunkel!

Beste Grüße,
Jens

[Krishty]

Stehen denn GPGPU-Möglichkeiten – also freie Thread-Ordnung, Gruppenspeicher und direkter Texturzugriff – zur Verfügung? Damit kriegt man das enorm elegant geregelt.

Ansonsten halt in Tile-Größe runterrechnen, also jeweils 8×8-Pixel-Blöcke, vielleicht auch 64×64, falls der Overhead noch zu groß ist und genug Register zur Verfügung stehen.

Übrigens kann ich mir gut vorstellen, dass du auch an der Unter- und Obergrenze interessiert bist – also an den beiden Helligkeitswerten, über/unter denen 95 % der Pixel liegen. Der Mittelwert allein bringt nämlich kaum was (und die absoluten Minima und Maxima auch nicht, weil sie je nur von einzelnen Pixeln erreicht werden). Und denk immer daran, im linearen Farbraum zu rechnen, falls du irgendwelche Kompressionsmethoden (Shared Exponent) anwendest.

Auch adaptiert das Auge in 1 °-Ausschnitten, d.h. Runterrechnen auf eine 90×50-Textur (ein Texel für jedes Quadratgrad Blickwinkel; mit Blur, damit nichts flimmert) und die Nutzung der entsprechenden Texel statt globaler Werte könnte bessere Ergebnisse bringen. Habe das aber noch nie gemacht.

Gruß, Ky

[Top-OR]

Hi Ky,
danke für die Hinweise. Ich wollt mit deinen Post mir zuerst ausdrucken und übers Bett hängen: Das ist wieder son Ding, was ich zuerst 4x (Edit: 8x) lesen musste, um überhaupt zu wissen, wovon du sprichst.

Stehen denn GPGPU-Möglichkeiten – also freie Thread-Ordnung, Gruppenspeicher und direkter Texturzugriff – zur Verfügung? Damit kriegt man das enorm elegant geregelt.

GPGPU-Möglichkeiten? In welchem Sinne? Ich würde eher mal ausm Stand sagen: wat? NE! (edit: bzw. Jein). NE von der unterstützten Hardware (edit:~ SM 3.0, also Jein), NE vom aktuellen Stand des Softwareframeworks (edit: Zugriff nur über GLSL) und NE vom Erfahrungsstand des Softwareentwicklers. Dieses Thema schiebe ich seit Monaten vor mir her unter der Überschrift: "Dinge, mit denen ich mich mal befassen müsste!" BTW: Hast vielleicht nen guten Einsprungspunkt/ein Tut zu diesem Thema? (Stichwort OpenCL oder bin ich da nun ganz falsch?)

Ansonsten halt in Tile-Größe runterrechnen, also jeweils 8×8-Pixel-Blöcke, vielleicht auch 64×64, falls der Overhead noch zu groß ist und genug Register zur Verfügung stehen.

Ich nehme an, du beziehst dich auf die Stück-für-Stück-downsample-Masche, die ich oben skizziert habe. So wirds dann wohl kommen ...

Übrigens kann ich mir gut vorstellen, dass du auch an der Unter- und Obergrenze interessiert bist – also an den beiden Helligkeitswerten, über/unter denen 95 % der Pixel liegen. Der Mittelwert allein bringt nämlich kaum was (und die absoluten Minima und Maxima auch nicht, weil sie je nur von einzelnen Pixeln erreicht werden). Und denk immer daran, im linearen Farbraum zu rechnen, falls du irgendwelche Kompressionsmethoden (Shared Exponent) anwendest.

Yo, gut „hellgesehen“. ;-) Wird wohl so kommen, dass ich das noch brauche (wenn ich mit verschiedenen Mappern experimentiere). Aber das wird dann Schritt zwei. Momentan muss ich erstmal die Szene "klein kriegen"...

Auch adaptiert das Auge in 1 °-Ausschnitten, d.h. Runterrechnen auf eine 90×50-Textur (ein Texel für jedes Quadratgrad Blickwinkel; mit Blur, damit nichts flimmert) und die Nutzung der entsprechenden Texel statt globaler Werte könnte bessere Ergebnisse bringen. Habe das aber noch nie gemacht.

Whohoooo, das ist Oberklasse: Ein ehrliches Danke für diesen Tipp, wobei ich mir jedoch noch nicht sicher bin, ob ich diese Liga erreiche. Aber gut, das zu wissen, BEVOR man anfängt.


Besten Danke soweit mal.
Wer weitere Vorschläge oder Anmerkungen hat: Her damit!

Beste Grüße

[Krishty]

BTW: Hast vielleicht nen guten Einsprungspunkt/ein Tut zu diesem Thema? (Stichwort OpenCL oder bin ich da nun ganz falsch?)

Uuuuh, leider nicht. Habe bisher nur über Direct3D GPGPU betrieben, und das war in jeder Hinsicht eine Qual …

Ich nehme an, du beziehst dich auf die Stück-für-Stück-downsample-Masche, die ich oben skizziert habe. So wirds dann wohl kommen ...

Genau. Nur halt die Gesamtzahl der Passes reduzieren, indem mehr als 2×2 Pixel runtergerechnet werden.

Whohoooo, das ist Oberklasse: Ein ehrliches Danke für diesen Tipp, wobei ich mir jedoch noch nicht sicher bin, ob ich diese Liga erreiche. Aber gut, das zu wissen, BEVOR man anfängt.

Nimm das lieber zurück — mir fällt nämlich gerade ein, dass man die Texel noch untereinander verschränken müsste damit nicht jedes Grad² wie ein komplett eigenständiges Auge berechnet wird … ist also doch nicht so einfach …

[Top-OR]

Ich nehme an, du beziehst dich auf die Stück-für-Stück-downsample-Masche, die ich oben skizziert habe. So wirds dann wohl kommen ...

Genau. Nur halt die Gesamtzahl der Passes reduzieren, indem mehr als 2×2 Pixel runtergerechnet werden.

Ahh, I've got it now:
Mehr Lookups im Sampling-Shader, dafür weniger Passes. Mal sehen, was sich da am Besten macht. bzw. was der beste Tradeoff ist. Ich hatte den Gedanken zwar auch mal kurz, mehr als 2x2 zu machen, aber ich hab meist (bzw. "nur") von Skalierungen mit 2x2 gelesen und war daher versunichert, obs überhaupt sinnvoll wäre, davon abzuweichen.