Jump to content
  • Advertisement


This topic is now archived and is closed to further replies.


Soft stencils vs soft shadow maps

This topic is 5420 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I need to implement shadows in my engine, so I was deciding on whether to go with shadow volumes or shadow maps. Though ordinary shadow maps are much faster, I need to know which is faster, since I''m going to make them soft, and when the engine displays a scene with 200 odd lights, the shadow maps would also be slow. What I wanted to know is, when there are many lights and a high poly scene, which works out to be faster - stencils or shadow maps? Thanks.

Share this post

Link to post
Share on other sites
I''m not The Dude in shadows (or anything else, actually ) so I''ll just tell you what I can:

- If you have 200 lights in a scene, even simple "N dot L" lighting would be slow . Has to be done in a VS, too, because all cards (as far as I know) can''t have 200 active lights (and you''d have to multi-pass)

- When the number of lights is large, you usually find - for each object - the N lights that contribute most to the object (not necessarily the closest N lights, depends on light properties), and then do a rough approximation for all the others or just ignore them.

- You might want to use the search feature (*evil grin*), and look for recent topics about shadows. Muhammad Adel (nick: mohamedadel, I think) wrote a lot about shadow volumes, their bottlenecks, optimizations, ...etc

- Shadow volumes: There are - at least - a couple of articles on GDNet that talk about the downsides of these (mainly: Fill-rate intensive).
Scenes with lots of trees, or a wire-fence (there''s some similar scene in Splinter Cell''s briefing, in the beginning. In the office, I think. Where shadows were cast by the I-don''t-know-the-name-but-it''s-some-kind-of-"curtain with lots of slits"-on-a-window on the place) can''t be done with shadow volumes, because the fill-rate would''ve been murder.

- Soft shadows with shadow volumes: Still in the works. There are some papers (and implementations) about it, but all the solutions aren''t fast enough for games, yet.

- Shadow maps: Require reading depth values. Have not seen a fast shadow-map sample on DX.
I''ve read somewhere that they''re not general-purpose/generic (It was said that some cases can''t be done using shadow maps, though I have no idea what these cases are).
Require render-to-texture.
Can - easily - do soft shadows.

A lot of people believe they are the future (and to me, it seems that they''re right).

- You don''t have to stick to one shadowing technique. Doom3 uses projected shadows for some stuff.

Muhammad Haggag

Share this post

Link to post
Share on other sites
here you are a comparison between the two different methods of shadows.
Shadow maps:
-they require rendering to texture (or surface as current ati drivers doesn''t support using a texture as depthstencil surface,but this driver specific not hardware specifice thing).rendering to a texture kills the performance unless you lock a big no of textures each frame not just a simple texture.
-they require reading z data from hardware.This is a very big bottle neck in the shadow mapping.using GetDepthStencilSurface()stops the parallelism between the gpu and the cpu.also this stops the fast z compression technique that each HIV uses, also stops the fast z reject technique used by the HIVs, so GetDepthStenciSurface() is a more significant bottle neck in the rendering. the solutin to this point is to use a softare occlusion and z buffering system as that used by Yann (the moderator fo of the graphics programming and theory forum) in his engine.this enabled him to use shadow maps in his engine without reading z data from hardware.
-they require precentage closer filtering to prevent aliased shadows.also you need bluering of shadow maps to make soft shadows.this may decrease the fill rate of the engine.
-they require multipass rendering from each light''s point of view.this may cause a burden on the gpu in transforming geometry of high poly count but this not a very big burden.

shadow volumes:
-they require a special geometry structure (each edge is shared by two faces only and the model should be closed).
-they cause a high cpu burden for extracting the silhoute edges and extruding the shadow volume.this burden can be decreased be updating the shadow volume once each two or four frames depending on your frame rate.I update it once each six frames in fast applications.
-they decrease the fill rate obviously and this point has no solution till now as far as I know.
- updating the geomety needs to copy it to a dynamic vertex buffer each time you update the shadow volume.this may take time in copying geometry in the vertex buffer.one solution for this was the extrusion of the shadow volume on the gpu using a vertex shader as in the sample of ati "Shadow Shader".but this will cause a burden on your gpu so if your gpu is free or you are not gpu bound you can use this method.if not then you can use the ordinary method.
-as coder said you can''t use it with geometry that has a lot of holes due to the fill rate that is needed with such geometry.
-soft shadows with shadow volume are still in research (as far as I know).the current methods get frame rates of 20 or 30 frames for simple scenes on a radeon 9700 .

actually using shadows using any technique is a heavy load on the engine.in doom carmak said that the shadow volume decreased the frame rate of the engine to the half.this is in a heavy engine that contins normal mapping, high poly count geometry ,realistic phisycs and animatons and a lot of good features.in other words using shadow volumes causes a load on the rendering pipeline equal to load caused by sum of all features mentioned before.
sorry if I spoke too much.

Share this post

Link to post
Share on other sites
Original post by mohamed adel
another note.this item should be posted in the graphics theory forum not here.

Yeah, that occurred to me too. But I thought that the choice of the API (DirectX) may affect the choice of the technique.
But maybe you''re right.

Muhammad Haggag

Share this post

Link to post
Share on other sites
Yup, I posted in the DX forum ''cause I''m using DX9. But yeah, guess the appropriate forum would be the Graphics Programming and Theory forum.

Anyway, thanks guys, I guess I''ll stick with shadow maps. I''ll just have to group my shadows into static and dynamic, so that I can render the dynamic ones every frame, and leave the static ones dormant after the first render.

Also, the scenegraph will remove any light not within the frustum, so that should help as well. After that, we''ll just have to wait for the R420 and NV41!

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!