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 
but wouldn’t this work and be efficient ?
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
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 . 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.
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).]
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
Ah, of course. I see it clearly now , I almost forgot what the initial problem was.
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).]
Originally posted by tarantula:
Dave, what you are doing is same as finding ordinary shadows … ones without Cass correction . 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
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)
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).]
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…
Paul,
Still thinking about it, but your approach sounds reasonable to me.
Cool! (I think.)
Thanks-
Cass
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. 
now it makes sense.
[This message has been edited by vshader (edited 09-22-2002).]
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).
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.
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…
Popping was my poor choice of words.
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 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
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).]
Originally posted by dorbie:
[b]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).][/b]
i got the joke… haven’t you seen the fat green smile in my post? here it is again:
hehe
(oh, yet another one )
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
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
V-man