PDA

View Full Version : finding if polygon can be seen by light?

Andy Gilbert
04-28-2010, 05:57 AM
Hi, im trying to work out how i can find out if a polygon can be seen by a light or a lights direction?

Ive got my self lost in the "plane equation" and not sure if thats what im meant to be using or not?

But what i have for now is:

A light source at XYZ and an array of verts that make a cube and a normal for each face of the cube.

And ide like to find to loop threw the faces somehow and determind if there viewable by the light?

Thanks
Andy

Dark Photon
04-28-2010, 06:38 AM
Hi, im trying to work out how i can find out if a polygon can be seen by a light or a lights direction?
Are you talking about determining whether the polygon is "facing" the light source?

Or are you talking about whether the polygon can see the light source given other objects in the scene?

The former doesn't depend on potential "shadow casters". The latter does.

Andy Gilbert
04-28-2010, 06:53 AM
No sorry, im doing this for shadow casting so the first option. Im trying to find out weather a polygon can see the light source. So i know it is to cast a shadow. (shadow volumes)

EDIT: Ive done the above (ive calculated the face normal vector against the light position vector) So just the issue below now :p

Once i find the face, i then need to go threw all the edges, but i see small issue i cant seem to find a simple soultion to.

I have my array of a polygon (quad) so 4 edges.
so:
verts[4]
0,0,0
0,0,1
1,0,1
1,0,0

so at first i thought, simply loop threw as follows: (pseudo code)
for i = 1 to 4 //edges
v1 = verts[i]
v2 = verts[i+1]

But that works until last loop 4, where v2 trys to get the 5th element (4+1) from the array, which doesnt exsist?

How do i get around that?

Thanks
Andy

Andy Gilbert
04-28-2010, 07:37 AM
Its ok, ive managed. Im not sure if there is a simpler way but ive simply said, if i = 4 then i = 1. :)

Does the trick for now!

thanks
Andy

carsten neumann
04-28-2010, 07:57 AM
you could use i % 4, i.e. compute the remainder of an integer division by 4, this will restrict your indices to the range [0 .. 3] (which are the valid indices for an array of size 4 in languages that use 0 based indexing, e.g. C/C++):

v1 = verts[i % 4];
v2 = verts[(i+1) % 4];

Andy Gilbert
04-28-2010, 08:13 AM
Hmm Maybe my solution to my initial problem of determining whether a polygon is "facing" the light source isnt to good.

It works, but it seems like its not smooth. If i have a rotating plane, i want it to flag facing if its only very slightly facing or fully facing?

Thanks
Andy

strattonbrazil
04-28-2010, 11:20 AM
What's not smooth? If you're working with just a cube, you shouldn't get any kind of popping on your shadows. I'd say it's a bug in your edge loop.

If you want to do a simple test, ignore your neighbors and just extrude edge loops around each face facing the light. If that fixes the problem, it's your extrusion. If not, make sure you're extruding far enough. I haven't ever heard of shadow volumes being finicky with grazing angles to the light. Especially with a cube.

Maybe you could be more specific about "not smooth". Is it popping or something?

Andy Gilbert
04-28-2010, 02:40 PM
Hi, thanks for the reply. Yeh popping is a better descriptor.

Its hard to explain, i might try to make a quick vid and show. But basically, as the cube spins when a new face becomes an occluder, instead of it appearing slowly, its like theres a delay and then suddenly it appears, moves round untill not occluding any more and dissapears.

Oh and at the moment, i am not neighboring, just extruding all faces that are occluding, but as im only working with one cube, thats a maximum of 3 at one time.

Thanks
Andy

Andy Gilbert
04-28-2010, 03:31 PM
Ok, heres a quick video of the problem.

I have made the shadow green to see it flick on and off.

few faces of the cube seem fine, then as it comes around, you will see the shadow disapears to early, causing it to "pop".

You can best see it, as the "watch carfully" text appears and near the end.

and at the moment, the way i am finding out if a face is a occluder is using this equation. (each face has a normal) so:

for every face
occluder = FaceNormalX*lightposX + FaceNormalY*lightposY + FaceNormalZ*lightposZ

then:

if occluder >= 0.0 then "extrude edges"

<object width="425" height="350"> <param name="movie" value="http://www.youtube.com/v/By6q2dT1VEY"></param> <param name="wmode" value="transparent"></param> <embed src="http://www.youtube.com/v/By6q2dT1VEY" type="application/x-shockwave-flash" wmode="transparent" width="425" height="350"> </embed></object>

strattonbrazil
04-28-2010, 04:03 PM
for every face
occluder = FaceNormalX*lightposX + FaceNormalY*lightposY + FaceNormalZ*lightposZ

Yeah, that's not a very robust solution. Imagine you have a light at (0,10,0). You also have a face lying on the XZ plane. Faces the light, right? Now imagine you move that plane up twenty units in the y direction so it's no longer facing the light. According to your equation, it's still facing the light because that answer is positive. You need to take the box position into account.

Think of things in terms of spaces. Image you have your face normal in world space. From that face (or a vertex on that face), what is the direction to the light? Right now you're setting the direction from the face to the light as the light position. It's the light position minus the box position.

In short, use face normal dotted with light direction from a vertex (or face midpoint), not light position. And make sure they're both in the same space (world space is probably easiest).

Nice video.

Andy Gilbert
04-28-2010, 04:21 PM
Hi, thanks yeh, although i never realised, i did think "it cant be that simple" infact when i implemented that and ran it, i didnt expect it to work at all and was highly surprised when i got the results i was.

But you right, its not robust.
But, im stil learning this and ill give your reply another good few reads in hope ill understand, but if you fancy putting it in more lamens terms, that would be a great help. (the equation more than anything)

Thanks
Andy