Shadow Volumes

Started by
5 comments, last by hplus0603 18 years, 9 months ago
I tried using the important parts of the example from the SDK(Shadow Volume), but whenever I make a call to clear the stencil buffer I always get what was previously rendered from the last backbuffer. What could possibly be causing this?
Advertisement
here is how I call it:
d3dDevice->Clear( 0, NULL, D3DCLEAR_STENCIL,
0x00000000, 1.0f, 0 );
this would only clear the stencil part of the buffer. If you want to, you need to clear the z and color frames too.
Sirob Yes.» - status: Work-O-Rama.
I've tried that. I'll try to be more specific. When I make a standard call to clear the backbuffer, and z-buffer I get a black background. When I add to clear the stencil buffer I get a background that was what the previous backbuffer contained. It works like this for anything. I can run the demo on the SDK, quit at any given time, and start up my program and see the plane with its shadow volume on the screen along with the graphics I put in my program. It's too weird, and one of those unexplained mysteries to me.
I don't like to blow my own trumpet, but I wrote an article on shadow volumes for this site: An Example of Shadow Rendering in Direct3D 9 - you might find it as a useful reference if you haven't already seen it..

I suggest it as I tried to go into some detail on the various render states, and at its core its pretty similar to the SDK example code.

hth
Jack

<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ]</small>

Can you show the clear call you are using??
Steele.
There is a link to the source on that article; that should show you what to do to clear the scene.

Jack, great article by the way and congrats on the MVP awared. Did you by any chance write a similar article on using vertex shaders for the shadow volume. i have an implementation working of both CPU and GPU and while the GPU is faster it looses all its benefits for me when i try and incorporate vetex changing animation (such as skinning, or deforming my terain ;)) as the degenerative quads require updating independently of the other vertices, and then the normals need recalculating etc, making it much slower. I also read that CPU implementation scales better with large amounts of geometry due to the extra vertices pushed through the pipeline with vertex shaders; do you think this still holds true with the latest generation of GPUs?
Does the same thing happen when using the REF (software) device? REF isn't that slow if you create it with a resolution of like 80x60 or so.

If the same thing does not happen with REF, then you likely have run into a device driver bug for your particular hardware and driver version. Check the vendor site if there's an updated driver available -- or if downgrading the driver fixes the problem.
enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement