Wir ihr alle wisst (oder auch nicht) hab ich ja relativ viel mit beleuchtung herumgespielt. Speziell globale beleuchtungen sind immer noch nicht wirklich realzeit fähig. Es sind viele Paper unterwegs in denen mit hilfe von spherecal harmonics versucht wird die beleuchtung vorzu berechnen. Eigendlich wäre das konzept leicht zu verstehen, wenn man folgendes am Anfang gesagt bekommt:

Das ganze ist nur brauchbar wenn es nur die Skymap keine lokalen Lichtquellen gibt.
Das das komplette Licht vorberechnet ist. Einfügen von schatten werfenden objekten verlangt quasi eine neue Berechnung des Lichtaustausch.

Das Grundprinzip ist jetzt, das quasi für jeden Vertex oder Texel, jede denkbare beleuchtung vorberechnet wird. Sozusagen jedes Texel der Skymap ist eine mögliche Lichtquelle, In der praxis ist es leider so, das man unmöglich per Vertex eine komplette cubemap speichern kann. Irgend wie ist dann jemand auf die Idee gekommen die Umgebungsmap mit hilfe von spherical harmonics zu komprimieren. Irsinniger weise bleibt nach dem test weisem dekomprimieren nur einer wirklich start gebluerte map zurück, Etwas anderes kann man ja auch nicht erwarten, wenn man nur noch 4,9, 16, 27 oder 64 Kooeffizienten übrig hat. Besonders dann wenn man die version mit den 64 koeffizienten anschaut, fallen zwei dinge auf: Die starke verwandschaft zur DCT die in den JPEGs verwendet wird und das 64 koeffizienten immer noch viel zu viel sind.

Nun kann man auch erst einmal feststellen, das es völlig irsinnig ist al diese Berechnungen im frequenz raum auszuführen. Das Hauptargument ist immer, das das Oberflächenintegral über die ganze Sphere zu einem einfachem dot produkt reduziert wird, da allerdings diese paar Koefizienten exakt genauso viel an infomationen speichert wie die gleiche Anzahl an virtuellen Lichtquellen welche ebenfalls mit einem einfachem dotprodukt verrechnet werden können. Fällt dieses argument wohl weg.
Der einzigste denkbare grund Spherical harmonics zu verwenden wäre, das diese sich wie eine einzelner Jpeg Block weiter auf bit ebene komprimieren lassen. d.H. für die höher frequenten Anteile weniger bits zu speichern benutzen, allerdings wird dies weder irgend wo erwähnt, noch durchgeführt, da Bitoperationen erst mit shader model 4.0 karten möglich sind jedoch wahrscheinlich kaum eine sinvolle Geschwindigkeit machbar wäre.... (Im einfachstem fall verteilt man eine feste anzahl von bits auf jeden koeffizienten)

Da dies allerdings nicht durchgeführt wird kann man genauso gut eine gewisse Anzahl von unschafe großflächigen lichtquellen auf der skymap verteilen, und für jede mit hilfe von radiosity die sichbarkeit speichern. Man gewinnt gegenüber den SH einige vorteile:

Nicht aktive lichquellen können komplett entfernt werden
Den größten einfluss hat die sonne, sofern das Licht dieser dynamisch berechnet wird (wegen schattenwurf dynamischer objekte), kann das indirekte Licht durch eine kette von virtuellen vorberechneten lichquellen dargestellt werde, deren direktes licht fehlt. (Kein problem, da der licht transport ja vorberechnet ist)

Lohnen tun sich Spherical Harmonics für globale beleuchtung also nur wenn der Speichergewinn für die bitweise Koeffizientenkomprimierung, den aufwand für die dekomprimierung wieder ausgleichen kann.

Sollte reichen erst einmal reichen um eine diskusion zu eröffnen...

_________________
Lumina plattform unabhängige GLSL IDE

Also ich für meinen Teil kann an dieser Diskussion nicht wirklich teil nehmen, da das Thema hinter meinem Horizont in diesem Bereich liegt. Ich möchte allerdings darauf hinweisen, dass wenn Ergebnisse aus dieser Diskussion oder deinen Nachforschungen vorliegen diese sich sehr gut im Wiki machen würden. Etwas tiefergehendes Wissen aus der Forschung ist immer gern gesehn.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich hab mich Spherical Harmonics nicht wirklich beschäftigt aber kann auch so was dazu sagen.
Das Problem an vorberechneten dingen sind die Speichergröße, man braucht sehr viel speicher auf der HDD oder im Speicher und die welten werden immer komplexer(größer,detailierter,dynamischer).
Wenn man da lightmaps,occlussionmaps und so weiter verwendet ist man so ziemlich erschossen, da man dann mit BlueRay schon nicht mehr ausreichend speicher hat. Die Maps müssen auch in den Speicher gelangen und wenn man für eine kleine Szene neben Textur(normal,color,spec,height),Shader,Mesh noch Daten für Licht hinzu bringt, dann werden die 256MB Speicher von der PS3 oder 512MB der XBox360 garnicht mehr ausreichend.
Deferred shading ist deswegen auch eine tote technologie, nicht weil man noch aktuell probleme hat AA zu supporten, sondern weil der Speicher viel zu knapp ist.
PS4 und XBox... werden es vieleicht möglich machen aber aktuelle Consolen nicht und auf PC auch nur eingeschränkt(GF8800 aufwärts,hd2xxx aufwärts).
Screen Space Ambient Occlussion ist auch so eine Totgeburt, die Ergebnisse, die man bekommt, sind völlig falsch, heben die einzelnen polygone eines meshes hervor und wirkt damit kantiger und brauchen auch gut rechenpower, um viele macken leicht zu kachieren.

Interessante Technologien, die sich wohl in den nächsten monaten-Jahren etablieren werden, sind wohl dinge wie Virtual Texture(nicht clipmap textures ala MegaTexture), Texture synthese, prozedurale materials(shader,texturen,scripte), deferred shading, state management und Parallel Split Shadow Maps.
Technologien wie "hot asset loading" oder "mesh streaming" sind schon länger bekannt aber werden noch viel zu selten verwendet.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Das großte problem in zukunft wird das indirekte oder globale licht bleiben. Ein deferred renderer z.B. kann nur das direkte licht berechen und wenn man den indirekten anteil durch einen festen ambienten anteil ersetzt, sieht alles auch einmal wieder eintönig aus.

Die spherical harmonics sind im prinzip nur ein Sonderfall, die nur dann funktionieren, wenn das licht nur von einer umgebenden sphere eingestrahlt wird und die scene statisch ist. Prinzipell kann man dann fast auch wieder zur lightmap greifen, wenn sich die beleuchtung der sphere nicht ändert (Was bei einer skymap ja meistends nicht so der fall ist).

Zum deferred renderer und kein antialiasing: Im prinzip ist die hardware seit der GF6/7 dazu inder lage, Allerdings gibt es keinerlei extensins um auf die samples einzeln zuzugreifen. So weit wie ich weiß wurde in einem PS3 game eindeferred renderer verwendet der zumindest 2x AA verwenden kann. Da unter DX10 das auslesen einzelner samples funktionieren muss, werden wir hoffendlich in OGL3 auchden zugriff darauf erhalten.

SSAO: Hier kann ich nur zustimmen, das es jeglichem konzept von realistischem rendern wieder spricht. Auf der einen seite geht man dazu über realistischer zu berechnen (HDR...) und dann hohlt man sich so einen völlig fehlerhaft rechnenden algoritmus dazu und lässt den nicht nur das ambiente licht modulieren, sondern auch noch das direkte....

Dann war da noch die Idee das indirekte licht mit hilfe von virtuellen lichquellen zu berechnen, die auf den angestrahlten objeflächen plaziert werden, jedoch kann man das konzept quasi völlig vergessen, da man auf keinen fallnoch dazu in der lage wäre die unmangen von shadowmaps zu berechnen, ohne diese wird das ergebnis nur noch schlimmer, da das indirekte licht dann auch durch wände scheint und jeglichen realistischen eindruck verhindert.

_________________
Lumina plattform unabhängige GLSL IDE

Ich bin nicht in der lage das selbst zu testen, aber du anscheinend schon. Kannst du nicht den festen Anteil "pseudo korrekt" berechnen? Mach eine distanzabhängige Berechnung für den ambient anteil und leg ein 10%iges rauschen drüber.
Ich denke das menschliche Gehirn wird nicht in der Lage sein die Fehler als solche zu erkennen, sondern es wird wie üblich versuchen das Bild zu interpretieren, d.h. die Realität an das Gesehene anzupassen.

Falls du es ausprobieren kannst, wäre es cool wenn du Bilder davon hochladen könntest. Einfach um zu sehen wie die einzelnen Methoden wirken.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Licht-/Schattenberechnung ist momentan wirklich ein schlimmes Thema, es fehlt noch die gute Lösung.
Schatten finde ich mit pssm schon ziemlich praktisch aber hat man ja immernoch das problem mit den harten schatten, die korrekt weich zu machen ist ja quasi über der leistung der aktuellen Grakas. Penumbra und Enumbra müsste man vieleicht mal probieren mit ein geometrieshader und der Siluette eines Models vresuchen zu konstruieren und über das normale fragment blending dann den fade realisieren. Also harten dunklen kern durch die siluette erstellen und dann irgendwie über den geometrie shader und den tiefeninformationen+lichtposition den fade aufbauen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Die Siluetten mit einem geometryshader in ein VBO zu schreiben wäre noch machbar. Dann wird es problematisch, weil jede Kante abhängig von der lichform zu einem prismaähnlichem raum expandiert wird. Dann musste man für jedes fragment die entsprechenden räume finden. Richtig komplex wird es dann wenn sich schatten von verschiedenen entfernungen aus überdecken, da dann für das fragment eine komplexe verdeckungs figur berechnet werden muss.
Besondere problem gäbe es außerdem, wenn schattenwerfende objekte kleiner sind als die lichquelle, da deren kernschatten dann nicht mehr unendlich lang ist.
Ich denke das tema könnte dann interresant werden, wenn die shader so flexibel werden, da s man mit denen das machen kann was mit cuda möglich ist.

Wenn es nur um eine geringe unschäfte gehtkönnte man auch abhängig vom normal im screenspace filtern, jedoch ist da die bedingung das die schatten wenigstends Aliasing arm sind (Da man dieses nicht durch filter mehr entfernen kann)

@Flash: Rauschen ist immer schlecht, auf distance basis geht schon gar nicht mehr, da dann das licht durch massive Wände und Decken in andere Räume durchscheint. Damit fällt auch fast jede andere technik flach, die nicht die umgebungs geometry vollständig beachtet.

Das haupproblem bleibt, das die globale beleuchtung einen visuellen anteil von 30 (viele lichtquellen) - 70% (wenig lichtquellen) ausmacht. Jedoch auf konventionelle weise 99,9% der rechenzeit verbraucht.

Ich hab schon üerlegt ob man die vorhandenen shadowmaps dazu verwenden könnte eine lightmap zu erstellen, welche nur das direkte licht enthällt. Diese wird dann mit hilfe einer komprimierten raidiosity matrix in indirektes licht umgewandelt.
Aber auch das bringt eine neue klasse von problemen mit sich:
Die shadowmaps müssen auch außerhalb des sichtbereichts einigermaßen korrekt sein.
EIne unkomprimierte radiosity matrix wächst quadratisch mit der anzahl der flächen.
Es wird sehr viel unötiges berechnet (solang die sichbarkeit noch nicht bekannt ist, wird das komplette indirekte licht berechnet....von der ganzen welt....)
Die build maschine könnte unter umständen sehr viel ram benötigen und auch sehr lange brauchen...

_________________
Lumina plattform unabhängige GLSL IDE