"The hardest thing to understand in the world is the income tax."
- Albert Einstein
More pages: 1 ... 11 ... 21 ... 31 ... 41 ... 51 ... 61 ... 71 ... 81 ... 91 ... 101 ... 111 ... 121 ... 131 ... 141 ... 151 ... 161 ... 171 ... 181 ... 191 ... 201 ... 211 ... 221 ... 231 ... 241 ... 251 ... 261 ... 271 ... 281 ... 291 ... 301 ... 311 ... 321 ... 331 ... 341 ... 351 ... 361 ... 371 ... 379 380 381 382 383 384 385 386 387 388 389 ... 391 ... 401 ... 411 ... 421 ... 431 ... 438
Query Faileddavepermen
Sunday, March 7, 2004

very nice. would be cool to have some sort of transparent slide going trough the volume "scanning it".. to show more what its all about..

oh, and the ufo should get a (projected..) shadow..

and i explained you yet that we need henriks smoke and fire, of course..


oh, and do you do full global illumination? again, henrik can help you

bah.. it's a great demo the way it is. it looks impressive.

Humus
Friday, March 5, 2004

g0b,
yes, that could certainly be done.

Graham,
yes, coloring the light when in passed through glass could be done too. You'd need to go to at least 16bit color though, so that's twice the size, but it could maybe be worth it. There's a lot of things you could encode into a static texture like this. I came to think of an optimisation I overlooked. Right now I'm doing attenuation in the shader. But that could be baked into the lightmap instead. Should improve performance.

Tride,
the softness comes from true soft shadow calculation rather than from linear filtering. For each point I evaluate 100 samples within a light volume roughly the size of the fire and average it.

Tride
Friday, March 5, 2004

Cool demo !

The main drawback of this technique - in my opinion - is that the use of a 3D texture waste lot of memory compared to a "shadow cube-map".
Moreover the only relevant information is where the surface intersects the texture (ok, with dynamic moving objects in the scene it makes sense to have lighting information defined everywhere :-)

The softness obtained looks great. I guess it mainly comes from the linear interpolation - doesn't it produce some artefacts (i.e. thin objects wrongly shadowed) ? (unfortunately I can't run the demo ...)

However I don't think fog can be handled with good performances : It would require to render "the light volume" i.e. to render some front facing polygons (=> bad for fillrate since these polygons will cover the whole screen).
Hmmm ... it may be worth the try ;-)

Anyway, thanks for all these cool effects !


Graham
Friday, March 5, 2004

Very impressive I like it

it has a smoothness to it that is impressive given that the texutre isn't really all that high res (eg, 6x64x64 cube shadow map would look pretty ugly compared to this).

Also if it were colour you could do real stained glass/fog shadows. And radiosity too. But I guess computation time for these would go through the roof.

And I it's very impracticle for large lights. Maybe a 2D lightmap for big lights such as the sky, and little 3D maps for all point lights.

g0b
Friday, March 5, 2004

Hi,

You could improve the realism of the demo by faking dynamic lighting of the fire. I this this could be done for cheap by adding a random perturbation to the 3D lightmap's texture coordinates...

G!ZMo
Thursday, March 4, 2004

@z

you have to add this to your windows-registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\NVIDIA Corporation\Global\OpenGl\Debug]
"ShaderObjects"=dword:00000001
"WriteProgramObjectAssembly"=dword:00000000


this works fine for my fx5950ultra

Humus
Thursday, March 4, 2004

MesserFuerFrauSchmid,
well first of all, 2D maps aren't neccesarily "always fast" just because it's a certain format. It also depends on how they are used, size, access pattern etc.

Also, 3D textures aren't always neccesarily always slow either. There's nothing saying that 3D textures must have significantly worse caching behavior. Worse, yes, significantly worse, no. The hardware probably uses something like Morton order that will ensure that spatially close pixels are in most cases also close in one-dimensional memory space. Then you have the access pattern. For every texel loaded from the 3D map, tens of texels are loaded 2D maps. This is because the lightmap is sparsely sampled and constantly is in magnification mode. If you remove the lightmap entirely from the shader you'll see that the performance doesn't improve significantly. It goes from 110fps to 115fps for me. A whooping 4.5%!

There just isn't any general rule that 3D textures must be slow, and in this demo it's not even close to being the bottleneck. In most situations where 3D textures are useful they are accessed in ways that are fairly cheap.

NeoKenobi
Wednesday, March 3, 2004

@FrauleinSchmid

You're right about the 2D maps part, but don't think computing the lighting realtime is cheap. Not to mention the soft shadows, multiple passes with stencil buffer shadowing are much more expensive than using a 3D texture. On the other hand, using shadow mapping with textures is also very expensive, but not anywhere near multiple passes with the stencil buffer.

Btw. this is a demo, meant to demonstrate graphical technologies, NOT A GAME!

More pages: 1 ... 11 ... 21 ... 31 ... 41 ... 51 ... 61 ... 71 ... 81 ... 91 ... 101 ... 111 ... 121 ... 131 ... 141 ... 151 ... 161 ... 171 ... 181 ... 191 ... 201 ... 211 ... 221 ... 231 ... 241 ... 251 ... 261 ... 271 ... 281 ... 291 ... 301 ... 311 ... 321 ... 331 ... 341 ... 351 ... 361 ... 371 ... 379 380 381 382 383 384 385 386 387 388 389 ... 391 ... 401 ... 411 ... 421 ... 431 ... 438