erm you said this are 290000 polygons

does the model consist of 290000 polygons as well? or did you use a subdivision to make it look smoother


i bet subdivision because modelling something with 290000 polygons is a pain in the ass you need a really good computer to do that

The technique that Yann describes is called shadowbuffers. Shadowmaps technique is one where geometry is colapsed onto a plane or planes and that is then captured into a texture thus shadowmap. This is used in the current games a lot I read and can confuse a newbie who read about hw shadowbuffers and thinks shadowmaps are the same thing. Charles Bloom''s website has more info on most shadowing techniques, worth a look.

Yann, are you getting biasing issues? This is the reason why I stayed away from shadowbuffers and instead use shadowvolumes. I''ve seen humus''s demo that has these artifacts in the distance and it isn''t pretty. I also read about object ids to combat biasing but then you don''t get selfshadowing on an object. I actually like your shadows so perhaps I''ll do me a test app and see how it goes. Anyways, nice cathedral and I agree with using per-pixel lighting as I think the tech is useable now. I use it on my gf2 and it''s pretty. I would say in dark games you might get away with doing no shadowing at all.

quote:
Got any more screen shots you can show us?

I have plenty, but I need to check back with marketing. I guess some publicity won''t hurt at the current development stage

quote:
does the model consist of 290000 polygons as well? or did you use a subdivision to make it look smoother
i bet subdivision because modelling something with 290000 polygons is a pain in the ass you need a really good computer to do that

It would be bliss to work with, if it was only 290k for the model... There are 290k faces visible in that frame. The cathedral model itself is approx. 4 million faces. The complete level (there is a terrain and town outside) takes 48 million faces. This is geometry only, and does not include instanciated objects (such as characters, trees, grass, etc). Those are cloned from reference models at runtime, so they take minimal memory.

But a 3D scene is not purely made of trimesh geometry. Large parts are parametric surfaces (NURBS, NURMS, spline surfaces). Those are tesselated at runtime, and make up approx. 30m faces of the 48m. The remaining 18m are hand modeled triangular meshes. You are right, scenes of that size are not manageable in a modeller. We use SGI workstations, but still it''s too much. So we split up the scene into several smaller parts (4 to 5 million faces each). The complete scene gets merged and compressed into a single one at level compile time.

quote:
The technique that Yann describes is called shadowbuffers. Shadowmaps technique is one where geometry is colapsed onto a plane or planes and that is then captured into a texture thus shadowmap. This is used in the current games a lot I read and can confuse a newbie who read about hw shadowbuffers and thinks shadowmaps are the same thing

Well yes, terminology can be confusing. The technique I was talking about is actually called shadow maps. That''s those with the zbuffer, from the light''s point of view. It''s the generally accepted term for this kind of shadowing.

Here a small list:

shadow maps: shadows rendered through the projection of the light''s zbuffer, and realtime depth compare. Example: Shadows in 3DSMax, Maya, etc.

light maps: (typically precomputed) RGB textures, that encode the full effect of a lightsource onto an object. Example: any Quake game.

projective shadows: Render a greyscale mask of an object, and use projective texturing to project it onto other geometry.

volume shadows (or stencil shadows): extrude shadow geometry along the silhouette edges of your objects. Check for each fragment, if it''s in an extruded shadow volume. Example: Doom3.

Shadow splatting: take the geometry of your object, and ''spalt'' it onto eg. a ground plane, by projecting the vertex positions.

There are several more techniques (adaptive shadowmaps, raytracing, deep shadowmaps, etc), but those in the list above are the most commonly encountered in realtime, on consumer level hardware.

quote:
Yann, are you getting biasing issues?

No, not really. I''m using the second-depth shadowmap technique, and it works very well. OTOH, I occasionally get aliasing artifacts, but that''s unavoidable with shadowmapping. But most of the time, they are unnoticeable, and can be aleviated by dynamically adjusting the resolution of the depth textures. Or by using perspective shadowmaps.

/ Yann

Here''s an article by Charles Bloom and his explanation of various shadow techniques:

source: http://www.cbloom.com/3d/techdocs/shadow_issues.txt

When I was researching shadowing techniques I found it confusing when people refered to shadow/depth buffers as shadow maps. Your "shadow splatting" is better termed as "projective shadow" or "planar shadow" because you''re projecting vertices onto a plane or set of planes.

Thanks for the link. I have not read it in detail yet but the way they handle bias sounds interesting and something I like to experiment with.

quote:
Here's an article by Charles Bloom and his explanation of various shadow techniques:

Well, his terminology is incorrect *). Just run a Google search on 'shadow maps', and check the results. Or start up 3DSMax, and check the light shadow properties. Or read the OpenGL specs. Or the Direct3D specs. Or read the definition of shadowmaps from the Siggraph advanced rendering course notes by Silicon Graphics: click.

Trust me, it's called shadow mapping.

*) Not really incorrect, just inconsistent with standard denomination. The term 'shadow buffering' is a synonyme of shadow map. But the term that is commonly used for this technique is shadowmap.

quote:
When I was researching shadowing techniques I found it confusing when people refered to shadow/depth buffers as shadow maps. Your "shadow splatting" is better termed as "projective shadow" or "planar shadow" because you're projecting vertices onto a plane or set of planes.

The term was perhaps not well chosen (shadow splatting is a actually a somewhat different technique, see here). But projective shadows are almost always associated with projective textures, so that this denomination would also be misleading.


[edited by - Yann L on January 12, 2003 7:41:01 PM]

Currently there are some game people who differentiate shadow mapping from shadow buffer technique. Because of this I think it would be logical to use shadow mapping when we talk about mapping shadow texture onto geometry. Btw, Nvidia shadow doc(gdc2k1_shadows.pdf) use the term Shadow Depth Buffer instead of shadow mapping. Goto http://www.nvidia.com/view.asp?PAGE=geforce3 it says:

"Another new feature of the GeForce3 Titanium series, shadow buffers create realistic shadow effects in real time. Enables self-shadowing for characters and objects, and softens the edges of shadows for realistic effects, adding depth to scenes and highlighting spatial relationships between objects."

Many who use your terminology say "hardware shadow mapping" to differentiate the old tech. from new tech.

Most text use the term planar shadows to refer to the tech. where the vertices are collapsed onto a plane making up the shadow. Projective shadow term can be tricky because it could mean planar shadows as well as shadow mapping. Shadow splattering as well as projective shadow are meaningless terms as all shadows exhibit this behavior. Same goes for planar shadows as most shadows are put on flat surface but because texts used this term to mean vertex collapsing I think it is ok to call it that. In the old days planar shadows were expensive to do so only a single plane was used for the shadow, usually the floor. I''ve since collapsed my shadow onto all planar surface like walls, floors so in this case the old term lost its meaning somewhat.

quote:
Currently there are some game people who differentiate shadow mapping from shadow buffer technique. Because of this I think it would be logical to use shadow mapping when we talk about mapping shadow texture onto geometry.

No. It would be logical to use the term that has been accepted as standard. If you just change the meaning of a term, because it seems more appropriate to you, then be ready for lots of misunderstandings. Oh, and nVidia also makes extensive use of ''standard shadowmaps''.

quote:
Many who use your terminology say "hardware shadow mapping" to differentiate the old tech. from new tech.

No, we use that term to state that the technique is hardware accelerated. In contrast to ''software shadow mapping'', which is just the same technique, but computed on the CPU. 3DSMax, for instance, uses software shadow mapping in it''s renderer.

Anyway, enough terminology debating. I don''t think that this was the intend of the OP, when he started this thread.

quote:
1) how many light sources are there in the scene ?

In the total scene, around 480 standard lightsources, and a little over 1200 virtual sources (pointlights without an apparent source, automatically placed at level compile time, to simulate a radiosity-style ambient light atmosphere). In the cathedral, 39 lights.

quote:
2) what kind of fps you get if you have to rebuild all the shadowmaps per frame ?

Considerably less. The caching algorithm is an integral part of the engine, you could almost say that the engine was built around it. The system does not work without the cache, so I cannot give you an exact figure. But I'm sure, that the game would be absolutely unplayable, if it was disabled. The scene has a very high polycount, so re-rendering all cubemaps every frame would be deadly. Not to forget about the horrendeous VRAM trashing on the 3D card, as there is not enough space even on a 128 MB card to store all the shadowmaps at good resolution.

Well, stating that the cache does all the work is an oversimplification, there is much more to it. The cache itself is a multiresolution, priority driven LRU scheme. It uses lazy evaluation: as soon as faces influenced by a certain lightsource enter the view (ie: inside the frustum, and not occluded), the system assigns an importance-factor to the light. The importance depends on parameters such as distance, intensity, influence (if there are lots of other bright lightsources around, they might mask out this source), and various other. The system also checks, if a shadowmap is already available in the cache, if so at what resolution, and if it needs partial of full updating. It then inserts the lightsource into the cache. The thing is repeated for all visible sources. Note, that at this point, nothing is rendered yet.

A fixed amount of VRAM is dedicated to shadowmaps. The cache system now assigns a resolution to each map in the cache, depending on it's importance factor. Maps that are already in the cache (and don't need updating) get special care (the system tries to assign them the resolution that is already available, to avoid downsampling). At this point, all shadowmaps that need to be updated are partially re-rendered, and can be used in the subsequent scene rendering process.

That's a quick outline. There are a few catches, though. First of all, we only have a limited amount of texture units available.
Some (if not most) of them will be taken by other per-pixel effects (material, bumpmaps, reflections, etc). So, if you have too many lightsources inluencing a certain area, mutiple passes can become necessary to treat them all. This obviously depends on the amount and density of lightsources. Our system tries to
minimize multipass operations by reordering the geometry.

LOD is another very important point to consider. If you are far away, and look at the city model, you'll see hundreds, if not thousands of lightsources on the same frame. They are far away, and thus at low resolution, but they will still stress the pipeline a lot, and might trigger multiple passes. The solution is pretty simple, actually: spatial source clustering. Consider a table, with lots of candles on it. Each candle has it's own lightsource. When the camera is near, we want to treat them separately, so that each one can cast independent shadows. But when it is far away, we can simply replace all candles by a single lightsource: disable the individual sources, and create a new one that accumulates the influence of all the smaller ones. If the system is well adjusted, artifacts are unnoticeable, and the number of lights to treat per frame will decrease considerably.

quote:
3) how accurate are your shadow maps, can you make a close up at character's face and see for example how its nose shadows its face ? dose it still look good in such case ?

Normally, yes. The cache system will make sure to use a very high resolution shadowmap near the camera, as those maps have a high importance factor. Also, using perspective shadow maps helps a lot. The quality near the camera is comparable to stencil shadows, but a little blurred. That's unavoidable with shadowmaps, but actually looks good IMO, as it simulates soft-shadows.

I'm currently putting together a small collection of shots, I'll try to add a closeup on a character face.

quote:
I'm currios becouse if you're getting good results i may consider to switch, or even build another pipeline for shadow maps.

If you're on a tight deadline, such a switch is very dangerous and might break your neck. There are lots of small, yet very time consuming issues to resolve, and your engine will probably need to be significantly modified. It took us (me) quite a long time to get the shadowing to work in complex scenes, without creating artifacts. There's a lot of trial and error involved, until you find the right settings.

But if you are not limited by a deadline or budget, then go for it. Shadowmaps really need some more publicity, with everybody using stencil shadows lately...

/ Yann

[edited by - Yann L on January 15, 2003 7:26:19 AM]