Beleuchtung durch Environment Map

[mOfl]

Hallo liebe Menschen,

ich suche schon seit einer ganzen Weile nach einem guten Paper, Tutorial, einer Demo oder sonst etwas, das sich mit der Beleuchtung einer Szene in Echtzeit durch eine Environment (Cube) Map befasst. Das Internet ist leider übersät mit Artikeln über "Image Based Lighting", "Environment Lighting" uvm., die alle nicht wirklich auf die Beleuchtung, sondern nur auf Reflexion und Refraktion eingehen. Dabei hat man im Alltag selten den Fall, perfekt spiegelnde Oberflächen darstellen zu müssen...

Mir geht es darum, Ambient-, Diffuse- und Specular-Term der Phong-Beleuchtung _ausschließlich_ aus einer Cube Map zu beziehen, in Echtzeit natürlich. Alle meine Spielereien haben nicht so wirklich gefruchtet. Das beste Ergebnis, was ich für den Ambient-Term hinbekommen habe, war über die Oberflächennormale meines Objektes einen Lookup auf die 1x1x1-Mipmap der Cube Map zu machen, um so die mittlere Farbe in dieser Richtung rauszubekommen. Sieht aber auch nicht wirklich gut aus, weil sich von zwei benachbarten Polygonen schlagartig die ambiente Beleuchtung ändert, wenn die Normalen entsprechend zeigen. Und von der diffusen Beleuchtung will ich gar nicht anfangen. Mir fehlt schon allein die Idee, wie ich zuverlässig die hellen Stellen aus dem Himmel filter und daraus etwas wie Lichtpositionen mache. Oder könnte/würde man eine ganze Cube-Map-Seite als Flächenlichtquelle nehmen? Und danach bräuchte man ja auch noch Schattenwurf, eventuell eine Shadow Map pro Cube-Map-Seite? Wie gesagt, ich suche ein Paper oder Tutorial oder sonstige Tipps von Leuten, die sich da schon Gedanken gemacht haben.

Oder hat vielleicht selbst einer von euch schon mal an so was rumgebastelt?

Gruß

mOfl

[Krishty]

Automatische Mip-Maps sind dafür (wie sonst auch) nur sehr begrenzt nützlich … du müsstest den Texturwürfel von Hand entsprechend der Kosinusformel schrittweise weichzeichnen. Indem du das Resultat jedes Mal in einer kleineren Mip-Map speicherst, kannst du dann anhand des Mip-Levels die Glätte der Oberfläche einstellen (größte Mip-Map enthält die unveränderte Textur, also perfekt glatt; kleinste Mip-Map enthält die Umgebungsfarbe, also perfekt matt). Möglicherweise ließe sich die Trigonometrie, die das Ganze so aufwändig macht, mit geschickten Wertetabellen performant implementieren.

Für die Schattierung müsstest du entweder auf Umgebungsverdeckung zurückgreifen oder Spherical Harmonics anlegen, die dir für die entsprechende Stelle und Normale die Verdeckungsinformation ausgeben. U.U. ließe sich das auch mit dem ersten Schritt – der Auswahl eines genügend großen Ausschnitts zur Beleuchtung – kombinieren.

Ich habe sowas zwar selber nicht implementiert, spiele aber schon seit Jahren mit dem Gedanken, das endlich mal zu tun (bin also sehr neugierig auf deine Erfahrungen).

[Schrompf]

Ich glaube auch, dass Du da noch ein paar falsche Vorstellungen von den Begriffen hast. Sowas wie "Ambient" und "Diffuse" gibt es genau genommen nicht, es sind nur Namen für ein paar Grundsorten von reflektierter Lichtenergie. Image Based Lighting wäre ansonsten tatsächlich der richtige Begriff.

Die richtige Beleuchtungsformel besagt ja für ein Stück Oberfläche in der Welt, wieviel Licht aus welchen Richtungen ins Auge des Betrachters reflektiert wird. Daher enthält die Formel natürlich alle Lichteinflüsse aus der Umgebung. Das wäre Deine CubeMap. Wenn Du alle Pixel der CubeMap zusammenrechnen würdest und die CubeMap keine direkten Lichtquellen enthält, wäre das der Ambient-Term in der Phong-Lichtformel. Wenn Du - Krishtys Empfehlung folgend - alle Pixel in der CubeMap mit dem cos()-Term auf alle Nachbarn überträgst und die CubeMap nur die direkten Lichtquellen als helle Flecken enthält, bekommst Du den Diffuse-Term.

Das sind jetzt alles ziemlich vereinfachte Beispiele, für die mich Leute mit Kenntnis von der Materie wahrscheinlich schlagen wollen, aber sie sollen andeuten, dass die CubeMap wirklich alle nötigen Informationen enthält und Image Based Lighting der korrekte Ansatz für Dein Thema ist. Die Phong-Formel ist nur eine Vereinfachung des Ganzen und wird halt gern genommen, weil sie eben gerade so einfach zu berechnen ist und akzeptable Ergebnisse bringt.

[mOfl]

Vielen Dank mal für die Antworten, das bringt mich schon ein Stück weiter, vor allem, dass der Begriff "Image Based Lighting" wirklich das ist, was ich suche. Was ich mit dem Phong- und dem Ambient-Term sagen wollte, ist, dass ich die nichtspiegelnde Beleuchtung aus der Umbegungsmap beziehen will, was ich so bisher noch nicht erklärt gesehen habe. Zum Beispiel der Fragment Shader des HDR-Beispiels aus dem OpenGL SDK 10:

Code: Alles auswählen

// Author: Simon Green
// Email: sdkfeedback@nvidia.com
//
// Copyright (c) NVIDIA Corporation. All rights reserved.

float4 object_fp(v2f In,
                uniform samplerCUBE envMap
                ) : COLOR
{
    float3 I = normalize(In.I);
    float3 N = normalize(In.N);

    float3 R = reflect(I, N);
    float3 T = refract(I, N, 0.95);
    float fresnel = my_fresnel(-I, N, 5.0, 0.99, 0.01);

    float3 Creflect = texCUBE(envMap, R).rgb; // lookup reflection in HDR cube map
    float3 Crefract = texCUBE(envMap, T).rgb; // refraction
    Crefract *= float3(0.05, 0.2, 0.05);

    float3 Cout = lerp(Crefract, Creflect, 0.02);

    return float4(Cout, 0.5);
}

Hier wird ein perfekt spiegelndes (Glas-)Objekt angenommen und nur Brechung und Spiegelung berücksichtigt, was natürlich am einfachsten zu berechnen ist, da man den Reflexionswinkel direkt als Lookup für die Cube Map verwenden kann.

Automatische Mip-Maps sind dafür (wie sonst auch) nur sehr begrenzt nützlich … du müsstest den Texturwürfel von Hand entsprechend der Kosinusformel schrittweise weichzeichnen.

Das verstehe ich nicht genau, von welcher Kosinusformel sprichst du?

Mit Spherical Harmonics hatte ich mich bisher auch noch gar nicht beschäftigt, da werde ich mich auch erst mal einlesen müssen. Ich sehe schon, ich werde mich in vieles erst einmal einlesen müssen, das ist ein ziemlich großes Gebiet, wo ich keine Ahnung habe :)

Aber danke für die Hinweise!

Gruß
mOfl

[Krishty]

Das verstehe ich nicht genau, von welcher Kosinusformel sprichst du?

Vom Lambertschen Kosinusgesetz, dem Skalarprodukt in den ganzen Shadern.

Was du für spekuläre Reflexion suchst, ist das Licht, das exakt aus Richtung des Halbwinkels auf die Oberfläche trifft und von ihr reflektiert wird. Das ist im Texturwürfel exakt der Wert, der in deinem Shader-Beispiel adressiert wird.

Was du für diffuse Reflexion suchst, ist das Licht, das aus der kompletten Hemisphäre auf die Oberfläche trifft und von ihr reflektiert wird. Du musst also theoretisch über die komplette Hemisphäre, jeweils mit dem Kosinus des Winkels zwischen Normale und Einfallsrichtung multipliziert, integrieren. Das ist so ähnlich wie ein niedrigeres Mip-Level zu wählen, nur eben mit dem Kosinus dazwischen.

Ambiente Reflexion gibt es nicht.

Weil das mit dem Kosinus und der Integrierung enorm rechenaufwändig ist, musst du es im Texturwürfel vorberechnen. Du nimmst also das detaillierteste Mip-Level und nutzt es mit dem Halbwinkel für spekuläre Reflexion auf glatten Oberflächen. Das niedrigste Mip-Level, das die kompletten Hemisphären integriert, mit der Flächennormale, nimmst du für diffuse Reflexion auf matten Oberflächen. Und dazwischen nimmst du umso engere Öffnungswinkel und höhere Auflösung für deine Kosinusberechnungen, je glatter die Oberflächenreflexion werden soll.

[mOfl]

Jetzt verstehe ich das, vielen Dank. Das klingt ja erst mal ganz vernünftig. Jetzt muss ich das nur noch gescheit implementieren :)

[eXile]

Oh boy here we go again!

Automatische Mip-Maps sind dafür (wie sonst auch) nur sehr begrenzt nützlich … du müsstest den Texturwürfel von Hand entsprechend der Kosinusformel schrittweise weichzeichnen. Indem du das Resultat jedes Mal in einer kleineren Mip-Map speicherst, kannst du dann anhand des Mip-Levels die Glätte der Oberfläche einstellen (größte Mip-Map enthält die unveränderte Textur, also perfekt glatt; kleinste Mip-Map enthält die Umgebungsfarbe, also perfekt matt). Möglicherweise ließe sich die Trigonometrie, die das Ganze so aufwändig macht, mit geschickten Wertetabellen performant implementieren.

Klingt plausibel. Siehe auch hier.

Für die Schattierung müsstest du entweder auf Umgebungsverdeckung zurückgreifen oder Spherical Harmonics anlegen, die dir für die entsprechende Stelle und Normale die Verdeckungsinformation ausgeben.

Das ist korrekt, ist aber natürlich abhängig davon, wie viele Freiheiten du hast: Wenn die Geometrie dynamisch ist, kann man in der Regel sowohl Ambient Occlusion wie auch PRT ab Schattierung (d.h. PRT mit Schattierung oder PRT mit Schattierung und Interreflexionen) in die Tonne treten; es sei denn, man bastelt sich noch ein paar Tricks zusammen (z.B. Schattenvolumen um die Objekte), welche aber nach meinem letzten Kenntnisstand alle nicht mehr echtzeitfähig waren. Aber das war hier ja eigentlich schon allen klar. ;)

U.U. ließe sich das auch mit dem ersten Schritt – der Auswahl eines genügend großen Ausschnitts zur Beleuchtung – kombinieren.

Nach Renderinggleichung braucht man für einen beliebigen Punkt und für eine beliebige BRDF immer die volle Hemisphäre. Wenn Subsurface-Scattering hinzukommt, braucht man die komplette Sphäre. Einschränkungen bzgl. des Bereichs der eingehenden Beleuchtung können nur bei Beachtung der gerade vorliegenden BRDF vorgenommen werden: Im trivialsten Fall will man eine perfekt spekulare Relexion. In diesem Fall reicht es dann logischerweise aus, einen einzigen Punkt der Cubemap (nämlich in Reflexionsrichtung!) zu sampeln. In diesem Fall ist aber die BRDF (ein einziger Dirac-Stoß in Reflexionsrichtung) aber auch sehr, sehr speziell. Wenn du sagst, das geht auch mit einer Phong-„BRDF“ (Anmerkung: Sie ist keine BRDF, da nicht energieerhaltend), hast du vollkommen recht: Der Träger des Kosinus-Terms (bis zu den Nullstellen – also bis dahin, wo der \($\max(\cdot, 0)$\)-Term keine Änderung verursacht) ist beschränkt. Damit reicht es aus, aus einem gewissen Teilgebiet der Hemisphäre zu samplen.

Ich glaube auch, dass Du da noch ein paar falsche Vorstellungen von den Begriffen hast. Sowas wie "Ambient" und "Diffuse" gibt es genau genommen nicht, es sind nur Namen für ein paar Grundsorten von reflektierter Lichtenergie. Image Based Lighting wäre ansonsten tatsächlich der richtige Begriff.

Danke, dass du es sagst. Noch einmal: Ambient-, Diffus- und Spekularterm sind nur vereinfachende Approximationen von bestimmten Beleuchtungsmodellen/BRDFs. Manche Beleuchtungsmodelle kennen diese Terme gar nicht.

Die richtige Beleuchtungsformel besagt ja für ein Stück Oberfläche in der Welt, wieviel Licht aus welchen Richtungen ins Auge des Betrachters reflektiert wird. Daher enthält die Formel natürlich alle Lichteinflüsse aus der Umgebung. Das wäre Deine CubeMap.

Und dabei wird auch direkt die Approximation klar: Unendlich weit entferntes Licht. Man kann nur mühsam noch zusätzliche lokale Lichtquellen in die Cubemap „reinbaken“. Mit SH geht das (nennt sich dann analytische Lightquellen).

Wenn Du alle Pixel der CubeMap zusammenrechnen würdest und die CubeMap keine direkten Lichtquellen enthält, wäre das der Ambient-Term in der Phong-Lichtformel.

Nein. Bei jedweder physikalisch korrekter Betrachtungsweise ist der Ambient-Term 0 (man hat höchstens noch einen emissiven Term). Der Ambient-Term, den man normalerweise als Approxmation einsetzt, ist eine Approximation von was? Genau: Der Differenz zwischen dem globalen und dem lokalem Beleuchtungsmodell. Hier nehmen wir aber nur ein Objekt unter unendlich weit entfernter Beleuchtung an. Da gibt es keine Differenz zwischen lokalem und globalem Beleuchtungsmodell (wenn man PRT Schattierung oder Interreflexionen außen vorlässt – das wäre hier die globale Beleuchtung). Alle Farbwerte für den Ambient-Term zusammenrechnen ergibt auch so leider nicht viel Sinn: Denn du hast die Farbwerte ja bereits für das, was du den diffusen Term nennst, verwendet; die würdest du dann doppelt addieren. (Soll ich vielleicht einfach Ambient → Diffus und Diffus → Spekular als Ersetzung vornehmen? ;) Dann stimmt's nämlich. :))

Wenn Du - Krishtys Empfehlung folgend - alle Pixel in der CubeMap mit dem cos()-Term auf alle Nachbarn überträgst und die CubeMap nur die direkten Lichtquellen als helle Flecken enthält, bekommst Du den Diffuse-Term.

Ich dachte jetzt an den Spekularterm. Egal. ;)

Das sind jetzt alles ziemlich vereinfachte Beispiele, für die mich Leute mit Kenntnis von der Materie wahrscheinlich schlagen wollen, aber sie sollen andeuten, dass die CubeMap wirklich alle nötigen Informationen enthält und Image Based Lighting der korrekte Ansatz für Dein Thema ist. Die Phong-Formel ist nur eine Vereinfachung des Ganzen und wird halt gern genommen, weil sie eben gerade so einfach zu berechnen ist und akzeptable Ergebnisse bringt.

Sekundiert.

Wenn man die Approximation durch eine reine Cubemap in Kauf nimmt, ist das, was alledem noch am nächsten kommt, ist das hier. Das ist natürlich noch zu rechenintensiv.

Das Problem ist doch eher, wie man das alles effizient hinkriegt. Soll heißen: Am Ende darf man nur aus einer 2D-Textur (sei das jetzt eine Cubemap oder parabolische Spheremap oder was auch immer) samplen; diese hat man aber vorberechnet. Um's mal platt zu sagen: Wir haben mit der Cubemap die eingehende Beleuchtung. Das Integral mit BDRF und mit Kosinus-Term verwuschtet das zu einer ausgehenden Beleuchtung. Diese ausgehende Beleuchtung wollen wir nun wiederum in einer Textur speichern! Das Problem ist jetzt aber, dass wenn wir das in einer 2D-Textur speichern wollen, die resultierende reflektierte Beleuchtung maximal zweiparametrisch sein darf!! Dies ist nur für bestimmte BRDFs erfüllt! (Die Renderinggleichung hat ja z.B. noch die Betrachtungsrichtung als Parameter). Im allgemeinen ist das nur mit einer 5D-Textur möglich.

So weit ich das sehe, ist die zweiparametrische Speicherung insbesondere mit der Phong-BRDF möglich – in einer bestimmten Formulierung aber (ich habe nun schon so viele Beleuchtungsmodelle gesehen, die meinen „Phong“ zu sein; es ist schon nicht mehr feierlich). Erstmal das Phong-Modell in Wikipedia-Notation genommen, und dann auf die eigene Notation umgestellt:
\($$\begin{align}\displaystyle k_s \cdot \frac{(\mathbf R \cdot \mathbf V)^m}{\mathbf L \cdot \mathbf N} &= \displaystyle k_s \cdot \frac{(r_{\mathbf n}(\omega_i)^\ast \mathbf v)^m}{\omega_i\!\,^\ast \mathbf n} \\
&= \displaystyle k_s \cdot \frac{(\omega_i\!\,^\ast r_{\mathbf n}(\mathbf v))^m}{\omega_i\!\,^\ast \mathbf n} \end{align}$$\)Bei mir ist \(${}^*$\) (wie auch in allen meinen anderen Posts) das Standard-Skalarprodukt. Das \($\mathbf L$\) wurde durch \($ω_i$\) ersetzt (Standardname in der Renderinggleichung). Das einzig Verbleibende ist das \($r_{\mathbf n}(ω_i)$\): Das ist der am Vektor \($\mathbf n$\) gespiegelte Vektor \($ω_i$\), d.h. einfach die reflektierte Lichtrichtung a.k.a. die ausgehende Lichtrichtung (denn wir spiegeln die eingehende Lichtrichtung am Normalenvektor). Das zweite Gleichheitszeichen gilt, weil das Skalarprodukt bilinear ist, also gilt:
\($$\begin{align}r_{\mathbf n}(\mathbf x_1)\!\,^\ast \mathbf x_2 &= (2\cdot \mathbf n^\ast \mathbf x_1 \cdot \mathbf n - \mathbf x_1)^\ast \mathbf x_2 \\
&= 2 \cdot (\mathbf n^\ast \mathbf x_1 \cdot \mathbf n)^\ast \mathbf x_2 - \mathbf x_1\,\!^\ast \mathbf x_2 \\
&= 2 \cdot (\mathbf n^\ast \mathbf x_2 \cdot \mathbf n)^\ast \mathbf x_1 - \mathbf x_2\,\!^\ast \mathbf x_1 \\
&= \mathbf x_1\!\,^\ast r_{\mathbf n}(\mathbf x_2)
\end{align}$$\)Was man jetzt machen kann, ist folgendes: \($$\begin{align}\underbrace{L_r(\mathbf x, \omega_r)}_{\small \text{Ausgehende Beleuchtung}} &= L_r(\mathbf x, \mathbf v, \mathbf n), \text{ da } \omega_r = \mathbf v \\
&= \smash{\int_\Omega \underbrace{k_s \cdot \frac{(\omega_i\!\,^\ast r_{\mathbf n}(\mathbf v))^m}{\omega_i\!\,^\ast \mathbf n}}_{\small \text{Phong-„BRDF“}} \underbrace{\vphantom{\frac{(r(n)^\ast \omega_i)^m}{n^\ast \omega_i}}L_i(\mathbf x, \omega_i)}_{\small \text{Eingehende Beleuchtung}} \hspace{-5 pt} \cos(\vartheta_i) \, \underbrace{\mathrm d\omega_i}_{\small \text{Raumwinkel}}} \\[20 pt]
&= \int_\Omega k_s \cdot (\omega_i\!\,^\ast r_{\mathbf n}(\mathbf v))^m \, L_i(\mathbf x, \omega_i) \, \mathrm d\omega_i
\end{align}$$\)Das ist die Renderinggleichung für diese Phong-„BDRF“. Welt-Position \($\mathbf x$\). Betrachtungsrichtung a.k.a. ausgehende Lichtrichtung \($ω_r = \mathbf v$\). Normalenvektor \($\mathbf n$\) der Geometrie bei \($\mathbf x$\). Integration über die komplette Hemisphäre \($\Omega$\). Die Umformung, die ich da gemacht habe, ist einfach die beiden Standardskalarprodukte (der Nenner vom Bruch und den Kosinusterm) herauszukürzen. Das \($ω_i$\) ist der Raumwinkel der eingehenden Lichtrichtung. Kann man sich am einfachsten (wenn auch mathematisch nicht ganz korrekt) als ein Vektor in eine Richtung \($(\vartheta_i, \varphi_i)$\) in Polarkoordinaten vorstellen.

Lasst mich das ganze nun mal kurz umschreiben:
\($$\begin{align} L_r(\mathbf x, r_{\mathbf n}(\mathbf v)) &= \displaystyle \int_\Omega k_s \cdot (\omega_i\!\,^\ast r_{\mathbf n}(\mathbf v))^m \, L_i(\mathbf x, \omega_i) \, \mathrm d\omega_i
\end{align}$$\)Nehmen wir jetzt auch noch unsere Position \($\mathbf x$\) für alle Vertizes im Zentrum des Objektes an (wieder eine Approximation!) kriegen wir:
\($$\begin{align} L_r(r_{\mathbf n}(\mathbf v)) &= \displaystyle k_s \cdot \int_\Omega (\omega_i\!\,^\ast r_{\mathbf n}(\mathbf v))^m \, L_i(\mathbf x, \omega_i) \, \mathrm d\omega_i
\end{align}$$\)Wenn wir jetzt linke Seite betrachten, sehen wir ganz was tolles: Das Teil hängt nur noch von \($r_{\mathbf n}(\mathbf v)$\) ab! Warum ist das toll? Weil der reflektierte Betrachtungsvektor zweidimensional ist (eben nur die Reflexion vom einem zweidimensionalem Vektor, der zum Augpunkt zeigt)! Damit hat man für diesen Spezialfall einer Phong-„BRDF“ eine zweiparametrische Parametrisierung des reflektierten Lichtes gefunden. Also kann man die Cubemap vorverarbeiten und wieder in einer 2D-Textur abspeichern. Und das ist es, was wir de-facto für eine Phong-BRDF mit spekularem Koeffizienten \($m$\) vorberechnen müssen.

So, das war der spekulare Anteil von der Phong-BRDF. Nun noch schnell der diffuse Anteil, der ist nun aber trivial:\($$\begin{align}L_r(\mathbf n) &= \displaystyle \int_\Omega k_d \cdot L_i(\mathbf x, \omega_i) \cos(\vartheta_i) \, \mathrm d\omega_i \\
&= \displaystyle k_d \cdot \int_\Omega L_i(\mathbf x, \omega_i) \cdot \omega_i\,\!^\ast\mathbf n \, \mathrm d\omega_i \end{align}$$\)Damit hat man einen konstanten Wert eine 2D-Textur (parametrisiert mittels des Normalenvektors) für den Diffus-Term und eine 2D-Textur für den spekularen Lookup (eine 2D-Textur pro Spekular-Exponent \($m$\), parametrisiert mittels des reflektierten Betrachtungsrichtungsvektors). Ich kann das auch alles noch weiter erklären; einfach an den entsprechenden Stellen nachfragen. ;)

Was du für diffuse Reflexion suchst, ist das Licht, das aus der kompletten Hemisphäre auf die Oberfläche trifft und von ihr reflektiert wird. Du musst also theoretisch über die komplette Hemisphäre, jeweils mit dem Kosinus des Winkels zwischen Normale und Einfallsrichtung multipliziert, integrieren. Das ist so ähnlich wie ein niedrigeres Mip-Level zu wählen, nur eben mit dem Kosinus dazwischen.

Sekundiert, siehe nun oben. ;)

Ambiente Reflexion gibt es nicht.

Sekundiert.

(Wie man das genau für eine BRDF mit Halfway-Vektor, d.h. Cook-Torrance oder Ashikhmin oder Blinn-Phong, macht, weiß ich noch nicht. So sollte es zumindest für Phong und das LaFortune-Modell klappen.)

(Ohne angeberisch klingen zu wollen: Ich fühle mich in Sachen globaler Beleuchtungsrechnung, Monte-Carlo-Integration und Photonmapping eigentlich relativ fit. Solltet ihr mal einem dieser Themen begegnen, und euch denken „oh, hier hat man ja nur Ahnung von Echtzeitrendering“ – nope; einfach fragen. :3)

[mOfl]

Herzlichen Dank für diese wunderbare formale Einführung in die Thematik! Ist schon eine Weile her, dass ich mich mit der Auswertung der Rendering-Gleichung beschäftigt habe, in letzter Zeit war Beleuchtung einfach Code... ;)

Wenn ich ein bisschen weitergekommen bin mit Verständnis, Experimentieren und Implementierung - oder wenn ich nicht mehr weiter weiß -, werde ich mich nochmal melden. :)

[TGGC]

Es gibt ein kostenloses Tool (glaub von ATI oder nVidia), welches dir deine kleine Cubemap berechnet. 1x1 ist etwas uebertrieben, ich wuerde mindestens 6x2x2 nehmen.

[mOfl]

Danke für den Hinweis, ich spiele schon damit rum. Das Tool heißt CubeMapGen und wurde von ATI entwickelt, ist mittlerweile aber Open Source. Es wurde auch eine leicht modifizierte Version davon veröffentlicht, die genau das macht, was ich will, nämlich die Irradiance Map mithilfe des Cosinus berechnen. Runterzuladen ist das ganze hier: http://code.google.com/p/cubemapgen/dow ... en-1_5.zip. Auch für andere Cube-Map-Zwecke ist das Tool wirklich hilfreich.

[eXile]

Runterzuladen ist das ganze hier: http://code.google.com/p/cubemapgen/dow ... en-1_5.zip. Auch für andere Cube-Map-Zwecke ist das Tool wirklich hilfreich.

Vielen Dank für den Link! Ich kannte zwar schon das Tool, wusste aber noch nicht, dass der Code veröffentlicht wurde.

Aber irgendwie ist das doch Mist: Ich habe die Powerlines-Cubemap genommen, und die mal durchgejagt. Das ist das Ergebnis:



Banding. Ja, Banding. Egal in welchem Format (8-bit RGBA, 8-bit RGB, 16-bit RGBA, float16 RGBA, float32 RGBA). Liegt also wohl nicht an deren Berechnung, sondern einfach nur daran, dass das am Ende in 8 Bit auf dem Monitor anzeigt wird / werden soll (die benachbarten Bänder unterschieden sich um genau 1 in genau einer Komponente). Kann irgendjemand Ratschläge liefern? Only Dithering for the win?

[Krishty]

Danke, dass du die Zeit und Professionalität investiert hast, die ich nicht habe :)

Also, das Banding ist übel … und natürlich darf man nicht die Cube Map dithern, weil dann das finale Objekt dann fleckig würde, sobald es größer als 256×256 Pixel angezeigt würde.

In 10/12/10 Bits (oder noch mehr) speichern ist imo die einzige Lösung, die man nicht im Nachhinein verfluchen wird. Wenn man HDR-Beleuchtung will, ist das aber sowieso alternativlos, oder? Ich bin mir sowieso sicher, dass der Kontrast doppelt so hoch wäre, wenn das Ausgangsbild in höherem Kontrastumfang vorläge – angesichts der ganzen Laternen, Fenster, etc, die nur zu hellen Flecken verschmiert sind … (All of the lights!).

Hier wird übrigens noch ein Problem deutlich: Bloß CGI als Ausgangsmaterial nehmen … sonst wird bei glänzenden Oberflächen jedes Highlight von dem Glare der Fotokamera geplättet.

Edit: Die fehlende bi- und trilineare Interpolation über Würfelseiten hinweg, die im ATI-Artikel erwähnt wird – bittebitte sag mir einer, dass das nur früher so war! :shock:

[TGGC]

Das Banding sieht man am Ende sowieso nicht, wenn man nicht gerade riesige Kugel in ideal-diffusem weiss anzeigt, weil einfach noch genuegend andere Werte dabei zusammengerechnet werden.

[eXile]

Hab' mal das HDRToneMappingCS11-Sample genommen und den MipLODBias der Skybox auf 5 gesetzt. Bilder:




Das Format der Lightprobe ist übrigens A16B16G16R16F. Und ich sehe immer noch Banding. So langsam verliere ich den Glauben an die Computergraphik. Vor allen Dingen weil ich gerade gemerkt habe, dass die Farben (43, 42, 30) und (43, 41, 30) mit bloßem Auge unterscheidbar sind:



Dass man mehr als 8 Bit braucht, wenn man den Farbraum beim Tonemapping verzerrt, ist mir klar. Aber dass das auch so de-facto scheiße ist, war mir unbekannt. Und das nennt sich truecolor? Dass ich nicht lache!

[Zudomon]

Dass man mehr als 8 Bit braucht, wenn man den Farbraum beim Tonemapping verzerrt, ist mir klar. Aber dass das auch so de-facto scheiße ist, war mir unbekannt. Und das nennt sich truecolor? Dass ich nicht lache!

Vielleicht liegt es ja an deinem Monitor... also ich musste schon im Zeichenprogramm schauen, wo da die Grenze in deinem Bild verläuft... jetzt wo ich es weiß, muss ich aber mehr als genau hinschauen, um da einen Unterschied zu erkennen...
Und in der Cubemap sehe ich keine Bandings... nur in der ersten Cubemap da sieht man leichte Filterartefakte an den Würfelkanten.

[eXile]

Magentafarben markiert sind die von Dir angesprochenen Sampling-Artefakte (liegt bestimmt an deren dreckigem Vertexshader). Im cyanfarbenen Rechteck sehe ich klare Banding-Artefakte. Kann hier am Monitor liegen. (Welche, nur so am Rande, ja trotzdem zur Zielgruppe gehören.)

[Zudomon]

Also in dem Cyanbereich sehe ich keine Bandings, sieht sehr einfarbig aus. Aber ich kenne das von anderen TFT's die da dann wirklich so Bandings haben, weil deren Farbdarstellung eben nicht wirklich True-Color ist.
Im Magentabereich, die Artefakte meinte ich vorher. Wäre es keine Cubemap sondern eine normale Textur, dann könnten diesen Artefakte dadurch zustande kommen, dass man Wrap statt Clamp benutzt. Soweit ich mich erinnere, hab ich noch nicht mit den Adressierungsarten rumprobiert, in Bezug auf Cubemaps, aber wundern würde es mich nicht, wenn man solche Artefakte damit beseitigt bekäme.

[TGGC]

Abgesehen davon, das es sinnlos ist, sich nur die Low-Res Cubemaps 100x vergroessert anzuschauen (logisch das er da nicht noch 100 Zwischenwerte erfinden kann...), wuerde es vielleicht auch helfen nicht ein schlecht kalibriertes 6-Bit TFT zu benutzen. ;-)

[eXile]

Abgesehen davon, das es sinnlos ist, sich nur die Low-Res Cubemaps 100x vergroessert anzuschauen

Darum ging es gerade: Wir untersuchen das Mipmapping an den Cubemap-Kanten.

(logisch das er da nicht noch 100 Zwischenwerte erfinden kann...)

Er kann schon, das wird aber am Ende auf die Farbtiefe des Framebuffers runtergerechnet. Aber das hat überhaupt gar nichts mit der Texturauflösung zu tun.

wuerde es vielleicht auch helfen nicht ein schlecht kalibriertes 6-Bit TFT zu benutzen. ;-)

6-Bit TFT ja, schlecht kalibriert eher nicht ;) Ich werde mir die Bilder in diesem Thread bei Gelegenheit mal auf einem Eizo-Monitor reinziehen.

[Krishty]

Ich sehe das Banding auch deutlich; und obwohl nur mittlere Preisklasse, ist mein TFT kalibriert. Abgesehen davon bringt das auch nichts, sich das auf High-End-Bildschirmen anzugucken – wir (ich spreche mal für uns alle) schreiben unsere Programme schließlich für den kleinen Mann auf der Straße und nicht für den monokeltragenden Industriemagnaten vor seinem 10k-Dollar-Bildschirm.

Noise im Post Processing (also nicht nur Dithering, sondern zwei- bis vierfach überhöht) ist imo sowieso die Lösung für alle Probleme in dieser Hinsicht – wenn unter 1920×1080 Pixeln ein einzelner für ein 60tel einer Sekunde mit 1 % mehr Helligkeit aufleuchtet, dann erkennt das kein Mensch, den nun weicheren Farbübergang sieht hingegen jeder (auch, wenn er ihn hoffentlich nicht bemerkt, denn dafür ist das ja da – dass man nicht merkt, dass man auf ein Ausgagegerät begrenzter Präzision guckt). Aber was weiß ich schon.

Und die Filterung der Texturwürfel macht mich depressiv.