Originally posted by cass:
[b]
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[/b]
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.
Originally posted by SirKnight:
[b]Oh ok, i never heard of slop before and i was like what the heck, sounds like something pigs eat. 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 , 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. I guess.
-SirKnight
[This message has been edited by SirKnight (edited 04-08-2002).][/b]
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).
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) .
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. I forgot there were 23 mantissia bits.
I think using 23 works nicely. And its safe!
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.
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.
I need to add code to walk through models and verify that it meets requirements for proper shadow volume generation.
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 ) 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).]
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.
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:
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).]
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?
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 . 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).]
