Scissor destroys z-buffer?

I’m doing stencil-shadows+bumpmapping, and I use scissoring to speed things up.
I’m doing about 5 passes with the same geometry. (same = identical vetices different texture coordinates)
My problem is that when I enable the scissor testing I get small z artefacts. (Looks like z buffer fighting, wich it probably is ) without scissoring I don’t have any artefacts. (Scissoring with a rectangle the size of the whole screen also works)
Is this normal?

That really shouldn’t happen unless you enable/disable it between passes. If you’re rendering a z only pass, make sure you use scissoring for that too.

Enabling scissor when I draw my depth pass doesn’t make any difference.
Btw is there a list of gl calls you can/can’t do to keep your z-values the same. (Beside obvious things as rendering exactly the same polygons,… . I never taught Scissor may have had an effect)

In the GL spec - Appendix A. You’ll notice that even changing blending does not guarantee invariance ( but usually it works, most drivers seems to be invariant with respect to the strongly suggested states ).

What hardware are you using ?

Originally posted by Pentagram:
My problem is that when I enable the scissor testing I get small z artefacts. (Looks like z buffer fighting, wich it probably is ) without scissoring I don’t have any artefacts. (Scissoring with a rectangle the size of the whole screen also works)
Is this normal?

The graphics board is probably doing scissoring at geometry level, instead of at rasterisation level, that means that it’s clipping the coordinates when you activate scissoring and then rasterising the clipped geometry.
Invariance is explicitly not required when geometry is clipped.

Try using polygonoffset to reduce the z-fighting.

On page 220 of the gl spec (Rule-2 dot 4) it says “Scissor parameters other than enbable” so by leaving it enabled it “should” work.

  • Strange -

But stencil parameters is not in the required list. (So you can never be sure that any given card will do stencil shadows correclty if i’m right)

My hardware is a Gf2-MX with the latest drivers. (29.42)

Originally posted by Pentagram:
But stencil parameters is not in the required list. (So you can never be sure that any given card will do stencil shadows correclty if i’m right)

Exactly, and Quake3 wouldn’t work. I think it’s safe to assume that these operations will work on even pretty old hardware. The one thing that almost certainly creates z-buffer artifacts are user clip planes.

I think that most drivers implement scissoring by actually clipping the geometry. However, this really shouldn’t affect the z coordinates. Have you resolved it by the way ?

You are not using ( emulated ) vertex programs are you ?

To me this sounds like something with using emulated vertex programs, since its being done on the cpu, it does things differently than the gpu which could cause a problem like this. If your not using vertex programs then just ignore this.

-SirKnight

No, I don’t believe that the nvidia cards clip the geometry - I believe they clip during triangle rasterisation. The reason I believe this is because you don’t see any colour interpolation artifacts on a clipped triangle, which you would if the normal (of the vertex created at the clip edge) was an interpolated normal. Interpolated normal would give a different colour value than an interpolated colour.

Originally posted by SirKnight:
[b]To me this sounds like something with using emulated vertex programs, since its being done on the cpu, it does things differently than the gpu which could cause a problem like this. If your not using vertex programs then just ignore this.

-SirKnight[/b]

Then he’d get artifacts whether the scissor test was enabled, or not, wouldn’t he?

Originally posted by knackered:
No, I don’t believe that the nvidia cards clip the geometry - I believe they clip during triangle rasterisation. The reason I believe this is because you don’t see any colour interpolation artifacts on a clipped triangle, which you would if the normal (of the vertex created at the clip edge) was an interpolated normal. Interpolated normal would give a different colour value than an interpolated colour.

Yes. With clipping I meant as opposed to doing some sort of fragment culling ( similar to implementing clip planes using textures ).

I’m not using any emulated vertex programs.
It is actually a rare artefact (the level that I was testing it on had it a lot but it’s not that everything is flickering all the time)
The only way I can resolve it is by disabling scissoring. (I left it enabled anyway since I can save a lot of clears this way.) So It is not really solved but I guess (hope?) it is the driver/card combination that is the problem.
On the implementation of it I always tought it was done at the scanline level but I’m not sure if this is even possible.

You’re clearing the scissor region?
I believe that it’s quicker to clear the whole viewport than a specific region.

Yes I’m clearing only part(s) of the stencil buffer evey light(s).
Acually I use some dirty rectangle system that draws lights in an order that requires less clears. If it has to be cleared I only clear the ‘dirty’ part.

I think the issue was glClear vs. drawing a polygon to clear a region. I’m pretty sure using scissoring with glClear would be the fastest.