PDA

View Full Version : White/black mini-artifacts in shadowed/lit area (stencil; z-fail)?



B_old
04-07-2003, 09:01 AM
Hello.
I am messing around with stencil shadows.
For now I run z-fail only.
I am noticing white artifacts the size of a pixel appear in my shadowed area.
Where there is no shadow I sometimes get black jaggs or barbs (don't know how to describe).
Is this a known issue (what can I do about it)
Or is it me again being unable to do anything right?
Thanks for any help.

DopeFish
04-07-2003, 04:30 PM
What size depth buffer are you using?

rgpc
04-07-2003, 06:53 PM
Any chance of a screen shot?

If the problem looks like z-fighting then there's a few things that may cause the problem. Ones that spring to mind are...

1. depth buffer precision
2. floating point precision for rotations etc.
3. You are doing something wrong with your shadow volume rendering.

Item 2 put a number of jaggies into my display because I was converting from Quaternions to Axis Angle. The jaggies appeared because between the first pass (Ambient only) and the second pass (z-fail fully lit) the resulting rotation was not the same due to fpp.

This meant that the lit geomtery was actually placed slightly different to the ambient geometry & jaggies resulted.

One way to identify the problem to turn off the drawing of your shadow volumes to the stencil buffer (just comment or #if out the code). If you still the jaggies then your ambient and lit geometry are not position invariant (and you can discount 3 above).

You can then "eliminate" depth precision by ensuring you have the maximum depth precision available (24bit on nVidia [?] on ATI). If you are using an infinite far plane for your shadows, try turning it off and using NV_depth_clamp (on Vidia hardware) or just use the infinite frustum for your shadow volumes.

cbwan
04-08-2003, 02:09 AM
are you extruding all triangles in shadow or using the object silhouette to create your shadow volume?
cb

B_old
04-08-2003, 05:58 AM
Hello.
1. 16 or 24 Bit depht-buffer seem to make no difference.

2. Hmmm. I have a lot of passes. Where is a potential fpp-critical moment. As far as I can see I set me camera before any rendering and it stays the same for every pass. (I will try something out though)
(I totaly disabled the shadows and all cracks disappeared although I still need several passes for lighting. Is that what you mean?)

3. I extrude every triangle that is facing the light. (no silhouette)

4. I use an infinite view frustum. I don't think it is wrong as I see nothing if I use a normal frustum.

Thanks for the help!

skynet
04-08-2003, 06:11 AM
What gfx card do you have? I noticed strange artifacts on my GF2 after I enabled the scissor test for stencil shadows. I didnīt have those pixel errors on other gfx cards.
The artifacts do not look like zfighting (long streaks) but like regular patterns of mis-shadowed pixels. And they completely go away with disabled scissor test.

Proton
04-08-2003, 06:37 AM
I reccommend only rendering the silhouette of the shadowed object. The fewer polys rendered the lower the chance of artifacts, you could also get a speed increase.

Another problem could be percision when you are creating your extruded polygons. Try using a double instead of a float.

B_old
04-08-2003, 07:08 AM
I have a GF2. I don't do the scissor test, though. BTW, do I gain much from that test?

I'm going to try it with doubles.
I would only render the silhouette if I knew what it looks like http://www.opengl.org/discussion_boards/ubb/smile.gif

Thanks!

[EDIT]
I believe the dots on the shadow appear where the volumes of different triangles join. So only extruding the silhouette would probably give better results but they shouldn't appear in the first place http://www.opengl.org/discussion_boards/ubb/frown.gif

[This message has been edited by B_old (edited 04-09-2003).]

rgpc
04-08-2003, 06:19 PM
It's kind of hard to say but it sound like you might be rendering geomtry which is not closed and you are seeing the cracks between the adjacent triangles? (ie. you see it in areas where the adjacent triangles do not actually share vertices - the vertices are duplicated)?

Another cause I can think of is if you have GL_POLYGON_SMOOTH enabled? (I think that's right - I seem to remember Polygon Smoothing can cause artifacts between the triangles under certain conditions).

B_old
04-09-2003, 04:25 AM
What do you mean by 'geometry that is not closed'?
Suppose I have a closed cube. I would only render the faces that face the light. Then it is not closed any more. Is that what you mean?

Never enabled smooth polygons.

Thanks for the help!

Proton
04-09-2003, 06:18 AM
Suppose I have a closed cube.

I believe that statement is what rgpc is suspiscious of. If you are using a cube, this is not likely a problem. A cube should only have 8 vertices in total, and the triangles should reference only those 8. If the triangles each have their own vertices then this could cause small cracks or small overlapping in the model itself if the verticies have slightly different position values. This would be a cause for your problem.

But this problem would likely appear with a more complicated mesh.

147-2
04-09-2003, 07:20 AM
I had exactly the same problem, it is depth fighting, and it can be cured with glPolygonOffset() I used negative numbers, I think -.05 or something for both args, and it worked nicely. This function is talked about very briefly in OpenGL Programmer's Manual.



[This message has been edited by 147-2 (edited 04-09-2003).]

B_old
04-09-2003, 11:35 AM
Well, In fact I don't have a cube http://www.opengl.org/discussion_boards/ubb/smile.gif
I just wanted to clarify my point.
I render the faces that the Radiant for Q3 compiled.

glPolygonOffset, worth a try I guess.
Do you set it once or every frame or every pass? What does it do?

Thanks for the help!

EDIT:
I have no some code that is supposed to decide wether z-fail or z-pass is the appropriate algo to run (works only when shadow caster is in front of me http://www.opengl.org/discussion_boards/ubb/frown.gif ).
When I turn the feature on/off I can see that the shape of the cracks change but they still remain. Just wanted to mention it.

[This message has been edited by B_old (edited 04-09-2003).]

rgpc
04-09-2003, 07:47 PM
Cube or not the principles for closed geometry are all the same. "Closed" geometry (in the traditional sense...) is geometry where all edges have two triangles on them.

With the cube example given above a closed cube will only have 8 vertices and 12 triangles with 18 edges. If you have any more than that then your geometry is not considered to be closed.

A reason a cube may not be closed is that you may have 6 textures for each of the six sides and the texture coords may vary in such a way that you can't share the vertices between one side and it's adjacent side.

All of the above can apply to ANY geometry (Cube, sphere, Laracroft.md2 etc.).
--------------------------------------------

Now, ignoring the above http://www.opengl.org/discussion_boards/ubb/wink.gif there is one other possibility which is the result of your infinite frustum. It is possible that you are getting "t-junctions" forming "at" infinity due to the use of w=0 when you extrude your geometry for the shadow volume.

Let me just clarify this statement by saying that I have no idea what "t-junctions" means but I have seen cass everitt mention it in another post on this board shortly after he released the doco on "know your w coord".

Can I suggest you try the NV_depth_clamp extension as a quick test to see if the "t-junctions" is causing your problem?

-----------------------------------
Edit I think I've counted the edges on a cube correctly this time... http://www.opengl.org/discussion_boards/ubb/wink.gif

[This message has been edited by rgpc (edited 04-09-2003).]

stefan
04-09-2003, 10:16 PM
@147-2: Using a factor!=0 in glPolygonOffset might open your shadow volume. In my opinion it's better to specify only the units parameter (i.e. the offset).
(Since the z-value for each pixel depends on the triangle's delta z and the polygon offset factor, you probably get different z-values for the edges of your shadow volume, which can then have an impact on the stencil test. This does not happen if the constant "unit" value is added to the z-value.)

B_old
04-10-2003, 08:38 AM
I don't think my card supports depth-clamp (GF2).

Hmm, where can I learn about the offset-thing. I have no idea how to use it.

Thanks.

147-2
04-11-2003, 07:08 AM
I set the polygon offset to -0.05 (for both values) when I am drawing geometry, and set both values to 0 for drawing shadows. I can't see why I have to do this from reading the documentation of the function, but for some odd reason it didn't seem to work unless I did this.

As far as opening the shadow volume, yes, I know. There is a tad bit of stitching evident with -0.1, but I haven't noticed any with it set as low as -0.05. That's why you gotta bat for as low of a value as you can without depth artifacts. It's a trade-off, you either get depth artifacts, or a touch of "shadow seam stitching" which is almost not noticeable.

[This message has been edited by 147-2 (edited 04-11-2003).]

B_old
04-13-2003, 08:46 AM
Originally posted by 147-2:
I set the polygon offset to -0.05 (for both values) when I am drawing geometry, and set both values to 0 for drawing shadows.
Hi. I don't really understand what you mean by drawing the shadows.
Do you mean -0.05 for ambient/depht and 0 for lighting?
Thanks for the help!

rgpc
04-14-2003, 03:52 AM
147-2 means when drawing the shadow volume.

B_old
04-14-2003, 08:24 AM
Ah, thanks!

I believe the black dots in lit areas are gone, at least I couldn't find them anymore in a short test. Lets hope for the best.
The white seems inside the shadows remain.
I am confident though that some of them will vanish as soon as I have grown smart enough to only draw the silhouette volume.