Simulation für Overbright-Blur

[aths]

Vor einiger Zeit hatte ich eine Idee, wie World of Warcraft vermutlich diesen Fullscreen-Glow erstellt. Mit dieser Methode müsste mal generell Overbright-Blur aus LDR-Content erzielen können:

- Man hat das fertige Bild, und macht eine Kopie davon unscharf (am einfachsten via MIP-Mapping und LOD-Biasing)

- Dieses Bild addiert man – nachdem die Farbwerte runterskaliert wurden – auf das Original.

- Um dafür zu sorgen, dass nur bereits helle Flächen überstrahlen, und dunkle Flächen unangetastet bleiben, kann man das unscharfe Bild zudem noch mittel Subtraktion abdunkeln (wobei natürlich Werte kleiner Null geclampt werden.)


Das probierte ich in einem Malprogramm aus, aber wollte mal was haben, um in Echtzeit mit Slidern herumspielen zu können. Da Xmas so nett war, mich mit den nötigen Informationen zu versorgen wie man mit OpenGL-Texturcombinern die gewünschte Formel umsetzt, kann ich das Experiment nun hier vorstellen:

http://www.dudv.de/files/3dcf/OBE.png Download Programm (http://www.dudv.de/files/3dcf/OB_Experiment.exe) Download Highres-Texturen (http://www.dudv.de/files/3dcf/Texturepack.rar)


Das Tool enthält sechs Bilder, eines davon zusätzlich in 512x512, den Rest in 256x256. Das Texturepack enthält die anderen fünf Bilder ebenfalls in 512x512, die man allerdings nur einzeln via "Bild laden" nutzen kann.


Die drei Hauptregler im Fenster oben regeln die Stärke der Überbelichtung, die Stärke des Verwisch-Effektes und die Schwelle, ab welcher Helligkeit überhaupt überbelichtet wird.


http://www.dudv.de/files/3dcf/001.jpg

http://www.dudv.de/files/3dcf/002.jpg

http://www.dudv.de/files/3dcf/003.jpg

[aths]

Es gibt drei Möglichkeiten, die drei Hauptregler zu beeinflussen:

- Die Slider mit der Maus anfassen.

- Das Hex-Code-Feld editieren. Mit diesem Feld kann man die Überblend-Einstellungen auf eine Art rauskopieren, ohne alle drei Werte separat abschreiben zu müssen. Man kann einen anderen Code auch aus der Zwischenablage einfügen oder den Code direkt editieren.

- Sofern man nicht gerade beim Code-Editieren ist (das Edit-Feld kann man mit der Tabulator-Taste verlassen) sind die Zahlentasten von 1-6 so belegt, dass sie die Slider beeinflussen.


Weitere Tastenbelegungen:

Num-Pad /,*: Ändert das allgemeine LOD-Bias. -,+: Ändert dem Zoomfaktor. (Diese Funktionen stehen auch im erweiterten Panel via Slider zur Verfügung, dort kann zusätzlich mit Maus die Bildzentrierung geändert werden.)

Q, W: Dreht das Bild um 0,25° nach links bzw. rechts. E: Setzt den Drehwinkel zurück.

A, S, D: Schaltet den bilinearen Filter, die MIP-Interpolation und die MIP-Nutzung jeweils an/aus. (Diese Funktionen stehen auch im erweiterten Panel via Checkbox zur Verfügung.)

[Gast]

Die Arbeit hättest Du dir sparen können; mit 2-3 Layern in GIMP oder Photoshop geht das viel anschaulicher.

[Mastermind]

Die Arbeit hättest Du dir sparen können; mit 2-3 Layern in GIMP oder Photoshop geht das viel anschaulicher.
Quatsch.

@aths: Schön! Nur noch bitte den HiRes-Link fixen.

[hofmetzger]

[...] und die Schwelle, ab welcher Helligkeit überhaupt überbelichtet wird.[...]
Heißt das, dass eine Linie deren Farbe von schwarz nach weiß wechselt, plötzlich anfängt zu blurren? Vielleicht sollte zusätzlich der Blur-Radius mit steigender Helligkeit wachsen.
EDIT: Leider crasht mein Gimp laufend, ich kann nichtmal zeigen was ich oben meinte
EDIT2: Ok ich nehm alles zurück, ich kann jedenfalls nicht entdecken, was ich vermutete.
http://img329.imageshack.us/img329/2006/blurtestno4.th.jpg (http://imageshack.us)
http://img478.imageshack.us/img478/6833/blurtestblrrdve4.th.jpg (http://imageshack.us)

[ScottManDeath]

Jo, Blooming ist Tone Mapping für Arme ;) Ich hatte das mal für meinen Raytracer als Postprocess implementiert.

Ist nett es mal fix zu sehen. =) Man könnte die Artefakte etwas verringern, wenn man im Shader aus den niedrigen Mip Levels mehrmals sampelt und dabei ein gedrehtes Raster, oder aber kubische Interpolation verwendet.

In der Regel faltet man das Bild mit einem weiten (ca. 10% bis 20% der Bild Breite), radialsymmetrischem sqrt((1-x)^4) Kernel, der in der Mitte 0 ist, so dass man die "eingestrahlte Energie" pro Pixel ermittelt. Bei diesen breiten Kernels dauert das aber pervers lang :( Dannach addiert man ein einen Teil davon auf das Originalbild auf. Man kann auch das Originalbild erst thresholden, um nur helle Bereiche zu blurren.

[aths]

In der Regel faltet man das Bild mit einem weiten (ca. 10% bis 20% der Bild Breite), radialsymmetrischem sqrt((1-x)^4) Kernel, der in der Mitte 0 ist, so dass man die "eingestrahlte Energie" pro Pixel ermittelt. Bei diesen breiten Kernels dauert das aber pervers lang :( Dannach addiert man ein einen Teil davon auf das Originalbild auf. Man kann auch das Originalbild erst thresholden, um nur helle Bereiche zu blurren.Ja, mein Ansatz ist bewusst "Multitexturing-kompatibel" und ganz ohne Shader machbar. Texuren könnte ich notfalls selbst blurren da ich sie ja auch im Hauptspeicher habe und der Blur via LOD-Biasing die typischen Alignment-Probleme eines 2x2-Boxfilters zeigt. Solche Details standen aber nicht im Vordergrund, ich wollte einfach mal sehen was man aus LDR-Material mit Overbright-Blur machen kann.

Immerhin ließen sich so ganz nette Fadein- oder Fadeout-Effekte erzielen.


@aths: Schön! Nur noch bitte den HiRes-Link fixen.Müsste jetzt funktionieren.

[aths]

Heißt das, dass eine Linie deren Farbe von schwarz nach weiß wechselt, plötzlich anfängt zu blurren?Das heißt, dass dunkle Bereiche nicht aufgehellt werden.
Vielleicht sollte zusätzlich der Blur-Radius mit steigender Helligkeit wachsen.Das ist indirekt drin, einfach weil der Blur von hellen Bereichen größere "Durchschlagskraft" hat.




edit: Neue Version mit minimalen Verbesserungen, z. B. dass Bilder mit Ausdehnungen größer als 2048 jetzt zentriert ausgeschnitten werden. Nach wie vor ist die Bildzentrierung (egal bei welchen Ausdehnungen) nicht perfekt, aber das Tool soll ja auch kein allgemeiner Bildbetrachter sein.

edit2: Noch mal ein kleines Update: Die Zentierung arbeitet nun korrekt, und man kann mit den Tasten A, S und D den Filtermodus beeinflussen. Im erweiterten Panel stehen dafür auch Checkboxen zur Verfügung.

edit3: Noch mal ein kleines Update: Man kann jetzt JPEG- und BMP-Bilder ins Hauptfenster reinziehen, um sie zu laden. Außerdem gibt es eine Mini-Ansicht des geladenen Bildes.

edit: Und noch ein Update. Jetzt ist es optional möglich, nur die Helligkeitswerte (Graustufen) zu addieren.

[sth]

http://collective.valve-erc.com/index.php?go=tron2 ;)

Das Verfahren leidet allerdings wirklich stark an der geringen Rechenpräzision. Bei kontrastreichen Szenen kein Problem, aber feine Farbverläufe (z.B. in Skyboxes) werden sehr unschön dadurch. Bei Half-Life 1 (siehe Tutorial) fällt das nur kaum auf, da das Spiel ohnehin nur auf 256 Farben runtergerechnete Texturen verwendet* und daher feine Verläufe von den Designern vermieden wurden.

*(zwar mit einer eigenen Farbpalette pro Textur, aber trotzdem oft mit sichtbarem Dithering)

[Mr. Lolman]

Warum wurde diese Technik nie in Spielen verwendet? Brauchten wir echt erst SM2.0-kompatible HW, bis die Welt reif war, für Bloom?

BTW: aths, könntest du dein so Programm umschreiben, dass es folgendes macht? http://www.forum-3dcenter.de/vbulletin/showthread.php?t=225835

Am Besten wär gleich eine konfigurierbare Batchfunktion, in der man bestimmte Wildcards für Diffuse-, Bump- und Specularmaps setzen kann (zB *_d.jpg für Diffuse)

[HajottV]

Warum wurde diese Technik nie in Spielen verwendet?

Die Technik ist uralt. Das wird so sogar schon auf der PS2 benutzt.

http://www.gamespot.com/pages/profile/index.php?user=raiden_011

Der Artikel zu Shadow of the Colossus ist ohnehin sehr interessant und lesenswert - leider ist die Originalseite futsch, wo der Text zum erstem mal auf Englisch auftauchte.

Gruß

Jörg

[sth]

Warum wurde diese Technik nie in Spielen verwendet?
Weil der Inhalt des Framebuffers zurückgelesen werden muss, was bei vielen alten Karten einfach viel zu langsam war. Mit der Generation der SM1.x-Karten fing es an brauchbar zu werden, aber AGP und Rückkanal ist halt so eine Sache für sich...

Es gibt ein paar Spiele, die die Technik auch auf nicht-SM2.0-Karten einsetzen (z.B. Guild Wars).

[aths]

Warum wurde diese Technik nie in Spielen verwendet? Brauchten wir echt erst SM2.0-kompatible HW, bis die Welt reif war, für Bloom?Ich bin kein Fan von solchen Verfahren. In WoW zum Beispiel nervt es nur noch, weshalb ich es abschalte. Dabei wäre es in WoW ohne zu viel Aufwand auch adaptiv implementierbar. In NFS: MW (auf der PS2) ist es schon ein wenig aufwändiger gemacht.

Man könnte auch ohne HDR-Rendering (mit 64 Bit) ein etwas "echteres" Overbright-Blur hinbekommen, in dem als HDR-Lightmaps einfach hochskalierte 8-Bit-Texturen genutzt werden. Tonemapping wird allerdings schwierig.

BTW: aths, könntest du dein so Programm umschreiben, dass es folgendes macht? http://www.forum-3dcenter.de/vbulletin/showthread.php?t=225835

Am Besten wär gleich eine konfigurierbare Batchfunktion, in der man bestimmte Wildcards für Diffuse-, Bump- und Specularmaps setzen kann (zB *_d.jpg für Diffuse)Da hat bansi doch schon was geschrieben?



http://www.gamespot.com/pages/profile/index.php?user=raiden_011

Der Artikel zu Shadow of the Colossus ist ohnehin sehr interessant und lesenswert - leider ist die Originalseite futsch, wo der Text zum erstem mal auf Englisch auftauchte.Extrem interessant.

[SentinelBorg]

Ich hab jedoch das Gefühl, als würde von Patch zu Patch an dem Overbright-Effekt in WoW rumgeschraubt werden. Zumindest scheint er mir heutzutage nicht mehr so grell und blurig zu sein, wie noch bei Release.

Sentinel

[aths]

Soweit ich das in Erinnerung habe, wurde ein mal bei einem Patch der Blur-Effekt geändert.

[Mr. Lolman]

Da hat bansi doch schon was geschrieben?


Naja, angefangen...