PDA

View Full Version : Clipping issue using 'infinite' P matrix ( Radeon 8500 )



PH
04-07-2002, 08:39 AM
I've noticed what might be a clipping bug on Radeon 8500. I'm using the 6043 drivers on Win2000 ( the only drivers that work with Tomohide's fur demo ).
The clipping "bug" appears when using the Pinf matrix as descriped in this paper (http://developer.nvidia.com/view.asp?IO=robust_shadow_volumes) .

NVIDIA's new infinite shadows demo demonstrates the bug ( the code needs to be modified so that polygon offset is not used ).

Has anyone with Radeons noticed this ? Humus ?

cass
04-07-2002, 09:02 AM
PH,

Can you post an image of the possible bug?

Thanks -
Cass

Humus
04-07-2002, 09:03 AM
I haven't checked the demo out too deeply, but I did notice some artefacting in it.

The model seams kinda broken, shadows worked just fine mainly, except for some small occasional glitches (http://esprit.campus.luth.se/~humus/temp/bug.jpg) .

PH
04-07-2002, 09:12 AM
Exactly like that. Yes, those are caused by the Pinf matrix on Radeon 8500 hardware ( not just this demo ). The artifacts on the model are caused by using polygon offset, here my shot of it,
http://www.geocities.com/SiliconValley/Pines/8553/Pinf.html

SirKnight
04-07-2002, 05:20 PM
I've also noticed some of these problems actually on the model, like at one angle it would be fine, but rotate the model a bit and all of a sudden, one or a few polys would all of a sudden go black from the shadow. Maybe this wouldnt happen if the model had more polys, it is pretty low poly.

-SirKnight

[This message has been edited by SirKnight (edited 04-07-2002).]

PH
04-08-2002, 05:59 AM
I did a few more tests and it seems that the possible clipping bug, is caused by using vertices with W = 0 ( and not neccessarily the Pinf matrix ).

cass
04-08-2002, 06:22 AM
One thing to try. There's a slop factor I use to nudge infinity slightly less than 1.0. Here's the code in infinite_frustum():



// nudge infinity in just slightly for lsb slop
float nudge = 1 - 1.0 / (1<<23);

m(2,2) = -1 * nudge;
m(2,3) = -2*zNear * nudge;


You might try setting nudge = 0.9 to see if it's some sort of LSB issue with the clipper.

Also, polygon offset shouldn't be causing any problems since it's only used when drawing the model (and not the shadow volume).

Thanks -
Cass



[This message has been edited by cass (edited 04-08-2002).]

PH
04-08-2002, 07:00 AM
Cass,

Well, I removed the nugde altogether http://www.opengl.org/discussion_boards/ubb/smile.gif and it works now ( I tried 0.9 but that failed too ). The strange thing is, I ran the wireframe test I posted a screenshot of some time ago ( regarding the scissor box ) and I noticed the lines jumping around ( it didn't do that on my GeForce3 ). That combined with your shadow demo made me thing it was a possible bug.

Interestingly, there are now some artifacts on GeForce DDR ( without the nudge ). Is this the case with GeForce3 too ? Not a big problem since we'll "soon" have NV_depth_clamp or similar.

Last thing, is the technique still robust ?

Paul


[This message has been edited by PH (edited 04-08-2002).]

cass
04-08-2002, 07:49 AM
Paul,

It's odd that taking the nudge out makes it work for Radeon. Its purpose is to allow some margin for numerical error in the computation. The fact that you can have a "fudge factor" is one thing that makes the technique robust (the other is depth clamp).
Otherwise infinity is really on the razor's edge of what should be clipped.

The reason the fudge factor is in there is that GeForce4 Ti required it. GeForce3 did not (in any of my testing).

Thanks -
Cass

PH
04-08-2002, 08:04 AM
Cass,

Instead of using the nugde, would it be possible to use a ledge at the far plane ? Like the one described by Mark Kilgard for the near plane and still use the ordinary Pinf matrix. I haven't given it a lot of thought, so I may be wrong ( I have previously used Kilgards near plane ledge which seemed to work fine ).

opla
04-08-2002, 08:12 AM
How did you manage to download the demo from http://developer.nvidia.com/view.asp?IO=inf_shadow_volumes ?

The server is always busy(I tried from home and from work)

can somebody post the demo and the src, please ?

cass
04-08-2002, 08:18 AM
Paul,

You really don't need a special ledge when capping at infinity with the zfail approach.

The ledge is useful when you have to introduce capping geometry in object space and you need some room (both in front and behind it) to make sure it doesn't get clipped. Nudging infinity in essentially does the same thing for the infinite zfail approach. You just want to make sure things that shouldn't be clipped aren't.

Thanks -
Cass

PH
04-08-2002, 08:49 AM
Cass,

So the nudge and the ledge would accomplish the same thing ?

And I got the nudge to work on Radeon 8500 by using 0.9 and 0.995. I'm not sure what I did wrong the first time. Strange that it's required on GF4Ti/GeForce DDR and not GeForce3 / Radeon 8500...

Paul

SirKnight
04-08-2002, 09:42 AM
Sorry but what the hell is slop? Also i guess there is something about clipping i didnt know about cuz all of this talk about nudge is kinda confusing me. Im not sure why this nudge thing is needed. For one thing its not mentioned in the paper.


-SirKnight

PH
04-08-2002, 10:33 AM
SirKnight,

You know about epsilon values, right ? Such as Abs(A-B) <= Epsilon. This says that A and B may differ by a small +/- Epsilon value and be considered equal.

Slop is almost the same - it's just one-sided.

I'm not sure why it wasn't mentioned in the paper - maybe it's another technical point ( something similar to rendering the caps twice ).

Paul

SirKnight
04-08-2002, 11:21 AM
Oh ok, i never heard of slop before and i was like what the heck, sounds like something pigs eat. http://www.opengl.org/discussion_boards/ubb/wink.gif What im wondering now, is why was the nudge computed like that. I know what 1<<23 does but why is it being done like this? If you want to nudge -1 to, well be sloppy i guess http://www.opengl.org/discussion_boards/ubb/wink.gif, then why go through the trouble of computing that and just multiply by some value that will make it close to -1 but not exact, so that way it will be nice and sloppy. http://www.opengl.org/discussion_boards/ubb/smile.gif I guess.

-SirKnight

[This message has been edited by SirKnight (edited 04-08-2002).]

Elixer
04-08-2002, 11:39 AM
Originally posted by opla:
How did you manage to download the demo from http://developer.nvidia.com/view.asp?IO=inf_shadow_volumes ?

The server is always busy(I tried from home and from work)

can somebody post the demo and the src, please ?

Yeah, I tried for the last 4 days, and I tried very late, very early, early, and basically left a download manager try to get it, and no matter what, the server was always busy. So your not alone in this. http://www.opengl.org/discussion_boards/ubb/frown.gif

PH
04-08-2002, 11:43 AM
Opla & Elixer,

Cass mirrored the files on his personal server, look in this thread,
http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/006086.html

Both links work ( just tried them ).

SirKnight
04-08-2002, 12:42 PM
Ok nm about my last question in my last post, i pluged all that into my calc and i see it gets a number thats very close to 1, its like .99999999blahbalh which makes sence.

-SirKnight

cass
04-08-2002, 02:20 PM
Just to clarify, there may be a more formal definition of "slop" that I'm not aware of. My usage of the term is just "some error" - either positive or negative.

Thanks -
Cass

Elixer
04-08-2002, 03:22 PM
Originally posted by cass:

Just to clarify, there may be a more formal definition of "slop" that I'm not aware of. My usage of the term is just "some error" - either positive or negative.

Thanks -
Cass

slop Pronunciation Key (slp)
n.
1 Spilled or splashed liquid.
2 Soft mud or slush.
3 Unappetizing watery food or soup.
4 Waste food used to feed pigs or other animals; swill. Often used in the plural.
5 Mash remaining after alcohol distillation. Often used in the plural.
6 Human excrement. Often used in the plural.
7 Repulsively effusive writing or speech; drivel.

Take your pick Cass http://www.opengl.org/discussion_boards/ubb/smile.gif

zeckensack
04-08-2002, 04:10 PM
Originally posted by SirKnight:
Oh ok, i never heard of slop before and i was like what the heck, sounds like something pigs eat. http://www.opengl.org/discussion_boards/ubb/wink.gif What im wondering now, is why was the nudge computed like that. I know what 1<<23 does but why is it being done like this? If you want to nudge -1 to, well be sloppy i guess http://www.opengl.org/discussion_boards/ubb/wink.gif, then why go through the trouble of computing that and just multiply by some value that will make it close to -1 but not exact, so that way it will be nice and sloppy. http://www.opengl.org/discussion_boards/ubb/smile.gif I guess.

-SirKnight

[This message has been edited by SirKnight (edited 04-08-2002).]

1-1/(1<<23) is exactly the largest number smaller than one that can be represented in 32bit floating point (at least in the ubiquitous IEEE 754 standard format).

cass
04-08-2002, 04:20 PM
Elixer,

I choose (1), but replace "liquid" with "bits". http://www.opengl.org/discussion_boards/ubb/smile.gif


Zeckensack,

I think (but I could be wrong) that 1-(1.0/(1<<24)) is the largest number less than 1.0 that can be expressed in 32-bit IEEE. There are 23 mantissa bits, but there's an implicit MSB.

I chose a shift of 23 just to be safe (my own additional slop) http://www.opengl.org/discussion_boards/ubb/smile.gif .

Thanks -
Cass

SirKnight
04-08-2002, 04:56 PM
Ah, (1<<23) was used b/c there are 23 mantissa bits. Now this makes even more sence than it did a few min ago. http://www.opengl.org/discussion_boards/ubb/smile.gif I forgot there were 23 mantissia bits. http://www.opengl.org/discussion_boards/ubb/wink.gif

I think using 23 works nicely. And its safe! http://www.opengl.org/discussion_boards/ubb/smile.gif

But it just kinda confuses me that this would be needed. I mean the far plane is effectivly at infinity so i dont understand why nudging it would be needed.

Im still kinda wondering why the problems bugs we see with the shadow demo has to do with clipping. To me it doesnt seem like it. Why would you guys say that its a clipping problem? I would have thought it was a problem with generating the actual volume from the occluder model gone bad. http://www.opengl.org/discussion_boards/ubb/smile.gif

-SirKnight

cass
04-08-2002, 06:05 PM
SirKnight,

In a symbolic math world, you wouldn't need this nudge. In the real world, the Pinf matrix produces geometry that is *exactly on* the far plane. If you consider all the math that's actually going on (or could be going on in a given hardware implementation) it's not that difficult to encounter situations where you're just one LSB of error produces artifacts.

You're right that it's not always obvious what the problem is. One important thing is to test on a model known to work, which is the case with the Knight model. http://www.opengl.org/discussion_boards/ubb/smile.gif

I need to add code to walk through models and verify that it meets requirements for proper shadow volume generation.

Thanks -
Cass

SirKnight
04-08-2002, 06:35 PM
Ok thanks for your reply Cass, i was just thinking in the symbolic math world and i was like, what is up with this. But ya since it produces geometry on the far plane like you say, then i can see how something that can seem insignificant like one LSB can cause a problem. Thats what sucks about a razor's edge, one very little thing can cause a problem.

One thing about the knight model (which is pretty cool btw http://www.opengl.org/discussion_boards/ubb/wink.gif) is that like i mentioned somewhere beore is if you have the model in one position its ok, then change the angle by a small amount and all of a sudden a triangle or two (or more) all of a sudden goes all black. It looks kinda wierd. Maybe higher tesselation would help? The part i notice it the most on the knight model is on by the face on his helm. It is a flat part on his helm that touches his face that i noticed this at first. I hope you can figure out what im talking about just from what im saying, maybe mess around with it and see if you can see what im talking about. If need be ill post two images of a before and after.


-SirKnight

[This message has been edited by SirKnight (edited 04-08-2002).]

davepermen
04-08-2002, 10:26 PM
i replied to this problem in the other thread about the infinite p matrix shadow volume demo (post from cass)

cass
04-09-2002, 03:42 PM
Ugh. I found a stupid bug in this code that makes the whole nudge thing on GeForce4 Ti unnecessary.

I'll make a note of it when I post the fix.

Cass

SirKnight
04-09-2002, 06:32 PM
Cool, im looking forward to see what the problem was. http://www.opengl.org/discussion_boards/ubb/smile.gif But what about the other cards? Is it still necessary on geforce cards under the 4 Ti?

-SirKnight

cass
04-09-2002, 07:22 PM
SirKnight,

Trust me, it's just a dumb error. It didin't affect the correctness of the shadows, only my rendering of the shadow volumes at infinity (glDepthFunc(GL_LESS) should have been glDepthFunc(GL_LEQUAL)). I also had an error in the specification of the light position. http://www.opengl.org/discussion_boards/ubb/frown.gif

Here's the corrected cpp file. I'll put it in an updated zip on the web site soon.
http://www.r3.nu/~cass/nv/infinite_shadow_volumes.cpp

Thanks -
Cass

evanGLizr
04-10-2002, 02:57 AM
Originally posted by cass:

Here's the corrected cpp file. I'll put it in an updated zip on the web site soon.
http://www.r3.nu/~cass/nv/infinite_shadow_volumes.cpp

Thanks -
Cass

There's also a bug that makes texturing state incomplete, so textures don't get rendered on cards that honor the texture state completeness and don't support GL_GENERATE_MIPMAP_SGIS, the line:

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);

should use GL_LINEAR or GL_NEAREST, as you don't download levels of detail for the checkerboard texture of the room:

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, 32, 32, 0, GL_LUMINANCE, GL_FLOAT, tex);

I guess that there should be some check somewhere to see if the card/driver supports generating mipmaps.

[This message has been edited by evanGLizr (edited 04-10-2002).]

davepermen
04-10-2002, 04:04 AM
sure, just check for GL_SGIS(od X)_generate_mipmaps http://www.opengl.org/discussion_boards/ubb/wink.gif (more or less that name)

SnowKrash
04-12-2002, 07:13 AM
I didn't have any visible problems with my own code and a Geforce 3, but some clipping of the infinite capping faces occurred with a Geforce 1 and 2 (MX).

UPDATE: I went back and checked the volumes again and there was some drop-out with the GF3 but it wasn't leading to any obvious visible artefacts with the actual shadows.

Neither the above nudge trick nor using GL_LEQUAL (or combination) for these faces prevented the GF1/2 clipping. The only reliable solution I've found so far is to use glPolyOffset on everything.

Also with regards the paper, I haven't found glStencilOp( GL_KEEP, GL_KEEP, GL_INCR ) to work (fix for double blending) either with my own code or the example. I lack experience with stencil operations so it's not immediately obvious as to why that leaves everything effectively in shadow.


[This message has been edited by SnowKrash (edited 04-12-2002).]

cass
04-15-2002, 11:05 AM
SnowKrash,

Are you saying that some clipping of the infinite faces (drawn to stencil) was occuring on GeForce(1 & 2)? If the shadows don't have artifacts, then I would expect that the shadow volumes are not being clipped at infinity.

I'm not sure what you're referring to regarding the glStencilOp() call. Does my demo program not work on your configuration?

Thanks -
Cass

SnowKrash
04-15-2002, 12:35 PM
I have just now taken another look at my code and discovered a stupid error, although it doesn't address everything.

The bug was that I'd accidently nudged both -1 entries in the projection matrix due to compact code http://www.opengl.org/discussion_boards/ubb/wink.gif. Reassuringly the nudge (1.0f - 1.0f / (1 << 23)) prevents clipping of the infinite faces on the GF1 - as I had believed it would at the time. One would expect this to be true of the GF2 as well, although I haven't checked as yet.

This doesn't change the fact that using a GL_LEQUAL depth test instead for these faces is not enough to prevent all unwanted clipping on the above cards. From displaying the volumes and toggling the depth test changes I can see that some faces are saved but not all.

To be absolutely clear on the GF3 front, with GL_LESS depth testing for those faces and no nudging I don't get any apparent shadow artefacts, although I can see from the volumes that some far clipping (fully prevented with GL_LEQUAL) is happening. That is somewhat odd.

Cass:
That glStencilOp(..) call is the one in 7.E of the code listing in the paper and discussed afterwards in the following section (page 6).

I haven't tried your test app with the older cards yet - all of the above findings are from my own code which I'm confident is now fixed. *secretly crosses fingers*


[This message has been edited by SnowKrash (edited 04-15-2002).]