(gelöst) Helligkeit bei ambienter Beleuchtung

[Krishty]

Hi,

Ich setze ambientes Licht ein, das aus allen Richtungen mit derselben Helligkeit strahlt. Damit wird eine Fläche beleuchtet, sagen wir (der Einfachheit halber), eine Lambert-Fläche.

Meine Frage: Ist die Helligkeit der Fläche nun identisch der Helligkeit des ambienten Lichts?

Einerseits wird die Fläche ja aus allen möglichen Richtungen beleuchtet, andererseits spielt bei denen noch das Kosinusgesetz mit rein ... gleicht sich das alles aus?

Mein ambientes Licht erscheint irgendwie zu dunkel und ich suche gerade alle Teile der Pipeline naach dem Fehler ab, darum die merkwürdige Frage.

Gruß, Ky

[Schrompf]

Ich verstehe Dein Problem nicht. Entweder Du rechnest den Winkel zwischen Licht und Flächennormale mit ein (das ist evtl. das, was Du mit "Kosinusgesetz" meinst), oder Du rechnest es eben nicht ein. Außerdem hast Du evtl. die Abschwächung (Attenuation) mit einberechnet. Die beschreibt eigentlich den Zusammenhang zwischen Fläche, Abstand und Helligkeit. Für eine Ambient-Lichtquelle würde ich nicht den Winkel einberechnen, wohl aber die Abschwächung.

[Krishty]

Naja, bei ambientem Licht gibt es weder Attenuation noch einen bestimmten Winkel. Die Frage ist viel mehr:

Wenn ich eine (Lambert-)Fläche aus jeder Raumrichtung gleichmäßig bestrahle, ist die Fläche dann genauso hell wie das Umgebungslicht? Oder dunkler/heller?

Bzw. kann ich den Wert des Umgebungslichtes einfach für die Beleuchtung weiterverwenden?

[Schrompf]

Ich verstehe das Problem immernoch nicht. In der orginalen Physik gibt es kein ambientes Licht. Das ist eine Erfindung der Programmierer, um sich das Leben leichter zu machen. Demzufolge kannst Du beliebige Formeln anwenden, ganz wie Du magst. Daher hätte ich die Attenuation durchaus einberechnet... sonst gibt es sehr hässliche Grenzen, da wo die Reichweite der Lichtquelle zu Ende ist.

Wenn wir jetzt eine Oberfläche annehmen, die vollständig von einem selbststrahlenden, ansonsten komplett absorbierenden Material umgeben ist, dann müsste diese Oberfläche die selbe Helligkeit wie die emittierende Umgebung haben. Denke ich. Ganz theoretisch läuft das auf ein Flächenintegral über die Fläche einer Halbkugel hinaus, integriert wird über die klassische ndotl, also über cos( Winkel zur Normale). Ich habe das Integral nie aufgelöst, aber rein intuitiv würde ich schätzen, dass da 1 rauskommt. Also selbe Helligkeit wie das emittierende Material rundherum.

Aufgrund Deiner bisherigen Formulierungen muss ich aber trotzdem nochmal drauf hinweisen: ich glaube, Du bist auf dem völlig falschen Pferd momentan. Das, was Du da zu erschaffen versuchst, gibt es in der Physik nicht. Demzufolge ist es absolut albern zu fragen, wie das da aussähe. Wenn Du nicht-physikalische Vereinfachungen wie Ambient-Lichtquellen einbaust, gibt es kein Richtig und kein Falsch mehr... nur noch ein "sieht ok aus" oder "sieht blöd aus". Also schieb an den Werten, bis Dir das Ergebnis passt.

[Krishty]

In der orginalen Physik gibt es kein ambientes Licht. Das ist eine Erfindung der Programmierer, um sich das Leben leichter zu machen. Demzufolge kannst Du beliebige Formeln anwenden, ganz wie Du magst. Daher hätte ich die Attenuation durchaus einberechnet... sonst gibt es sehr hässliche Grenzen, da wo die Reichweite der Lichtquelle zu Ende ist.
...
Das, was Du da zu erschaffen versuchst, gibt es in der Physik nicht. Demzufolge ist es absolut albern zu fragen, wie das da aussähe. Wenn Du nicht-physikalische Vereinfachungen wie Ambient-Lichtquellen einbaust, gibt es kein Richtig und kein Falsch mehr... nur noch ein "sieht ok aus" oder "sieht blöd aus". Also schieb an den Werten, bis Dir das Ergebnis passt.

Nun, ich habe aber in meinem Fall tatsächlich eine umgebende Lichtquelle, die über alle Richtungen nahezu konstant strahlt. Natürlich ist das, was ich mache, bloß ein Modell. Dennoch gelten für jedes Modell nach außen Grundsätze wie der Energieerhaltungssatz. Und genau darum geht es hier: Selbst wenn die Beleuchtung nicht allzu präzise ausfällt (gut, dass unsere Wahrnehmung uns da viel vezeiht), sollen die Fehler unter'm Strich Null ergeben, so dass der Rest der Szene so wenig wie möglich von den Macken des Modells getroffen wird. Deshalb kann ich nicht einfach die Lichtstärke mit einem beliebigen Faktor multiplizieren, bis mir das Ergebnis gefällt.

Wenn wir jetzt eine Oberfläche annehmen, die vollständig von einem selbststrahlenden, ansonsten komplett absorbierenden Material umgeben ist, dann müsste diese Oberfläche die selbe Helligkeit wie die emittierende Umgebung haben. Denke ich. Ganz theoretisch läuft das auf ein Flächenintegral über die Fläche einer Halbkugel hinaus, integriert wird über die klassische ndotl, also über cos( Winkel zur Normale). Ich habe das Integral nie aufgelöst, aber rein intuitiv würde ich schätzen, dass da 1 rauskommt. Also selbe Helligkeit wie das emittierende Material rundherum.

Hast mich verstanden, das ist ziemlich genau die Antwort, die ich mir erhofft habe. Danke :)
Ist zwar ohne Auflösung kein Beweis, aber ich bin überzeugt dass ich deiner Intuition da mehr trauen kann als meiner ... Mathe ist nicht meine Stärke, sonst würde ich nicht fragen.

[joeydee]

So abwegig von der Realität ist das gar nicht - in der Produktfotografie wird z.B. ein sog. "light tent" bzw. "soft box" eingesetzt, um eine möglichst gleichmäßige Beleuchtung von allen Seiten zu bekommen:
http://www.vividsparks.com/kaufsospass/ ... _box_g.jpg
In der Rendergrafik wird das ebenso benutzt, sei es als HDRI-Panorama (image based lighting) oder als Lightdome (viele Lichtquellen auf einer gedachten Kugel angeordnet). Wenn man sämtliche Schatten mitberechnet (Selbstabschattung) bekommt man auf diese Art den Ambient Occlusion Pass.
Ohne Schatten hat jede Fläche denselben Lichtwert. In der Realität wie gesagt praktisch nicht zu erreichen.

Zum Helligkeitswert ein kleiner quick'n'dirty-Test für eine Ebene:

Code: Alles auswählen

//Javascript (AS3)
var spots=100000;//Anzahl Lichter

var lit=0;
for(var i=0;i<spots;i++){
	var px=Math.random()*100-50;
	var py=Math.random()*100-50;
	var pz=Math.random()*100-50;
	var d=Math.sqrt(px*px+py*py+pz*pz);
	if(d>0){
		px/=d;
		py/=d;
		pz/=d;
		var dot=pz;//normal=(0,0,1) -> dot=0*px+0*py+1*pz
		if(dot>0)lit+=dot/spots;
		}
	}
trace(lit);//Ausgabe

Scheint sich irgendwo bei 0.257 anzunähern.

[Krishty]

Dass der Wert so niedrig liegt überrascht mich nun schon – die Lichter sind wahrscheinlich nicht richtig gleichmäßig verteilt, aber diese Abweichung dürfte minimal sein … bei mir sieht das ambiente Licht selbst mit 1 noch zu dunkel aus … aber ich bin immernoch bei der Fehlersuche, könnte angefangen bei der Größe des Blickfelds bis hin zum Tonemapping an vielem liegen.

[joeydee]

Naja, so überraschend ist das nicht:
- von sämtlichen Lichtern liegen generell 50% auf der Rückseite einer beliebigen Ebene
- von diesen 50% scheint maximal eine Licht mit voller Helligkeit (jenes senkrecht über der Ebene), alle anderen sind aufgrund des Kosinusgesetzes reduziert.
-> der Wert muss also sehr deutlich unter 50% der gesamten Lichtsumme liegen.

[Krishty]

-> der Wert muss also sehr deutlich unter 50% der gesamten Lichtsumme liegen.

Aber ist die Summe des Umgebungslichts nicht 4×π (Oberfläche der Einheitskugel)?

[joeydee]

Reine Definitionssache: Wenn eine Lichtleistung pro Flächeneinheit gegeben ist, nimmst du natürlich die Kugeloberfläche als Gesamtfläche, um etwas über die Gesamtleuchtkraft zu erfahren. Aber egal ob diese gedachte Kugel nun insgesamt gleichmäßig mit 80.000 Glühbirnen, 50 Lux oder 18 Glühwürmchen strahlt, kommen auf einer beliebigen Ebene in der Mitte der Kugel deutlich weniger als 50% davon an.
Aus Gründen der Einfachheit nehme ich die Gesamtleuchtkraft der Kugel eben als "1" bzw. "100%" an.

[Krishty]

Okaaay, ich habe nämlich nicht mit der Gesamtleuchtkraft der Kugel gerechnet sondern mit der Leuchtkraft in einer Raumrichtung. Die müsste ich dann also mit 4π multiplizieren um die Gesamtleuchtkraft der Umgebung zu berechnen und danach mit rund 0.257 um an die Beleuchtung der Fläche zu kommen.

Für mich ergibt das einen Faktor von rund 3.23, den werde ich gleich mal ausprobieren – als ich frei Schnauze vorgegangen bin, kam ich auf einen Faktor von vier bis acht, bei dem die Beleuchtung glaubwürdig aussah. Klingt also vielversprechend.

Achja, off-topic: Irre ich mich oder hattest du nicht mal ein IOTW über Ambient Occlusion gepostet?

[joeydee]

Ja hab ich. War ähnlich: je Pass ein Licht mit Schatten, ankommende Helligkeitswerte auf jeder Fläche addieren und durch die Anzahl der Passes teilen. Damals hatte ich den passenden Korrekturwert aber auch nicht genau ausgerechnet sondern händisch korrigiert glaube ich. Bei AO möchte man in der Regel ja auch möglichst Weiß(1,1,1) auf den "offenen" Flächen.

[Krishty]

Bei AO möchte man in der Regel ja auch möglichst Weiß(1,1,1) auf den "offenen" Flächen.

Mit HDR ist das nicht mehr nötig :)
Habe die Helligkeit mal gemäß meinem letzten Post umgesetzt und 3.23 sehen tatsächlich viel besser aus als die 1.0 von vorher. Bis zum perfekten Look fehlt zwar immernoch was, das wird aber am Content liegen.
Danke für die Hilfe!

[Schrompf]

Zeig Bilder!!!!11eins :D

[Krishty]

Nagut, bevor du die einself auspackst :D

Also, mein derzeitiges Projekt ist das Rendern von Atmosphäre. Ich nehme einen klassischen Frame entgegen, der komplett frei von Atmosphäre ist (schwarzer Himmel mit Sternen und Sonne als Hintergrund). Dann wühle ich mich für jeden Pixel durch rund eine Million Kubikmeter Luft und berechne, wie diese Luft das von außerhalb der Atmosphäre einfallende Licht reflektiert, streut und absorbiert und was davon den Betrachter erreicht. Das Ergebnis ist dann ein Frame mit simulierter, auf Physik basierender Atmosphäre.

Weil sowas erst bei einer gewissen Bildtiefe zur Geltung kommt (1 bis 200 km), kann ich nur Screenshots mit detailarmem Terrain zeigen, das ich mal schnell Brute-Force runterrender (die Berge am Horizont sind gut 20 km entfernt).

Nun berechnet mein Modell nicht nur die Atmosphäre selbst, sondern kann auch die Beleuchtung durch die Atmosphäre simulieren. Wenn bei mir die Sonne untergeht, färbt sich nicht alles rot weil sich die Sonne verfärbt, sondern weil erkannt wird, dass das Sonnenlicht einen weiteren Weg durch die Atmosphäre zurücklegen muss. So kommt z.B. automatisch zustande, dass bei Sonnenuntergang zuerst Täler, dann Berge und zuletzt die Wolken im Erdschatten versinken. Übrigens habe ich außer dem Erdschatten noch keine Schatten implementiert, also nicht schreien wenn mal eine Fläche zuviel beleuchtet ist.

Hier mal ein typischer Screenshot mit direkt & indirekt beleuchtetem Terrain und Atmosphäre. Wer genau hinschaut, kann den Mond erkennen (Mondphasen usw. simuliere ich selbstverständlich auch)

_zfx_dayw_.png (1.05 MiB) 14931 mal betrachtet

Hier dieselbe Aufnahme ohne Atmosphäre aber weiterhin mit direkter und indirekter Beleuchtung (letztere kommt dann besser zur Geltung, weil sie nicht mehr durch die Atmosphäre überblendet wird. Wäre die Beleuchtung aus, wäre alles schwarz und man sähe nur die Sterne)

_zfx_daywo.png (963 KiB) 14928 mal betrachtet

Am besten sieht man den Effekt von Himmelslicht und Ambient Occlusion, wenn die Sonne untergeht und die Täler schon im Schatten versinken, während der Himmel noch strahlt

_zfx_twilight.png (899.08 KiB) 14930 mal betrachtet

[Aramis]

Die Screenshots sehen richtig super aus. Darf man erfahren was du genau planst? Spiel? Simulator? GPU-Kernschmelze :-) ?

PS: Maximum für Screenshots sollte jetzt auf 2048 KiB sein.

[Krishty]

Thx, das mit der GPU-Kernschmelze könnte tatsächlich hinkommen – aber wenn man schon ein Teraflops hat, warum nicht auch nutzen :D Spezielle Anwendungsfälle schweben mir nicht vor, aber für Flugsimulatoren wäre das ideal. Sonnenaufgänge sehen aus 20km Höhe oder gar aus dem Weltraum einfach phantastisch aus. Im Grunde kann jedes Rendering davon profitieren (Täler und Schluchten können im Nebel versinken, Städte im Smog … und der größte Vorteil ist immernoch: Tageszeit und Wetter variabel in Echtzeit) … aber es steckt noch in einem zu frühen Entwicklungsstadium, um was genaues sagen zu können.

Danke auch für das neue Limit, mich nervt nur, dass die Bildbreite auf nicht ausreichend breiten Monitoren immernoch abgeschnitten wird und man dann nicht einmal einen horizontalen Scrollbalken hat -.- Aber sind ja nur ein paar Pixel.

[CodingCat]

Wow, höchst beeindruckende Bilder. Wenn du da noch schöne volumetrische Wolken reinsetzt, sitzt man schon fast im Flugzeug... ;-)

Das mit den abgeschnittenen Bildern war eine Unstimmigkeit im phpBB prosilver Stylesheet (von denen im Moment alle Styles abgeleitet sind). Sollte jetzt gefixt sein.

[Krishty]

Wow, höchst beeindruckende Bilder. Wenn du da noch schöne volumetrische Wolken reinsetzt, sitzt man schon fast im Flugzeug... ;-)

Experimentiere dieser Tage damit, aus der Vogelperspektive aus 8km Höhe sieht es schon ganz hübsch aus … in der Horizontalen habe ich aber noch zuviele Grafikfehler.

CloudsAlpha6.png (1.22 MiB) 15872 mal betrachtet

Das mit den abgeschnittenen Bildern war eine Unstimmigkeit im phpBB prosilver Stylesheet (von denen im Moment alle Styles abgeleitet sind). Sollte jetzt gefixt sein.

Danke, ging ja fix :) Hatte das schonmal gemeldet, da konnte das aber noch nicht gefixt werden.

[CodingCat]

Wow. Wow! Wie renderst du die? Partikel (alphatransparente Quad-Sammlungen)? Geometry Shaders? Instancing? Raycasting? Volumentexturen (Raytracing)? Imposters? Sonst irgendwas abgefahrenes (Voxel :-P)?

[Lynxeye]

Ich bin echt beeindruckt, von dem was du hier zeigst! :shock:

Einen Flugsimulator mit dieser Grafik könnte ich mir echt gut vorstellen. Hoffentlich findest du irgendwann mal die Zeit uns wieder mit so einem tollen Artikel, wie den über das rendern von Sternen, zu beglücken.

[Krishty]

Wow. Wow! Wie renderst du die? Partikel (alphatransparente Quad-Sammlungen)? Geometry Shaders? Instancing? Raycasting? Volumentexturen (Raytracing)? Imposters? Sonst irgendwas abgefahrenes (Voxel :-P)?

Ich benutze eine Perlin-Noise-Textur, die die Wolken bestimmt. Per Geo-Shader erzeuge ich aus jeder Wolke ein Volumenobjekt. Der Pixel-Shader durchläuft dieses Volumenobjekt und berechnet anhand der erstgenannten Textur, wie hoch die Wahrscheinlichkeit ist, dass der Pixel tatsächlich durch die Wolke verdeckt wird. Dann entscheidet ein von der Position abhängiger Perlin-Noise anhand der Wahrscheinlichkeit, ob an diesem Pixel nun eine Wolke sichtbar ist, und wenn ja, wie stark. War nur ein spontaner Einfall, ist recht langsam und zaubert in Bewegung Artefakte … außerdem beruht das Wolkenmodell auf keiner Physik, ist einfach eine willkürliche Mischung von Sonnen- und Himmelslicht, in ein paar Stunden experimentell hingeklatscht ^^

Mein Hauptaugenmerk liegt momentan auch eher darauf, die Verdeckung mehrerer Wolken hinzubekommen … um eine Wolke zu rendern, muss ich nämlich den Tiefenwert des Pixels hinter der Wolke kennen, aber das ist in einem einzigen Pass unmöglich. Order-Independent-Transparency funktioniert zwar, lässt die Framerate aber kollabieren (, die GPU heißer als während Crysis werden ;) ) und sieht bescheiden aus. Quasi dasselbe Problem wie immer mit Post-Processing und Alphablending. Ich habe ein paar Ideen um das alles zu umgehen, würde das aber gerne komplett „sauber“ lösen … mal schauen, was mir da noch einfällt.

Hoffentlich findest du irgendwann mal die Zeit uns wieder mit so einem tollen Artikel, wie den über das rendern von Sternen, zu beglücken.

Ist unwahrscheinlich – über Atmospheric Scattering gibt es bereits hunderte Paper, da wäre meins überflüssig. Über Sterne habe ich nur geschrieben, weil das so noch nicht da war/ist. Vielleicht mache ich bei den Himmelskörpern weiter, schließlich musste ich mir auch einiges einfallen lassen um den Mond und die Sonne realistisch darzustellen … ist mir aber nicht wegweisend genug und ich müsste dafür erstmal Zeit finden …

[Krishty]

Ich krame jetzt mal das sieben Jahre alte Thema raus, weil die Antwort auf meine Frage in der Zwischenzeit zum Allgemeinwissen geworden ist.

Der Faktor ist nicht rund 0.257, sondern exakt 1/π. Sébastien Lagarde hat eine anschauliche Erklärung für Mathe-fremde Menschen wie mich.

Jeder, der mit Physically-based Lighting zu tun hat (heute also quasi JEDER Grafikprogrammierer) sollte das wissen, weil es direkt aus der BRDF hervorgeht. Nun bin ich auch im Jahr 2012 angekommen. Wie rasant sich die Welt doch weiterentwickelt.