PDA

View Full Version : popping artifacts with shadow volumes and smooth shading



cass
09-21-2002, 11:18 AM
If you've ever been irritated with shadow volumes when you see polygons "pop" into
and out of shadow, and the ugly interaction it has with smooth shaded surfaces, here's an approach you may want to take a look at.
http://www.r3.nu/~cass/shadow_volumes/

It includes some images, an email thread discussing the solution, and updated source code for the infinite_shadow_volumes demo.

I'd be interested to hear if others have success with this approach.

Thanks -
Cass

PH
09-21-2002, 11:46 AM
I can't seem to find the timer.h file, is it in one of the SDK's ? Can you provide a binary ( or the timer.h file ) ?
I did some tricks with the silhouette in the past but it didn't work when a model cast a shadow onto its silhouette boundary. That will be the first thing I check with your demo http://www.opengl.org/discussion_boards/ubb/smile.gif.

cass
09-21-2002, 12:00 PM
You can get it from
http://cvs1.nvidia.com/OpenGL/src/demos/infinite_shadow_volumes/

I'll be interested to hear your results. http://www.opengl.org/discussion_boards/ubb/smile.gif

Thanks,
Cass

NitroGL
09-21-2002, 12:30 PM
Originally posted by cass:

If you've ever been irritated with shadow volumes when you see polygons "pop" into
and out of shadow, and the ugly interaction it has with smooth shaded surfaces, here's an approach you may want to take a look at.
http://www.r3.nu/~cass/shadow_volumes/

It includes some images, an email thread discussing the solution, and updated source code for the infinite_shadow_volumes demo.

I'd be interested to hear if others have success with this approach.

Thanks -
Cass

Unfortuantly I haven't had any success with the infinite_shadow_volumes code at all. Maybe it's just my 3D model data (just 3DS models), but I haven't been able to get the winged edge, or anything else to work.

Oh well.

Lars
09-21-2002, 12:56 PM
I thought about your algorithm, but discarded to use it (atleast at the moment).
The problem is u need to check each polygon if it is facing the light each time u render the mesh (atleast everytime the relation betweeen mesh and light changes which is each frame for me).

I will just think a bit more about it, but i don't see a fast solution for that.

At the moment i am not selfshadowing objects that have problems with that (like planets) on other objects, i can just hope that it isn't that recognizable.

By the way is that also noticeable with shadowmaps ?
I only have a geforce2go and 2mx at home so no chance to check this now...


Lars

PH
09-21-2002, 01:06 PM
Cass, one word...absolutely brilliant ( ok, two words http://www.opengl.org/discussion_boards/ubb/smile.gif ). I hacked it into my engine ( using glVertex/attrib calls ) and it works. I'll have to think about why it works ( I just looked at the comments in the code ).
From initial tests, I see absolutely no problems with this method. It works on completely general scenes.

zed
09-21-2002, 01:26 PM
Originally posted by Lars:
I thought about your algorithm, but discarded to use it (atleast at the moment).
The problem is u need to check each polygon if it is facing the light each time u render the mesh (atleast everytime the relation betweeen mesh and light changes which is each frame for me).

I will just think a bit more about it, but i don't see a fast solution for that.
Lars

this is just a simple dotproduct per triangle, very quick, most engines done this before hardware t+l came in + doing your own backface culling wasnt such a plus.

btw very nice cass, as i wrote on these forums before the 'popping' effect was disgusting glad to see its been solved (havent looked at the paper though)

SirKnight
09-21-2002, 01:46 PM
Yay! Just when I get my inf shadow volume prog working correctly a solution to the 'popping' comes out. Cool! http://www.opengl.org/discussion_boards/ubb/biggrin.gif

Now all I need to do is make shadows cast from something more complex than a cube. http://www.opengl.org/discussion_boards/ubb/wink.gif

-SirKnight

Lars
09-21-2002, 02:06 PM
I dont say that this is useless, it is an extrem cool extension to the standard algorithm. But it slows things down a bit.

I need to build two new indexlists for each instance of an object i draw and that for each light that affects the object.

But i am still thinking about it...
And maybe i can put it into the calculations that do the bumpmapping. If i do them outside a vertex program i could sort out the polygons where we have vertices that point away and towards the light. And after that rendering just those polygons with the changed stencil function. This would involve a second render call, but their would only be some polygons to draw...
Maybe i will do this, but i have to go away from the vertex programs...poor >gf2 users.

Lars

[This message has been edited by Lars (edited 09-21-2002).]

zeroprey
09-21-2002, 02:57 PM
Cass,

We emailed back and forth when this was posted on the gdalgorithms list a few weeks ago. At the time you didn't believe me when I told you this produced artifacts. Now I can show you what I'm talking about. The problem comes from concave areas. The shadow ends up getting cut off at the beginning so it looks like itís coming from nowhere. For instance turn the model a little and look at his helmet. You can see there's a shadowed triangle on his right side of his helmet. This seems to pop in when you turn him. In my tests with a model that was tessellated more than this one I had more than a just a few occurrences. It might not be as jarring as the popping but imho if it produces errors its worse. I just went back to the inset method because it ended up really causing problems.

Brian

cass
09-21-2002, 03:30 PM
Hi Brian,

I still contend that this approach behaves properly for situations where smooth shading behaves properly. That is, if your shading normals are "bad" and produce a fully lit triangle that is backfacing the light, then it's going to look wrong -- but that's bad shading anyway.

The point is that smooth shading with shadow can produce shading errors either way. There is no "correct" here, as far as I can tell because one method is using interpolated vertex shading and shadowing is done at polygon edges.

I really would like to see an example where this approach fails on a well-tessellated piece of geometry with good smooth normals.

The knight is so geometrically undersampled, that it's hardly a good case. That's what you get with programmer art, though. http://www.opengl.org/discussion_boards/ubb/smile.gif Lucky it wasn't a teapot, though at least the tessellation would have been better. :P

Thanks -
Cass

PH
09-21-2002, 05:47 PM
I tried to recreate the problem that Brian mentioned.

Here's a shot ( yes, same old textures and lousy map http://www.opengl.org/discussion_boards/ubb/smile.gif ), http://www.geocities.com/SiliconValley/Pines/8553/ShadowTest.html )

The green lines are the normals. The problems occurs in the V-shaped area. It's basically a deformed patch.

Edit:
It doesn't occur in all concave areas, only something exaggerated like the V-shape.


[This message has been edited by PH (edited 09-21-2002).]

Mazer
09-21-2002, 06:19 PM
Hi cass, i came up with this method with brian and we tried this approach a while ago. if i understand what you did right you cause poly's to not shadow themselves. if another poly casts a shadow it will show up, but polys simply facing away from the light dont shadow.

this should work in theory, but when you have and s curve like the one shown in the post above you run into problems. the polys are rotating tward the light enough so that some of the bumps are lit, but the actuall poly is still not facing the light. this would be fixed with the normals of the bumpmap being close to what the poly normal is, but that sorta ruins the whole concept of bumpmaps.

PH
09-21-2002, 06:39 PM
I do think Cass is right, the problem is due to bad shading ( the normals in the V-shape are really wrong ). Creating a sharp edge in that case would solve the problem ( since it is in fact not a smooth area ). Whether it's easy to fix these issues automatically, is something else.

[This message has been edited by PH (edited 09-21-2002).]

Mazer
09-21-2002, 06:51 PM
in that case a sharp edge would fix it, but think about a curved surface with the same v type shape, for example clevage. There will always be the problem of non light-facing polys getting a little light because of their bump maps or smooth shading.

these aren't a problem when the surface is going from shade to light, where popping usually occurs, but with this method you get this between a bunch of fully shaded objects so it really sticks out and pops in that place instead. just moving the popping to a new position, not really a fix

it is very important that our clevage looks good, we need to find a better fix.


[This message has been edited by Mazer (edited 09-21-2002).]

zeroprey
09-21-2002, 06:52 PM
Here's my best attempt to explain it. Any back facing triangles shadow gets canceled out. The problem comes when you have the triangle back facing the light yet its edge further from the light has normals facing the light. This doesnít only happen in exaggerated V shapes or even only in S curves. Its not all concave areas but those are where the problem happens. It has to be concave to have a non-silhouette edge of a back facing poly to have normals facing the light.

Its really a geometric problem not a problem with tessellation. More polys will help but it can still happen. Its just less likely. it should really be on all concave areas I think just you see it when its enough to come past enough of the self shadowing.

I think to fully get rid of it you'd need more tris than youíd really want to use. I think robustness is more important than fixing most cases.

Thatís my best attempt. I really canít do better without drawing it. I could also post a shot but I have no web page.

Brian

PH
09-21-2002, 07:01 PM
Brian, I think you might be right ( unfortunately http://www.opengl.org/discussion_boards/ubb/smile.gif ).

cass
09-21-2002, 07:03 PM
Brian,

I'd be happy to post a shot or drawing on my web site illustrating the problem if you want to email it to me.

Thanks -
Cass

vshader
09-21-2002, 07:26 PM
it should be possible to preprocess meshes to identify trouble spots like that and just duplicate the vertex normals (like you would to avoid tangent-space basis degeneracy).

anyone see a problem with that? in the picture posted you would just change that edge to separate verts with different normals to make a crease. the bump-maps can still make the lighting look smooth when it's not in shadow, because the tangent-space basis does not have to be oriented the same as the vertex normals use for self-shadowing. or if you use object-space bumpmaps - no problems.

and the shadows will be correct as long as you use the unperturbed normal self-shadowing trick. (modulate bump map result by interpolated vertex normal dot light) it would avoid the problem posted in the picture, wouldn't it?



[This message has been edited by vshader (edited 09-21-2002).]

cass
09-21-2002, 08:05 PM
Ok, I see at least one of the issues now.

It occurs at the edge between triangles in a concave region where there is a back facing triangle with a shading normal that faces toward the light.

I agree this does complicate things. Good call, Brian. Thanks for hanging in there with me. http://www.opengl.org/discussion_boards/ubb/smile.gif I'm pretty sure you can identify these cases too (at some extra cost), and keep them from being lit, but let me think about it a bit more.

Thanks!
Cass

zeroprey
09-21-2002, 08:10 PM
I just drew up a picture explaining what I was trying to do with words. It seems though that my computer is not seeing any usb devices right now, including my camera, which I took a shot of it with. Sorry. As for screenshots I cant get it working right now. Seems when I uncomment it the shadows disappear. sorry again. I had it a week or so ago when we were originally talking about this because you had me worried my shading code was wrong. I took out everything but the selfshadowing term. I did a csg union of a torus through a cylinder in 3ds (less than a 90 degree angle at where they join). I tested this and even this I saw errors. No matter how much theory we talk about matters much when you take a look at how it works in practice. If you're saying youíll just tessellate it so the error goes in to the selfshadow enough you're doing to same as what youíd do to get rid of the original problem. In some test cases you wont see any problems. In the ones Ive tested I see them. maybe you could make a tool to correct models that might have errors. I dunno. What I can tell you is you cant just throw any model that works with per pixel shading at it and have them work. Thanks for the offer Cass.

Brian

zeroprey
09-21-2002, 08:12 PM
Originally posted by cass:


I'm pretty sure you can identify these cases too (at some extra cost), and keep them from being lit, but let me think about it a bit more.



yeah that would be cool. Are you talking while you shadow or preproccessing?

Edit:
Ok I just thought about that and if you could pull that off it would get rid of all but one case which is the s curve case. the one where the outer most triangle has the problem, ie the one on the silhouette.



[This message has been edited by zeroprey (edited 09-21-2002).]

vshader
09-21-2002, 08:38 PM
can you explain that case to me? you're not talking about the one in the picture PH posted - you're talking about something else, yes?

zeroprey
09-21-2002, 09:09 PM
as far as i know theres only one case. this is the one he mentions and the one ive been talking about all along. you have a triangle that is facing away from the light with a concave edge with normals facing the light. its in the shadow but at that edge its lit up because of the normals. its basicly the oppisite of the shadow popping.
_
\
\
\/______|
.

i wonder if that works. if not try copying it to notepad. the dot is the light and the right long line is the face with the problem. the things sticking out are normals. the normal in the middle kinda faces the light (pretend it does) and the right face doesnt. that is the case i know of. there may be more. the reason why this is bad is that it is lit near the middle normal even tho this should be in shadow. is is a text atempt at the picture i drew but cant transfer. remember also that in 3d you have triangles that have small angles where the normal can be much further off from that of the face. Maybe this clears things up?

Brian

edit:
damn didnt work at all. anybody know how to do this here?


[This message has been edited by zeroprey (edited 09-21-2002).]

dorbie
09-21-2002, 10:06 PM
_
\
\
\/______|
.

vshader
09-21-2002, 10:11 PM
so the vert at the point of the V has the problem?

if so, is there a reason why the technique i suggested wouldn't be robust?

in short - you use different normals for self-shadowing caluclations, and modulate the per-pixel lighting results to avoid the artifact.

[sorry - multiple edits]

to be more precise - u would send the triangles face normal at that V vertex, and use that to modulate the bump-map result. just means an extra 3 floats per-vertex probably. in most cases the self-shadowing normal would be the same as the vertex normal. pre-process identifies verts needing special treatment (V-case) and sends different verts for the tris on the two sides of the V - each with triangle face-normal as the "self-shadowing" normal. the same tangent-space basis is used for each vert, though, so non-shadowed lighting is OK.




[This message has been edited by vshader (edited 09-21-2002).]

dorbie
09-22-2002, 12:50 AM
vshader, this is the same problem PH posted. The problem is that even smooth surfaces are approximated by facets. Sure in this extreme case you can intuitively say you don't want to average the normals, but this is just one example. The problem will arise with any situation where the inner shared normal is bent back towards the light. Now it may not be very bright in most cases however a crease will ALWAYS be created inside concave edges, even with subtle curvature because you go from stencil tested zero contribution to *something* however dim along the crease and it will switch on or off depending on the direction of motion. The trick is solving it considering the dynamic situation, sure you could use different normals and solve for a still, but at some point it's going to switch between them.

Cass still has a nice idea, you just have to decide which artifact you like least. 1D texture modulation between 1 and 0 on polys where you flag the concave edge might fix this problem. But then you'd still have to flick that modulation on when going backfaced. You could start modulating before you become backfaced, this would be similar to the modulation term applied to fade the dot product to avoid back faced bump peturbations getting illuminated, you just pull it round the surface a bit, but the effectiveness depends on the tesselation of the model. Coarse models would require too agressive a fade.

[This message has been edited by dorbie (edited 09-22-2002).]

davepermen
09-22-2002, 02:46 AM
why can't we just all raytrace, it would be so much simpler then http://www.opengl.org/discussion_boards/ubb/biggrin.gif ...

at least the major popping bug is now solved, thats a first step..

dorbie
09-22-2002, 03:09 AM
No, it wouldn't work. If you raytrace it it will still fail the shadow test (stencil volumes produce the correct answer just an undesirable one). The flipped shadow is in a sense correct, but it's the combination with the normal or color interpolation that's wrong. The cause of the problem is with the faceted approximation of the curved surface. You'd have to raytrace a more detailed curved surface, and you could also sender such a surface conventionally.

vshader
09-22-2002, 04:01 AM
OK - i get the picture. you don't want to do a preprocess that involves looking at every possible position of a skinned mesh.



this would be similar to the modulation term applied to fade the dot product to avoid back faced bump peturbations getting illuminated,


exactly - you just send in an explicit normal instead of assuming tangent space <0,0,1>

still you could do it dynamically if you have a model structure that has adjacency info - which you would anyway for shadow volumes. you could identify backface/frontface pairs that might have the problem, and perhaps apply the technique that way. no chance of using tri-strips then, though, as anywhere a crease could form you need separate vertex indices for the triangles on each side of the edge so you can mess with the "self-shadowing" normals... or do you? if the frontface tri is shadowed anyway, does it matter which way it's normal points?

depends wether u can quickly and reliably detect the problem cases at run-time.

damn... this idea is interesting, but b4 now i had infinite shadow volumes running totally on the GPU.

[This message has been edited by vshader (edited 09-22-2002).]

PH
09-22-2002, 04:11 AM
Maybe the following could work: use Cass' approach on the triangles in the backfacing list ( wrt. the light ) that are on the silhouette ? These are really the only problematic triangles.

Edit:
Hmmm, no still wouldn't work.

[This message has been edited by PH (edited 09-22-2002).]

cass
09-22-2002, 06:15 AM
Since we're working on-the-fly here, let me try to define a term that may be helpful. http://www.opengl.org/discussion_boards/ubb/smile.gif

Let's define the concavity of an edge as follows:

If for each triangle, ABC, we keep an index to the vertices A, B, and C, and we also keep an index to the vertex opposite A, B, and C as a, b, and c. Here's some ascii art.



C
/|\
/ | \
/ | \
A---B---a

That is, vertex a is the vertex on the adjacent triangle that is opposite edge BC.

We can say that edge BC is concave if dot(plane_ABC, a) is positive, and edge BC is convex if dot(plane_ABC, a) is negative.

Ideally we could just say that we also shadow polygons where the following conditions apply:
a) back facing the light
b) have a concave silhouette edge

The ambiguous case is when a polygon has two silhouette edges, where one is convex and one is concave. It's tempting to call this poorly tessellated geometry, but for concave surfaces, one of the possible silhouette loops must make a transition from concave edges to convex edges. Seems reasonable that this could happen at a single polygon.

<processing....>

Cass

PS minor wording correction

[This message has been edited by cass (edited 09-22-2002).]

PH
09-22-2002, 07:04 AM
Another on-the-fly idea : In addition to the idea I posted above, only use the vertex normals with the silhouette vertices. For vertices ( on backfacing triangles on the silhouette ), use the triangles normal.

Sounds reasonable ?

Edit:
Or simply set the shading on those vertices to 0.

[This message has been edited by PH (edited 09-22-2002).]

davepermen
09-22-2002, 07:12 AM
Originally posted by dorbie:
No, it wouldn't work. If you raytrace it it will still fail the shadow test (stencil volumes produce the correct answer just an undesirable one). The flipped shadow is in a sense correct, but it's the combination with the normal or color interpolation that's wrong. The cause of the problem is with the faceted approximation of the curved surface. You'd have to raytrace a more detailed curved surface, and you could also sender such a surface conventionally.

i don't see any point why raytracing would fail..
you find out what you hit nearest on screen. once you have this point, you check if there is anything between that point and the lightsource. if that is true, you have a factor 0 for the shading part of this light, if you did not found anything, you have a factor 1. that one you can multiply with the normal shading then...

all you need is to get your intersections right...

problem here is, items get "shadowed twice", once thanks to the shadowvolumes, once due the shading. that does only affect selfshadowing, and generates that popping. once you tweak yourself around this, you get other artefacts, seen in here..

about the selfshadowing.. you don't test if you hit the triangle with the to_light-ray for finding out if there is something between the point and the light.. problem solved perfectly..

PH
09-22-2002, 07:27 AM
This illustrates my idea,
http://www.geocities.com/SiliconValley/Pines/8553/noPop_Problem.html

The dark edge is from self-shadowing. Green lines are normals, yellow dot is the light.

Not drawn to scale http://www.opengl.org/discussion_boards/ubb/smile.gif.

cass
09-22-2002, 07:38 AM
Paul,

Seems reasonable to me for handling the case where a back facing triangle participates in both a convex and concave silhouette edge.

My preference would be to handle it at the polygon level only rather than both the polygon and vertex level if possible.

Thanks -
Cass

dorbie
09-22-2002, 07:51 AM
Dave, the result would be indistinguishable from the stencil approach. The WAR would suffer from the same problem. Perhaps ybe I'm missing something you are proposing.

vshader
09-22-2002, 07:52 AM
Originally posted by cass:
Ideally we could just say that we also shadow polygons where the following conditions apply:
a) back facing the light
b) have a concave silhouette edge


but we don't want to shadow the whole tri - just the offending edge. the other vertex should have a nice smooth shaded gradient.
we just want to id the offending edges and send some info that will "unshade" them...
and if i get the problem right (i can't implement anything 'cos my engine is broken) - it's not the silhouette edge thats concave, but a non-silhouette edge of a triangle on the silhouette edge - only one vertex of an offending triangle need be on the actual silhouette edge, and the opposite edge will possible exhibit the problem depending on normals.


originally posted by PH
Another on-the-fly idea : In addition to the idea I posted above, only use the vertex normals with the silhouette vertices. For vertices ( on backfacing triangles on the silhouette ), use the triangles normal.
Sounds reasonable ?



thats pretty much what i've been suggesting, but you describe it much more cleanly than me. we send a normal that correctly describes the "backfacing-ness" of this tri for use in the shading calculations - a "self-shadowing" normal. there's easily room to fit this normal in a color interpolator and use it instead of lightspace Z for the self-shadowing modulation of per-pixel lighting results (assuming tangent space bumpmapping)... i get the feeling the object-space case would be easier, but i haven't thought it thru properly


edit: oops UBB code



[This message has been edited by vshader (edited 09-22-2002).]

cass
09-22-2002, 08:35 AM
vshader and Paul,

I agree that the "right" approach is to shade-as-black only the vertex that is on the concave silhouette, and only for the polygons that are back facing the light.

The only time you really need to draw those polygons at all is when there is an inflection point (concavity change) inside the polygon. That is, when the edges are not all convex or all concave.

In any case, I think you can identify the "bad" case and fix it. The question now is, how to do it efficiently.

Cass

davepermen
09-22-2002, 08:42 AM
Originally posted by dorbie:
Dave, the result would be indistinguishable from the stencil approach. The WAR would suffer from the same problem. Perhaps ybe I'm missing something you are proposing.

yes, you are. and i'm missing what.., so i can't help you http://www.opengl.org/discussion_boards/ubb/biggrin.gif

i know just one thing, never had any such problems with raytracing at all.. but i had them the first time i tried to work with stencilshadows, so no, they don't give the exactly same results..

PH
09-22-2002, 08:44 AM
I don't think it is required to detect anything if you only process the backfacing tirangles *on* the silhouette. Two out of the three vertices ( the ones on the silhouette ) are shaded as normal, the last on is set to shade=0. All other triangles are tested using the standard shadow algorithm. I'm starting to confuse myself http://www.opengl.org/discussion_boards/ubb/smile.gif but wouldn't this work and be efficient ?

cass
09-22-2002, 08:52 AM
Paul,

A back facing triangle can be on both a convex silhouette AND a concave silhouette. You need to darken the vertex on the concave silhouette, but not the convex silhouette. Is that what you mean?

Maybe that's not too difficult, but it does require you to build new vertex data on-the-fly, right? For immediate mode, this is no big deal at all...

Thanks -
Cass

tarantula
09-22-2002, 08:56 AM
Originally posted by davepermen:
i don't see any point why raytracing would fail..
you find out what you hit nearest on screen. once you have this point, you check if there is anything between that point and the lightsource. if that is true, you have a factor 0 for the shading part of this light, if you did not found anything, you have a factor 1. that one you can multiply with the normal shading then...


Dave, what you are doing is same as finding ordinary shadows .. ones without Cass correction http://www.opengl.org/discussion_boards/ubb/biggrin.gif. The problem here arises because going by the face normal or the raytrace shadow test, the triangle should be shadowed but going by the vertex normals it shouldnt be fully shadowed.

PH
09-22-2002, 09:03 AM
Cass,

Actually, I meant darken both. If it's convex, the triangles that are connected to the "backfacing silhouette triangles" are self-shadowed anyway.
It might not be efficient with arrays, I haven't thought about that.

Edit:
I probably haven't considered this thoroughly enough, so I'm not positive this will work.

[This message has been edited by PH (edited 09-22-2002).]

cass
09-22-2002, 09:16 AM
Paul,

You definitely don't want to darken vertexes that are on a convex silhouette edge. Those were the ones that shadow volumes were messing up to begin with.

I'll put up some diagrams later if this is still unclear.

Thanks -
Cass

PH
09-22-2002, 09:18 AM
Ah, of course. I see it clearly now http://www.opengl.org/discussion_boards/ubb/smile.gif, I almost forgot what the initial problem was.

PH
09-22-2002, 09:21 AM
Wait, I'm still confused. If you don't shadow the silhouette ( using stencil ) but use the shade=0 for the convex edges, would the shading be smooth ? The stencil SV approach would remove the shading entirely.
The silhouette vertices are shaded as normal, of course. But without stencil.

[This message has been edited by PH (edited 09-22-2002).]

davepermen
09-22-2002, 09:24 AM
Originally posted by tarantula:
Dave, what you are doing is same as finding ordinary shadows .. ones without Cass correction http://www.opengl.org/discussion_boards/ubb/biggrin.gif. The problem here arises because going by the face normal or the raytrace shadow test, the triangle should be shadowed but going by the vertex normals it shouldnt be fully shadowed.

a) it does not result in the exactly the same, if i would be so stupid and test against the own face, like the uncorrect version in the stencil shadow volumes, due to the perpixel determination if we want to shade in shadow or not, wich is not the case in, uhm, vertexlighting http://www.opengl.org/discussion_boards/ubb/biggrin.gif
b) i use the workarount cass suggested, and that one solves actually the problems correctly, at least in raytracing. in fact, that workaround is standard in raytracing, as you never trace against the hitten triangle against when going away from the triangle again (due rounding errors that could yield to bad effects.. in fact, everything would get shadowed, reflections would only reflect itself, etc in worst case)

PH
09-22-2002, 09:33 AM
Here's how I thought about handling the convex case,
http://www.geocities.com/SiliconValley/Pines/8553/shade.html

Edit:
Backfacing on the silhouette means : backfacing triangles that are on the silhouette.

[This message has been edited by PH (edited 09-22-2002).]

vshader
09-22-2002, 10:06 AM
so - how to do it efficiently...

as for modifying the vertex data on the fly maybe you can avoid that - all you need to use is the triangle face normal for that vertexes shading, which is known in advance and could be in your arrays as another vertex attribute.

but you need to pass in more info to the vertex program to decide wether to use it or not ... i'm clear on how to define the problem and the needed data for an edge, but not for an individual vertex...

it's very late on this side of the world, and i was hoping to go to bed after i cleared up the shift/reduce conflicts in my Yacc shader grammer (just finished)... but now i want to work this out...

cass
09-22-2002, 10:18 AM
Paul,

Still thinking about it, but your approach sounds reasonable to me.

Cool! (I think.)

Thanks-
Cass

vshader
09-22-2002, 11:02 AM
starting to think this can't be done with static vertex data - you can do standard infinite shadow volumes in a vertex program without needing adjacency info, but i don't think you can do this non-popping technique.

but if you do software skinning anyway then u can do this technique with no problems.

we need GL_ARB_primitive_program!

Edit: i type faster than i think. http://www.opengl.org/discussion_boards/ubb/frown.gif now it makes sense.

[This message has been edited by vshader (edited 09-22-2002).]

Liquid
09-22-2002, 05:32 PM
Try this:
Use the standard smooth-shading.
And then use only polygons that backfaces the light for your shadow volumes with the z-fail approche.
Render these polygons and it's possible sillouettes extruded to infinity and itself infinite far away.
Use glDepthFunc(GL_LEQUAL).

dorbie
09-22-2002, 11:22 PM
Dave I think you're missing the popping because ray tracing is very slow :-). At a fundamental level the ray shadow test produces the same result as stencil volume test for meshes approximating curves.

davepermen
09-22-2002, 11:42 PM
Originally posted by dorbie:
Dave I think you're missing the popping because ray tracing is very slow :-). At a fundamental level the ray shadow test produces the same result as stencil volume test for meshes approximating curves.

have i talked about popping? i talked about artefacts..
and i can't see them here around..

dorbie
09-23-2002, 12:32 AM
Popping was my poor choice of words.

davepermen
09-23-2002, 01:25 AM
Originally posted by dorbie:
Popping was my poor choice of words.

popping is the right word for fast animated artefacts.. thats why i don't use it http://www.opengl.org/discussion_boards/ubb/biggrin.gif i will not have any fast animated artefacts in my raytracer till i get my new pc.. but even so, i have no artefacts at all

dorbie
09-23-2002, 02:51 AM
Well there are underlying issues with workarounds that are not the same as the original popping, but it was really only a joke about ray tracing performance. We've already agreed I'm missing some understanding of what you're doing to fix this.

[This message has been edited by dorbie (edited 09-23-2002).]

davepermen
09-23-2002, 03:05 AM
Originally posted by dorbie:
Well there are underlying issues with workarounds that are not the same as the original popping, but it was really only a joke about ray tracing performance. We've already agreed I'm missing some understanding of what you're doing to fix this.

[This message has been edited by dorbie (edited 09-23-2002).]

i got the joke.. haven't you seen the fat green smile in my post? here it is again: http://www.opengl.org/discussion_boards/ubb/biggrin.gif
hehe http://www.opengl.org/discussion_boards/ubb/biggrin.gif
(oh, yet another one http://www.opengl.org/discussion_boards/ubb/biggrin.gif)
well, once i have my 3.6giga p4, i'll have the power to render some more complex models fast, i'll check then, if there is popping or not http://www.opengl.org/discussion_boards/ubb/biggrin.gif

V-man
09-23-2002, 02:13 PM
I didn't understand what the solution was from the txt file. Can anybody explain it? An it seems to have disseapered from cass's site.

I got confused when reading some posts. Is there more problems to solve or did new problems get discovered here?

Well, at least I know what "popping" mean http://www.opengl.org/discussion_boards/ubb/smile.gif

V-man

PH
09-23-2002, 03:01 PM
V-man

The comments in the source are more helpful that the txt file ( which is still there ). No, it hasn't been solved yet. The ideas posted in this thread are not proven yet ( it might not work ). I implemented it ealier today but didn't get the results I expected ( there's a bug in there somewhere ).

I'm wondering if Cass has any news on this ? Or perhaps looking into some other technique.

[This message has been edited by PH (edited 09-23-2002).]

vshader
09-23-2002, 03:01 PM
I didn't understand what the solution was from the txt file. Can anybody explain it? An it seems to have disseapered from cass's site.


only shadow backfacing polygons that are inside more than 1 shadow volume.

look for the bit in the source file where the stencil reference value is changed to 129 (128==0 shadow volumes).

edit: am i bad at UBB or what?

edit 2:
oh, V-man do you mean the solution to the solution?

best so far is this:
process the mesh at runtime and send extra info to disable shading on vertices that will exhibit the artifact. i don't like this cos u can't do it in a vertex program... but i can't think of a way to do it in one without sending 3x the geometry needed to draw the model.



[This message has been edited by vshader (edited 09-23-2002).]

SirKnight
09-23-2002, 03:13 PM
PH, have you tried the shadow volume insetting technique (what the d3d8 shadow volume demo does) with your v shaped geometry and see how that works with that? I wonder if Carmack has a solution. Everything looked good in doom 3 so far, so maybe he's doing something to get rid of the popping. Or telling the artists to NOT model concave parts in the models. http://www.opengl.org/discussion_boards/ubb/wink.gif

-SirKnight

PH
09-23-2002, 03:22 PM
SirKnight,
I haven't tried the inset approach. Take a look at the the video on this page,
http://www.ati.com/technology/hardware/mobilityradeon9000/testimonials.html

It's John Carmack talking about the ATI Mobility R9000. Notice the severe popping on the machinery. It's the old MacWorld clip but even Carmack has problems http://www.opengl.org/discussion_boards/ubb/smile.gif. There's also some popping on the body in the bathroom scene ( other video ). I was of course specifically looking for errors when I viewed the videos.

[This message has been edited by PH (edited 09-23-2002).]

vshader
09-23-2002, 03:36 PM
all the doom3 screenies i have have very hard edged shadows on the silhouette tris.

id hasn't published any non-poppy shadow volume screenies i'm aware of.

SirKnight
09-23-2002, 04:05 PM
I have that video but for some odd reason the sound doesnt work. The music I hear is pretty crapped out and I can't hear carmack at all. It sounds real low and distorted. I even cranked the volume up a lot and I still can't make out what he's saying. http://www.opengl.org/discussion_boards/ubb/smile.gif Maybe the new media player MS released will fix it.

I think the bad thing about the inset approach is that depending on the geometry, different inset values are needed. If that is wrong I would like to know it. http://www.opengl.org/discussion_boards/ubb/wink.gif If that is correct, maybe there is a way we can analyze the geometry to figure out using some formula like thing to find an inset value that will work ok. But running through the models doing this may be a bit slow.

I've been thinking about this anomaly with the popping pretty much all day and getting a good fast solution is pretty hard. I hope somehow we can figure something out.

BTW, Cass, are you still thinking of making a follow up paper to the inf shadow volume paper? If we can figure out a good way to eliminate popping that would be a perfect time to make a follow up explaining this to others. http://www.opengl.org/discussion_boards/ubb/smile.gif

dorbie
09-23-2002, 04:36 PM
I thought it was sufficient to do the stencil test vs the increased stencil value only on back facing polys which also contribute a silhouette edge to a volume.

I assumed that's what was being proposed.

If not then it would be a slight enhancement of the algorithm that produced fewer artifacts.

P.S. a modeller or converter could also exploit this by adding an extra subdivision before seriously concave apexes to reduce most remaining artifacts. A subdivision of a poly which bent back with a coplanar junction with only silhouette polys unstencil tested would eliminate all the artifacts but i'd guess you'd want to use it sparingly.


[This message has been edited by dorbie (edited 09-23-2002).]

vshader
09-23-2002, 05:59 PM
Originally posted by dorbie:
P.S. a modeller or converter could also exploit this by adding an extra subdivision before seriously concave apexes to reduce most remaining artifacts. A subdivision of a poly which bent back with a coplanar junction with only silhouette polys unstencil tested would eliminate all the artifacts but i'd guess you'd want to use it sparingly.



i think the problem with that one, is that for an animated mesh it would be a lot of work figuring out where that could happen as a preprocess. and it may turn out that it could happen in a lot of places on the mesh....anywhere a concave possible silhouette edge can form from a light from any angle is susceptible. i'm pretty sure that for any concave silhouette edge there is a light position that could cause the artifact. and if there is any spot on the mesh that could possibly form a concave or convex silhouette edge (due to animation), you have a real problem... the 'fix' for the artifact will give a result identical to standard stencil shadows - ie a hard edge which pops in and out or shadow.

if at runtime you identify verts on concave silhouette edges with normals facing into the light, you can disable shading on them cos they really should be black (i thought about it and using a different normal won't work always unless you have no shared vertices).

so if u calculate the shadow volumes in software, you just have to add a concavity check... the problem is it also means writing an extra vertex attribute per-vertex per-frame.
if you are doing that anyway, then no-problem.



[This message has been edited by vshader (edited 09-23-2002).]

cass
09-23-2002, 07:44 PM
Paul,

No, I haven't had a chance to do any testing on the stuff we've discussed here this past weekend. I feel pretty confident (intuitively) that we've arrived at a robust solution, but testing is needed.

I would still like it to be "simpler". But - we find *a* solution first, then we make it elegant. http://www.opengl.org/discussion_boards/ubb/smile.gif

Cass

vshader
09-23-2002, 09:18 PM
Originally posted by dorbie:
I thought it was sufficient to do the stencil test vs the increased stencil value only on back facing polys which also contribute a silhouette edge to a volume.

I assumed that's what was being proposed.

If not then it would be a slight enhancement of the algorithm that produced fewer artifacts.



oops.
dorbie i misunderstood you.

i get it now... you were working on the assumption that we were only testing silhouette edge tris against the higher stencil value - as long as you make sure they are only convex possible silhouette edges (or that they are only "actual" silhouette edges), then that will wipe out most of the artifacts.

it means doing 3 passes of the geometry (front facing, backfacing convex silhouette, all other backfacing), and will only trip up when a triangle is on both a convex and concave "possible" silhouette.

so i assume that's what you meant about subdividing the triangle - ensuring one triangle never has concave and convex edges. this will be robust as long as the animation does not turn this new edge into a concave silhouette edge for any light positions... which you can maybe do by making sure the vertex weights of the new vert are a linear combination of two old ones, the linear weights based on the new verts parametric distance along the line connecting the two original verts. (is that right? we need to make sure the 2 tris are always coplanar)

that sounds pretty robust to me... involves no runtime extra geometry, just a few extra dot products per edge and another pass.

dorbie
09-24-2002, 10:14 AM
It's the same number of passes as the initial solution. In fact a pass in this sense is really a drawing bin since the 'passes' have mutually exclusive content so you're really talking about state change and meshing overhead rather than passes, depending on how you implement.

Yes you got it, if a quad or tri has the potential to cast an outside silhouette edge and have a concave internal edge it gets subdivided into coplanar facets.

It is robust I think however it would lead to more tris on the mesh in general.


[This message has been edited by dorbie (edited 09-24-2002).]

ToolTech
09-24-2002, 12:56 PM
just some reflections on this topic and what I am doing in Gizmo3D.

Another approach.. The Gizmo3D way ;-)

I divide all objects into two groups.

1. Objects that cast shadows and can self shadow

and..

2. Pure shadow receivers and possible non shadowed objects

The first group renders its shadow volume with GL_LEQUAL and a negative poly offset which mean that all front facing tris will be included in its own shadow volume. All trivial front facing tris will get a stencil number of 1 of its own shadow volume. All backface tris covered by these tris will also get 1. Subsequent covered front facing tris will get higher values.

Group 2 renders with a stencil val of 1 for shadow receivers and 0 for non receiving objs.

Now a recursive rendering of shadowed area uses stencil values 2 and greater to get shadowed.

By aligning the ambient factor of back facing polys in combination with a shadowed front facing we get a complete smooth transition between "round corners" without any extra passes...

E.g. By using another ambient value + diffuse components weighted by an added tranparency it also works for soft shadows and multiple lights.

Any comments ?? This seemes as a simpler approach..

vshader
09-24-2002, 08:00 PM
ToolTech,

that definitiely sounds simpler but i'm afraid you lost me at the "ambient factor" bit... care to explain those last few lines in different words?

dorbie
09-24-2002, 09:13 PM
I don't see how it works either. This is a predominantly delf shadowing problem. With your scheme it seems like either objects don't self shadow or if they do they suffer the same fate as the methos descrobed in this thread.

Yould you give some more detail on what happens to a self shadowing object (class 1 in your description). And when you say recursive what do you mean.... it sounds interesting.

ToolTech
09-25-2002, 12:17 AM
The sentence "By aligning the ambient factor .." is due to the fact that i do a number of shadows with different skinning matrixes to generate the umbra for soft shadows. Each pass adds a darkening factor. Therefor the complete shadowed ambient value must be the same as the lit poly ambinet - the darkening factor. This way a back faced poly with no back face lighting will interpolate equally to the resultant ambient value of the shadowed polys.

The recusrsive stuff.. I do a recursive rendering using stencild so i can mix shadows and contributions from multiple light sources.. or e.g. render shadows in mirrors etc.

The trick about self shadowing is actually to identify that the layer of "first hit" polys in a light will not contribute to the shadow volume. At the same time realise that they do add a stencil value so lets say that you have a box. the fron face will be inside the shadow volume but will not be shadowed. The sides that are backfacing will be inside the volume but they will not be shadowed by the shadow volume but they will be shadowed by their normals backfacing properties. E.g. if the sides were convex or concave the normals would interpolate the shadowing.

In other words. The box would not be using the shadow volume for self shadowing.

Lets take a more complex object with actual fron facing polys that are shadowed by other fron facing polys in the same object. They will be included in their own shadow volume but also in the shadowing polys volume and therefor get a shadow stencil value >=2. They will be draw with the recursive shadow renderer with material props and blending that make them shadowed. They will not be rendered using their normals direction..

I have a sample of this i can put on the WEB..

/Anders

vshader
09-25-2002, 03:43 AM
Tool Tech - thanks, that is much clearer.

but still, i am a little confused... your method avoids lighting on a concave silhouette edge of a backfacing poly inside <2 shadow volumes exactly how?

i read the bit where you say they will be shadowed by their normals backfacing properites, but if a vertex is on a concave 'possible silhouette' edge, it is quite legitimate for it to have a normal that is front-facing towards the light, even though the triangle is back facing. that's the artifact we have been talking about... forgive me if i have missed something obvious, but it seems your method would suffer from the same artifact... what did i miss?

ToolTech
09-25-2002, 04:24 AM
You are right. It doesn't solve all issues but it is very easy to implement and faster than to check normals etc.

I am sorry if I stated this..

In my oppinition one should allow convex smooth surfaces but concave items should be modelled better.

Anyway the visual quality is much better without any extra code...

vshader
09-25-2002, 05:52 AM
Originally posted by ToolTech:
Anyway the visual quality is much better without any extra code...

all the extra code we've been talking about is just to avoid this artifact - the basic technique only involves changing the stencil reference value by one when checking backfaces. but your technique doesn't even require changing the stencil reference value ... have you had any problems getting the right polygon offset value? any shadow artifacts with polygons intersecting a frontfacing 'first-hit' face?



In my oppinition one should allow convex smooth surfaces but concave items should be modelled better.


Cass first suggested that the artifacts only turned up with poor modelling, but thinking it thru it seems that the situations where this artifact turns up aren't due to poor modelling - any concave area that is meant to be smooth rather than a hard crease can quite legitimately have normals that will cause the problem. i haven't been able to think of a way of modelling those areas to fix the artifact that doesn't mess up situations when they are not shadowed...

edit:UBB and grammer tidy up



[This message has been edited by vshader (edited 09-25-2002).]