Volume shadows

the photo doesn''t load.there''s an error while opening the web page.any way try to change the z compare function from D3DCMP_LESSEQUAL to D3DCMP_LESS.the z bias doesn''t work with shadow volume.

Thanks a lot! That improves the situation a lot, but I still have some z-fighting...

Here''s another shot (this should work): http://nade.altervista.org/temp/shot2.jpg

nICO

you may change the values of the projection matrix to increase z precision.to make sure that the problem is with the z precision get the camera near the surface has artifacts and if the artifacts disapear you can be sure that it is z precision problem.

[edited by - mohamed adel on December 28, 2003 11:18:07 AM]

It doesn''t seem a z-precision problem... but pheraphs I found the solution.
I''m creating the shadow volume with a vertex shader and this seems to be the problem.
In fact if I render all the scene using vertex shaders I don''t have z-fighting problems. Instead, if I render only the shadows with vertex shaders I have this problem.
I should check if creating volumes and rendering without vertex shaders gives the same problem...

Thank you
nICO

Hi !

Yeah, I''ve got this problem some time ago - z-fighting when mixing fixed and programable pipelines. I didn''t find any reasonable solution that can overcome this problem :/ (Except of drawing everything using vertex shaders ).

PS: AFAIK there is an extension in OGL that some how helps with this, but I don''t know about anything similar for DX9.

Well the reason why this happens when doing different parts in different pipelines is because of different float precision. Since different parts do different floating point ops. Are you capping your volume? Since if you cap it and project into infinity you will have huge z-fighting problems!? Check out this paper for very efficient shadow volumes http://developer.nvidia.com/object/fast_shadow_volumes.html .
There shouldn''t be any difference between fixed function and vertex shader vertex processing on newer cards (GF3+, Radeon 8500+) unless you''re using software vertex processing ( but if you have vertex shader capable hardware why should you anyways?), or unless you''re doing your own z-filtering (which I believe it''s not the case here).
There are few things that could be causing this:
you clamp your values in the shader;
you use a bad projection matrix;
you''re doing extrusion separatelly from the shadow rendering pass.

Well, I''m using a very simple shader, I don''t think the problem resides there...

vs_1_1
dcl_position v0
dcl_normal v3
dp3 r0.x, v3, -c10
sub r1, v0, c16
slt r2.x, r0.x, c18.y
mul r2.x, r2.x, c18.x
mad r3, r2.x, r1, v0
m4x4 oPos, r3, c0

where c10 holds light dir, c16 light pos, c18.x the push distance of the volume (it''s not infinite) and c18.y simply holds 0.0f (used for comparison in the slt instruction).

Btw, what is the best mode to use volume shadows? I read about capping, using Carmack''s reverse and tons of other methods, but I don''t know which is better...

nICO

I also met the same problem for the same reason :differnce in precision.are you multiplying the world,view and projection matrix and then pass it to the vertex shader as a vertex shader constant (Iam guessing)?

carmak's reverse and the depth pass are the only two techniques for shadow volume.it is carmak's reverse that needs capping,infinite view volume and all these things,they aren't new or different tehniques but they are part of the carmak's reverse.

[edited by - mohamed adel on December 29, 2003 6:23:19 AM]

Yes, I pass the matrix to the shader as a constant.
Anyhow, I think I can solve the problem simply don''t mixing fixed & programmable pipelines...

Btw, pheraphs I didn''t understand Carmack''s reverse, but it doesn''t seems to me that capping is used in it.
Doesn''t Carmack''s algorithm simply inverts the stencil buffer operations?? (I mean incrementing the stencil buffer when the z-test fails for backward faces and decrement it when the z-test fails for front faces).

nICO

first: the problem is in the difference in precision between the matricies multiplied by the cpu (using the D3DX functions) and matricies multiplied with the gpu (in hardware TnL).pass the world ,view and projection matrecies to the vertex shader and let it multiply them with the vertex.mixing the programable and the fixed function pipe line isn''t the problem as the fixed function instructions are changed to vertex and pixel shaders in the driver for the modern cards.new ATI cards doesn''t contain fixed function pipeline in the card itself to save the no. of transistors and the cost.there''s a slight differnece in the z precision on between the fixed function pipeline and the programmable pipeline on my radeon 9700 pro BUT this is an EMPIRICAL notice and happens RARELY and I think it is driver dependant.

second: carmak''s reverse needs capping of the shadow volume or you will see artifacts.carmak''s reverse needs the shadow volume to be closed.also it needs extending the view frustum to infinity or projecting the back cap on the far clipping plane.you can see the article called "the theory of stencil shadow volume" on this site ,it is excellent.

Thank you. I''ll check it out!

nICO