PDA

View Full Version : better volumetric lighting



zed
02-21-2005, 03:00 PM
http://uk.geocities.com/sloppyturds/nelson/2005_02_22.jpg
what i have at the moment looks very flat, eg the edges of the penumbra is just as much shaded as the inside, in real life dust particles within it would of travelled through more of the light area thus they would look brighter.
Now it looks way better if i use many lightplanes within the lightvolume, but all those blended polygons kill framerate. does anyone know of any
method of getting a similar looking result with a shader, with only drawing the outside light planes?

also i always have great difficulty in finding the best descriptive english word for something,
whats a better description of these light cast area planes, light aura/lightshafts? at the moment im calling them lightplanes whats the correct term?

cheers zed

V-man
02-22-2005, 04:13 AM
There is a method that doesn't use shaders:
Render the back polygons with fog ON, blending ON (src_alpha, 1-src_alpha), adding blend - Render the front polygons with fog ON, blending ON (src_alpha, 1-src_alpha), subtractive blend
It works by doing "far fragment fog color" - "close fragment fog color"
You will need to figure out silhouettes so the same algorithm as stencil shadows applies here.

zed
02-22-2005, 10:43 AM
thanks, i dont see how its gonna work though, surely with the fog it only takes into consideration the distance away, no wait actually now i think about it, yeah i think i see how it works, :)
it does require two passes though (which aint to bad i suppose), ill do it in a shader (ive ditched the fixed pipeline for now) and post a screenshot if sucessful.

pocketmoon
02-22-2005, 01:45 PM
render shadow volumes back to front, calculating in-scatter between illuminated sections :)

http://homepage.ntlworld.com/pocketmoon/mroom.jpg

Shadow columes must be depth sorted to copy with overlapping shadow volumes which otherwise screw up the in-scatter. I depth peel.

V-man
02-22-2005, 06:12 PM
it does require two passes though (which aint to bad i suppose)It's sort of similar to stencil shadows, so perhaps some special extension that can control the blend equation depending on polygon orientation is needed.
That or a programmable blending unit.
We could have something like



if fragment.facing == forward then
blendequation = "+"
else
blendequation = "-"
end if
Maybe pocketmoon is doing it in one pass?

zed
02-22-2005, 08:34 PM
that looks awesome pocketmoon, if i could achieve that visual quality ild be laughing, the technique though suffers from the same problems as stencil shadows (geometry has to be behaved/no alpha textures) so that sort of rules it out.

Now it looks way better if i use many lightplanes within the lightvolume, but all those blended polygons kill framerate.i actually tried this (more proof to not discount something until u try it)
http://uk.geocities.com/sloppyturds/nelson/2005_02_23A.jpg
http://uk.geocities.com/sloppyturds/nelson/2005_02_23B.jpg
using 20 tubes decreasing in size and the framerate didnt drop that much. in typical situations im not really expecting the camera to get inside the lightfrustum so i might just stick with this, nice and simple
cheers anyway v-man/pocketmoon

knackered
02-22-2005, 10:40 PM
Originally posted by V-man:

it does require two passes though (which aint to bad i suppose)It's sort of similar to stencil shadows, so perhaps some special extension that can control the blend equation depending on polygon orientation is needed.
That or a programmable blending unit.
We could have something like



if fragment.facing == forward then
blendequation = "+"
else
blendequation = "-"
end if
Maybe pocketmoon is doing it in one pass?No, that method relies strictly on the pixel being added *before* it's subtracted, thus it will always need to be in two passes.

V-man
02-23-2005, 06:55 AM
No, that method relies strictly on the pixel being added *before* it's subtracted, thus it will always need to be in two passes If the hw supports blending on float buffers, it should be possible to do it in a single pass.

The only problem is the z buffer.
I think here you can render every opaque object, disable depth writes leave depth test on, and render the light volumes.

For light attenuation effect (I'm not sure if Pocketmoon is actually trying to simulate scattering), you use a shader on the light cones and you can modulate with the fog color.
I think moon said he was doing this.

dorbie
02-23-2005, 09:26 AM
Depends on the details of what you're talking about. For example if you're doing scene geometry intersection with fog volumes you may still need multiple passes in places.....

pocketmoon
02-23-2005, 09:49 AM
Originally posted by V-man:
For light attenuation effect (I'm not sure if Pocketmoon is actually trying to simulate scattering), you use a shader on the light cones and you can modulate with the fog color.
I think moon said he was doing this.Hi,

There's a chapter in 'Graphics Programming Methods' in which I describe the whole effect ;)

I do a rough in-scatter calculation - the amount of light forward-scattered along an illuminated line-of-sight between shadow boundaries is calculated in a shader.

There was a discussion a couple of years back on this forum about the method. Similar to Radomir Mech's fog/light volumes (Journal of Graphics Tools Vol6 #3 2001), but my (more convoluted)method accounts for things like overlapping shadow volumes.

Have a look here :

http://www.wavestate.com/pics/pocketmoon.pdf

One day I'll spend some time updating the method to avoid nasty things like stencil buffer read-backs (Yikes!)

harsman
02-23-2005, 12:17 PM
The hackish approach is to modulate transparency with (viewvec dot normal) so the edges of the shadow turn more transparaent thus faking a penumbra. You might need to apply some sort of function to the actual dotproduct value to get decent result, like exponentiating or clamping or something.