ZFX
ZFX Neu
Home
Community
Neueste Posts
Chat
FAQ
IOTW
Tutorials
Bücher
zfxCON
ZFXCE
Mathlib
ASSIMP
NES
Wir über uns
Impressum
Regeln
Suchen
Mitgliederliste
Membername:
Passwort:
Besucher:
4394947
Jetzt (Chat):
23 (0)
Mitglieder:
5239
Themen:
24223
Nachrichten:
234554
Neuestes Mitglied:
-insane-
"Ambient Occlusion" von J. Diehl (joeydee)


Eine Global-Illumination-Methode, die normalerweise nur in Raytracern zu
finden ist: Ambient Occlusion berechnet die Menge des von der Umgebung
einfallenden Lichts (keine Selbstbeleuchtung, nur Selbstabschattung). Das
Ergebnis entspricht etwa dem von Radiosity, wenn man das Objekt vollständig
mit einem weißen "Lichtzelt" umgibt und nur einen Pass berechnet. Im
Vergleich zur Realität ähnelt es einem weißen Objekt an einem trüben Tag
ohne spezifische Lichtrichtung.

Das Besondere an meinem Programm ist, dass die Lichtinformation mit
Hardwareunterstützung berechnet wird und (da Betrachter- und
Lichtquellenunabhängig) wahlweise in die Vertices oder in eine Textur
"gebacken" wird und das Final somit ohne Einbußen in Echtzeit dargestellt
werden kann.

Das gezeigte Modell ist ein Download von 3dcafe mit 58736 Dreiecken (der
Boden wurde ergänzt). Die Berechnung dauerte auf einem 3GHZ-Rechner mit ATI
Radeon 9800XT-Karte ca. 1 Minute.

Der Ambient-Occlusion-Pass ersetzt im Final den ambienten Pass (der ja im
Standard-Beleuchtungsmodell keine Modellstrukturen zeigt). Der diffuse Pass
geschieht entweder mit Standardlichtquellen, oder besser, per Normal-Lookup
über einen Lightcube für den fast perfekten Global-Illumination-Look.

Die Bilder zeigen den Ambient-Occlusion-Pass, den diffusen Pass mit einer
Standardlichtquelle sowie die Kombination beider. Letzteres zeigt erst dann
gut sichtbare Unterschiede zum ersten, wenn sich die Lichtquelle bzw. das
Modell bewegt.

Weitere Anwendungen meines Programms sind die Berechnung von "bended
Normals" (aus welcher Richtung trifft das meiste Licht auf einen
Oberflächenpunkt?) und der Export einer Modellspace-Normalmap. Die Daten
werden bereits mitberechnet, nur der Export ist noch nicht gecodet. Das
Programm dient u.a. auch als Prerender-Tool für anschließend besseres und
einfacheres Skinning/Texturing (da schon vorberechnete Schatten in der
Textur zu sehen sind).






Von joeydee am 15.06.2004, 00:50:48 Uhr
erster ;)

Da das ja schon ein paar Tage alt ist und ich inzwischen weiter bin: so siehts mit Cubemap-lookup aus:

http://opengl.diehlsworld.de/demos/iotw_ao2.jpg

Von Marshal am 15.06.2004, 01:26:13 Uhr
Hölla, das neue Bild gibt jetzt wirklich nen plastischen Eindruck... sauba!

Von matrian am 15.06.2004, 09:53:46 Uhr
3.
Muss schon sagen sieht echt super aus!!
Weiter so!

Von Praios am 15.06.2004, 12:04:51 Uhr
Sieht schnieke aus...
Trotz der nicht vorhandenen Texturen macht es wirklich einen guten Eindruck.

Von Richard Schubert am 15.06.2004, 14:05:33 Uhr
nicht übel.
wie sieht denn die diffusecubemap aus, ist diese einfach wie bei HL2 durch sechs farbwerte realisiert, oder hat diese eine echte auflösung, oder verwendest du gar Spherical Harmonics?

Von anno1983 am 15.06.2004, 15:06:24 Uhr
Sieht echt super aus, auch wenn ich nicht verstehe was da eigentlich gemacht wird *g*

Für was macht man sowas? Für ein Spiel denke ich hat das ja keinen Zweck (Renderzeit). Könnt mir das jemand mal erklären?

Von joeydee am 15.06.2004, 15:42:32 Uhr
@Richard: die diffuse Cubemap ist das Ergebnis einer weißen Kugel, per HDRI beleuchtet und gerendert in eine Cubemap (fürs lookup). Das heißt, ich habe für jede mögliche Oberflächennormale den vorkalkulierten diffusen Lichtwert einer "echten" HDR-Beleuchtung gespeichert, ohne an ein bestimmtes Modell/Szene gebunden zu sein. Somit lassen sich sowohl die Modelle als auch die Cubemaps beliebig austauschen, ohne etwas neu berechnen zu müssen.

@anno1983: Doch, das gibt die Lighting-Equation für ein Spiel. Die momentane Darstellung läuft ohne Probleme in Echtzeit (inkl. flexibler Beleuchtung). Nur die Vorkalkulation dauert ein wenig. Die wird aber sowieso "offgame" in der Produktion erledigt.

Von Richard Schubert am 15.06.2004, 16:42:46 Uhr
das verstehe ich nicht ganz, die cubemap muss doch extrem unscharf sein oder nicht?

Von joeydee am 15.06.2004, 18:22:14 Uhr
Ist sie auch. Sie dient ja nur zur Beleuchtung, nicht zur Darstellung. Eine reine lookup-Map für die Normalen.

Von Richard Schubert am 15.06.2004, 19:03:11 Uhr
dann könntest du auch SHs verwenden, das wäre wesentlich günstiger, dynamischer/flexibler.

D3DXSHProjectCubeMap + http://home.comcast.net/~tom_forsyth/SH_GDCE_TomF.zip

wirklich sehr einfach zu implementieren
der occlusionterm ist aber trotzdem schon ne sehr schöne sache.

Von joeydee am 15.06.2004, 20:26:57 Uhr
Ich habe mir auch schon einiges über SH durchgelesen (u.a. das Paper von Robin Green). Die ppt kenne ich noch nicht, werd ich morgen mal durchlesen (hab hier gerade kein ppt).

Was ich bisher darüber weiß (ohne es probiert zu haben), verleitet mich zu folgenden Annahmen: Es kann sicher bessere Ergebnisse liefern wenn man alle Terme beachtet.
Allerdings halte ich die Vorberechnung und die Darstellung für wesentlich unperformanter.
Wirklich flexibel ist es auch nicht, da es auch nur auf fixe Szenen angewendet werden kann. Und für einfach zu implementieren halte ich es ebensowenig.
Und wegen meiner einen diffusen Cubemap für die komplette Szene bin ich sicher, dass ich besser wegkomme wenn ich diesen nicht über Spherical Harmonics rekonstruiere.

Von Richard Schubert am 15.06.2004, 20:36:09 Uhr
Zitat:
Allerdings halte ich die Vorberechnung und die Darstellung für wesentlich unperformanter.


eben nicht.

Zitat:
Wirklich flexibel ist es auch nicht, da es auch nur auf fixe Szenen angewendet werden kann. Und für einfach zu implementieren halte ich es ebensowenig.


eben doch.

Zitat:
Und wegen meiner einen diffusen Cubemap für die komplette Szene bin ich sicher, dass ich besser wegkomme wenn ich diesen nicht über Spherical Harmonics rekonstruiere.


eben nicht.

das ist ähnlich zu dem von Robin Green nur auf Objektebene nicht auf Vertex oder gar pixelebene.
aber wenn du die ppt anschaust wirst du es auch sehen können. also lass dich überraschen wie einfach es sein kann und wieviel flexibler/speichersparender es geht.

ist auch nur ne anregung, nicht das du jetzt unbedingt das einbauen musst.

Von joeydee am 15.06.2004, 22:11:46 Uhr
Jedenfalls danke für den link - werde mir das auf jeden Fall anschauen :)

Von ThunderEye am 15.06.2004, 22:19:58 Uhr
Hi,
jupp das sieht Spitze aus, respekt!
Wegen dem Power-Point Prob: http://www.microsoft.com/downloads/details.aspx?FamilyID=7c404e8e-5513-46c4-aa4f-058a84a37df1&displaylang=en Den benutze ich auch immer.
mfg
ThunderEye

Von joeydee am 16.06.2004, 08:35:03 Uhr
So, durchgelesen :) Ist ja tatsächlich sehr einfach gehalten, dafür gibt es halt ziemliche Einbußen. Selbstabschattung wird da (im Gegensatz zum "echten" SH-lighting) nicht reincodiert. Uff, war meine Hauptarbeit doch nicht überflüssig ;) Aber als reiner Cubemap-Ersatz (nicht unbedingt performanter, aber speicherschonend und flexibel) ist das interessant... wird ausprobiert :)

Von Richard Schubert am 16.06.2004, 11:58:32 Uhr
Zitat:
Selbstabschattung wird da (im Gegensatz zum "echten" SH-lighting) nicht reincodiert. Uff, war meine Hauptarbeit doch nicht überflüssig ;)


wie auch wenns nur auf raumebene ausgerechnet wird. aber deinen occlusionterm kannst du weiterhin verwenden, was das ganze sache super toll dastehen lässt. :D

Zitat:

Aber als reiner Cubemap-Ersatz (nicht unbedingt performanter, aber speicherschonend und flexibel) ist das interessant... wird ausprobiert :)

wieso nicht perfomant? ist dir das samplen einer cubemap etwa lieber als ein paar mikrige vertex shader operationen (11 - 13 slots an der zahl)?

das beste ist doch noch, dass noch weitere dynamische diffuselichter hinzukommen können, ohne großen aufwand betreiben zu müssen.

Von joeydee am 16.06.2004, 12:29:42 Uhr
Das mit den dynamischen Lichtern ist auf alle Fälle ein großer Pluspunkt.

Wie sieht es aus wenn ich das auf Pixelbasis (z.B. für Bumpmapping) mache und statt texCUBE() diese 9 Terme einsetze? Das lookup ist doch ne ziemlich einfache Sache und kann doch nicht teurer sein als SH? Oder doch? Klär mich auf...

P.S.: ich glaube wir haben hier alle verjagt ;)

Von Richard Schubert am 16.06.2004, 14:13:10 Uhr

ich weiß nicht genau was eine
Code:
tex t0

texm3x3pad   t1, t0
texm3x3pad   t2, t0
texm3x3vspec t3, t0

anweisung mit cubemap kostet, aber es wird sicherlich günstiger sein als die elf arithmetischen instruktionen mit den SHwerten. zusätzlich steigen dann die anforderungen auf ps.2.0... sicherlich nicht so toll, aber immernoch flexibler.

Zitat:
P.S.: ich glaube wir haben hier alle verjagt ;)

sind wahrscheinlich alle nur sprachlos wegen den schnieken bildern.

Von Godhand am 17.06.2004, 16:06:23 Uhr
Hi,

Sieht gut aus! IMHO gibt es dazu auch was in den GPU Gems.

cu, Godhand.