pointlight shadowmaps

Yes. I did exchange some words with some NVidia guys about this issue 6 months ago but they thought at that time it would be difficult to realise, but the dpslacement map might be the perfect thing. Will check that :wink: Thanx…

The work I do is simillar to MCCool but the real trick I think is the way to use a “shrinking” image process to generate the simulation of soft shadow with umbra/penumbra fx. I have also made some image passes that takes care of the capping so you get perfect capped volumes without any problem as you walk into the volumes etc… The algo is alsoe described on the web pages I have…

Will go and check the image displacement mapping now :wink:

The original poster is confusing the point-lights and omni-lights. Omni-lights are point-lights, but so are spot-lights. Spot-lights require one depth-map, but omno-lights require up to 6.

Rendering the scene 6 times is not as bad as you might think. The set of things that have to be drawn is only the things that can occlude light falling on objects that the camera can see that are within range of the light.

You ussually do not have omni-lights that can ‘see’ anywhere near as much geometry as the viewer can see. This is because the omni-lights are ussually fairly short range, while cameras can ussually see all the way to the far plane. The far plane for a light is ussually very close.

Even if you do have to send your geometry to the card 6 times to draw a cube depth map, it still may take less time than rendering your whole scene from the camera point of view (for many reasons), especially if the light has a small range.

Your visible light occluder determination algorithm may even determine that no geometry is important in certain directions and make it completely unnecessary to draw 1 or 2 of the cube faces.

All this is discussion is pointless because no one can prove or disprove anything about the slowness of cube depth maps until depth maps are extended to include cube depth maps. I would believe stencil-shadow volumes to be too slow as well if I had not seen fast implementations. I can still hardly believe that Doom 3 will run at acceptable framerates.

The proof of the pudding is in the eating. So far no one can even make any pudding (hmmm, pudding). All we have is imitation color index shadow map pudding… opps, be careful with metaphors, you might get hurt.

Where can i find more info about the new hardware and displacement mapping ?

Here is a start. Since Matrox is the only IHV with support right now, you may find more on their site.
http://developer.matrox.com/details.cfm?CFID=494274&CFTOKEN=79199891&s=docs&i=86

EDIT: There is also an artists guide, and in the paper there is an e-mail address to get more (hopefully technical) information from Matrox.

[This message has been edited by Nakoruru (edited 08-20-2002).]

Hey, blender, do you have a link to the sample you are referring to?

Here’s your shots: http://www.3dactionplanet.com/hitman47/hitman/screenshots/screens/rotterdam/16.jpg http://www.3dactionplanet.com/hitman47/hitman/screenshots/screens/budapest/10.jpg

But these doesn’t show how the shadows are actually casted on more complex environment.
In the game it looks very realistic.

thats just what i said, a projected shadow, rendered from the character. the other one doesn’t have shadows, the other shadows look different, and the maincharacter doesn’t selfshadow.