Shadow Mapping für Point Lights?

[tivolo]

hi,

weiß jemand eine gute methode, um shadow mapping auch für point lights hinzubekommen - mal davon ausgehend, dass wir KEINE pixel shader (aufgrund fehlender hardware) zur verfügung haben. sonst könnte man die distanz ja einfach in eine floating-point textur rendern... aber gut, eine radeon 9800 hab ich halt leider nicht :)

hab mir "dual paraboloid shadow mapping" (google is your friend) für pointlights angeschaut. die funktionieren allerdings nur, wenn die geometrie ziemlich high-tesselated ist -> schlecht/gar nicht geeignet.

es gibt immer noch die gute "alte" methode, eine cube-map für die 6 verschiedenen richtungen des pointlights zu verwenden - allerdings hab ich die befürchtung, dass meine geforce 4 schön langsam in die knie geht.


hmmm... shader 3.0 hardware for everyone :devil: dann wär das leben leichter.

mfg,
tivolo

[Chuck]

uhm ich bin zwar kein shadow mapping spezialist, aber ausser dem 6 faces in alle richtungen berechnen und projezieren ansatz denk ich mal gibts kaum was anderes (btw was meinst du mit distanz in ne float tex rendern?)

das problem mit pointlights is ja im endeffekt neben den aliasing artefakten einer der größten nachteile von shadow mapping und so schnell wirds dafür wohl auch keine besseren lösungen geben :)

[tivolo]

(btw was meinst du mit distanz in ne float tex rendern?)
einfach aus der position der lichtquelle den jeweiligen "abstand" in eine floating-point cubemap rendern. beim anderen pass aus der kamera-perspektive die gespeicherte distanz der float-cubemap vergleichen -> brauchst pixel shader 2.0 hardware und floating-point cubemaps dafür, welche allerdings nur von neuen der neuesten karten unterstützt werden (auf einer radeon 9800 hats funktioniert). float-cubemaps deshalb, weil du die distanzen nicht wirklich gut auf [0, 1] skalieren kannst (da geht viel information verloren).


das problem mit pointlights is ja im endeffekt neben den aliasing artefakten einer der größten nachteile von shadow mapping und so schnell wirds dafür wohl auch keine besseren lösungen geben :)
es GIBT bessere lösungen, z.b. einfach in eine depth-cubemap rendern. NVIDIA ist ja so brav und hat eigene extensions für sogenannte depth-textures, allerdings darf man von denen keine cubemaps anlegen, zumindest nicht auf karten < geforce 6800.
dass pointlights + shadow mapping wunderbar auf neuester hardware (6800) funktionieren können, sieht man am besten in der unreal engine 3. ich bin sowieso der meinung, dass shadow maps den stencil volumes früher oder später den rang ablaufen werden, weil's weder für CPU noch GPU so witzig ist, für models > 5000 polys zuerst die silhouette zu finden und anschließend an haufen schwarzer dreiecke zu rendern. des ganze noch für 3-5 lichtquellen und deine prozessoren sind ARG beschäftigt :engel:

mfg
tivolo

[Chuck]

einfach aus der position der lichtquelle den jeweiligen "abstand" in eine floating-point cubemap rendern. beim anderen pass aus der kamera-perspektive die gespeicherte distanz der float-cubemap vergleichen -> brauchst pixel shader 2.0 hardware und floating-point cubemaps dafür, welche allerdings nur von neuen der neuesten karten unterstützt werden (auf einer radeon 9800 hats funktioniert). float-cubemaps deshalb, weil du die distanzen nicht wirklich gut auf [0, 1] skalieren kannst (da geht viel information verloren).statt einer float cubemap sollte man auch ne rgb texture cubemap verwenden können (da kamma denn theoretisch die tiefe in die rgb komponenten codieren... zugegebenermaßen braucht man dann wohl immer noch ein fragment program um das codieren und die vergleiche durchzuführen und es wird im endeffekt sicher nicht so schön wie mit den richtigen depth textures von nvidia wegen fehlendem ordentlichen filtern, aber könnte unter umständen trotzdem reichen :) ). btw die z koordinate aller pixel ist (wegen der division durch h und des darauffolgenden clippings) immer zwischen [0,1] :shinner:



es GIBT bessere lösungen, z.b. einfach in eine depth-cubemap rendern. NVIDIA ist ja so brav und hat eigene extensions für sogenannte depth-textures, allerdings darf man von denen keine cubemaps anlegen, zumindest nicht auf karten < geforce 6800.
hmm stimmt depth-cubemap wär das optimalste... aber wie gesagt ich könnt mir vorstellen dass das auch mit ner rgb textur geht (der z puffer hat auch nur maximal 32 bit und in ner rgb bzw rgba textur kamma die durchaus unterbringen... könnte man auch mit ner luminance texture versuchen, auch wenn ich mir nicht ganz sicher bin wie das rendern in sone textur funzt :) )
dass pointlights + shadow mapping wunderbar auf neuester hardware (6800) funktionieren können, sieht man am besten in der unreal engine 3. ich bin sowieso der meinung, dass shadow maps den stencil volumes früher oder später den rang ablaufen werden, weil's weder für CPU noch GPU so witzig ist, für models > 5000 polys zuerst die silhouette zu finden und anschließend an haufen schwarzer dreiecke zu rendern. des ganze noch für 3-5 lichtquellen und deine prozessoren sind ARG beschäftigt :engel:

mfg
tivoloan und für sich find ich den shadow mapping ansatz auch irgendwie sympatischer (weil er meistens einfach robuster ist... stichwort alphatest *g*).

[tivolo]

btw die z koordinate aller pixel ist (wegen der division durch h und des darauffolgenden clippings) immer zwischen [0,1] :shinner:
genau deswegen speichert man ja die DISTANZ in die float-cubemap (ja, genau, punkt-punkt-distanz) und NICHT den Z-WERT (nur um das nochmal klarzumachen) - egal, wir haben sowieso keine fragment-programme.

mal was anderes: hab im moment den ansatz mit 6xrendern, usw. und es funktioniert soweit (wenn auch a bissl langsam auf meiner geforce 4).nur eines will ich überhaupt nicht verstehen:

512x512 shadow maps sind definitiv SCHNELLER als 256x256! (irgendwie komisch, oder?). wenn ich auf 1024x1024 geh, hab ich nur mehr die halbe performance, was auch logisch ist. aber warum sind 512x512 die schnellsten?

wennst mir das noch erklären könntest bin ich zufrieden :)

mfg
tivolo

[Chuck]

ah sorry hatte das mit der distanz automatisch als z-koordinate interpretiert :).
und bin auf jeden fall mal gespannt wie das ganze aussehen wird (wir ham zz noch keinerlei dynamische schatten bei unserem projekt, weil wir uns nicht so recht für nen algorithmus entscheiden können... )

hmm und sind die 512x512 wirklich schneller oder gleichschnell wie die 256x256? falls gleichschnell könnts vielleicht daran liegen, dass ihr geometrie limitiert seid beim generieren der shadowmaps. btw wie is es mit 128x128? :)

[tivolo]

mal ausgehend von 3 lichtquellen, per-pixel bumpmapping und einer geforce 4:

128x128: > 75 frames
256x256: 23 frames
512x512: 33 frames (kein schreibfehler!)
1024x1024: ~10 frames

kanns mir nur so erklären, dass sich der NVIDIA-treiber genau bei 512x512 dazu entschließt die textur in den schnellsten speicher zu legen, den die grafikkarte zu bieten hat. bei 256x256 denkt sich der treiber - vergiss es, die kopier ich jedesmal hin und wieder zurück; und 1024x1024 hat schlicht und einfach nicht platz.

was anderes fällt mir auch nicht ein...

mfg
tivolo

[Chuck]

hmm komische sache wird wohl echt am speichermanagement liegen...
müsste man mal unter www.opengl.org (http://www.opengl.org) im forum posten. den leuten dort fällt zu sowas immer was schlaues ein :)