quote:
whats the difference between a lightmap and a shadowmap?

A lightmap is a (typically pre-calculated) texture map that contains the intensity values produced by a specific lightsource on specific geometry. The intensity values encode any possible shadow-effects, or even colour bleeding, in the case of radiosity.

Shadowmaps, OTOH, do not contain the actual light values. They contain a depth-buffer from the viewpoint of the light. The textures themselves do not store RGB values, but depth values. They are computed in realtime, for each lightsource, using render-textures (p-buffers). Directional lights and spot-lights need a 2D texture, while pointlights use a cubemap texture. When rendering your scene, a special kind of depth compare operation (supported on GF3+) is done on the shadowmap's depth value and an interpolated component. The result is a realtime per-pixel shadow information, that can be used in a subsequent pixelshader.

More informations about shadowmaps can be found here. (and a few more papers on the nVidia developer site).

quote:
Beside this, I plan do compute the lightning for my indoor racing game through radiosity. Will the result of the radiosity calculations then be more lightmap-like or shadowmap-like?

Radiosity is precomputed, and therefore its solution is stored in lightmaps. You cannot (yet) compute radiosity in realtime. But ofcourse, the visual results of radiosity are excellent, so it might be worth using lightmaps for this purpose. Although you can combine lightmaps for the overall lighting, and shadowmaps for the effect of local dynamic lightsources.

quote:
ps. how's the game going? any expected release dates?

Not yet. The shot above is from a public demo level, that isn't yet public because of .. hmm.. incompetent management people... nuff' said. Isn't so easy, if you develop a large game with a small team in a gamedev startup, while privately financing the development.

/ Yann

[edited by - Yann L on January 9, 2003 7:38:05 PM]

wow that looks awesome

i read the article but sadly i only have a gf2 ultra i want to buy a new system with these FX cards in around 6 months

so is there a way to do it on GF2 ultra cards as well or do i have to wait ?

>>Holy shit! Yann! How did you pull those frame rates off? That''s incredible. <<

shadowmaps aint really affected much unlike say stencil shadows but the scenes polygon count, BUT theyre not to good for positional lights + aint supported on a lot of hardware

>>so is there a way to do it on GF2 ultra cards as well or do i have to wait ?<<

arb_shadow is part of opengl1.4 ive done it on a gf2mx (but its very very slow <0.1fps) as its done in software.
there is another method that does work on the gf2 (its what i used in the screenshots below of KEA) but its limited to 8bits resolution (there r ways around this though) + its slower than arb_shadow (on cards that support arb_shadow that is)
check shadowmaping at the nvidia developer site

http://uk.geocities.com/sloppyturds/kea/kea.html
http://uk.geocities.com/sloppyturds/gotterdammerung.html

i have downloaded they demo it worked fine for me

quote:
Holy shit! Yann! How did you pull those frame rates off? That''s incredible.

Besides optimization, one simple guideline: don''t render what you don''t see. Eg, if an object is small and far away, switch from perpixel to vertex lighting. Switch off other expensive perpixel effects based on distance. Cache as much information you can (eg. shadowmaps from non-moving lightsources).

quote:
shadowmaps aint really affected much unlike say stencil shadows but the scenes polygon count, BUT theyre not to good for positional lights + aint supported on a lot of hardware

The former problem is not really a problem, they work pretty well for positional lights, actually. You just have to design your engine pipeline with this in mind (efficient cubemap rendering and separation). The later one can be a problem: hardware support is reserved to newer cards, ie. GF3 and above. If you want your game to run on lowend hardware, then you''ll need some kind of fallback.

quote:
i have downloaded they demo it worked fine for me

Yeah, that''s because it detects the card type, and uuses the shadowmap ''simulation'' zedzeek mentioned. Basically, you can simulate shadowmapping on a GF2, by alpha and registercombiner tricks. But it''s not as accurate and good looking as real shadowmapping, and is much more performance hungry.

/ Yann

the method above works for points lights only how about directional lights?

generate a static shadow map with precompiled depth values?

or do i set a faked point light far away draw it and use this?

of course without drawing the skybox

quote:Original post by Basiror
the method above works for points lights only how about directional lights?

Even easier. You need a cubemap for point lights, but only a standard 2D texture for directional lights. Project it using ortho projection.

quote:
generate a static shadow map with precompiled depth values?

Not precompiled, but computed on the fly, everytime something changes in the scene, or the light moves. This will give you 100% dynamic lights with dynamic shadows.

But keep in mind, that shadowmaps will only work on GF3+. If you want to develop for a GF2, then lightmaps will probably be the better choice. The GF2 regcom shadowmap trick works only for small demos, and is not really well usable for a large scale game. Perpixel lighting is a nice alternative to traditional lightmapping, but only on highend hardware.

/ Yann

damn i should buy a gf3 for a few $$ to go on in development