View more

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

### The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

# Distance to cone light / cone light culling

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

2 replies to this topic

### #1theagentd  Members

Posted 31 August 2014 - 06:09 PM

Hello!

I am trying to figure out a good way of determining

1) if a cone light with a certain position, direction, field of view and range is visible on the screen (frustum culling) and

2) how far away the camera is from the light so I can pick a fitting shadow map resolution.

I am currently treating the cone light like a point light with the center of the sphere being the origin of the cone light and the radius of the sphere being the range of the light, but this creates a lot of false positives and overestimates the shadow map resolution. I want to do more precise frustum culling, and I also want to calculate a more accurate distance from the camera to the closest point that lies inside the cone light's volume to better estimate the shadow map resolution.

For point lights I simply use the highest shadow map resolution available when the camera is inside the point light's volume, and then gradually reduce the resolution proportionally to

1 / (distance from center of point light - radius of point light)

if the camera is outside the point light's volume.

For cone lights I wish to do something similar. I want to determine if the camera is inside the cone light. If it's not, then I want to calculate exactly how far away it is from the cone light's volume, and pick a shadow map resolution based on that.

### #2Buckeye  GDNet+

Posted 31 August 2014 - 08:45 PM

Off the top of my head (check this yourself):

Given a point c, tip of the cone position p,  and cone direction d:

Setup vector C = c-p

Length of C = |C| is distance from c to p.

Let Ldot = d dot C

[EDIT: a little bit of a slipup; the following assumes d is the normalized (length=1) direction vector]

if Ldot < 0, point c is not in the cone (it's somewhere "above" the cone in the opposite direction of the cone direction)

if Ldot > range, point c is not in the cone. (it's beyond the end of the cone)

Since Ldot = |d| |C| cos(angle),

Let angle = cos-1( Ldot/( |d| * |C| ) )

if angle > cone angle, point c is not in the cone. (angle is what I think you mean by "field of view.")

Edited by Buckeye, 01 September 2014 - 07:23 AM.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.

### #3MJP  Moderators

Posted 01 September 2014 - 12:22 AM

It is possible to test a cone for intersection with a plane, and the algorithm is described in the book Real Time Collision Detection. If you perform this test against the 6 planes of the view frustum, you can cull spotlight cones in the same way that you would typically cull a sphere. Just be aware that as the cone gets larger relative to the size of the frustum it becomes more likely to generate false positives (the same problem happens with spheres as well). As an alternative you can represent your spotlight with an oriented bounding box or a frustum, and test for intersection with a frustum using the separating axis test. SAT produces exact results, but is more complex than testing a sphere or cone against the frustum planes.

As for scaling down your shadow map resolution, you should consider that in the ideal case you'll want to scale your shadow resolution based on the projection of your occluders onto the receivers being lit by the spotlight. So if you're going to base it on a distance from the camera, then you'll probably want to pick a point inside the cone that represents the most likely place for a receiver to be. If everything is dynamic then you'll probably have to guess or estimate, unless you do some calculations at runtime. However if the light is static and there's static geometry involved, then you can possibly do a bit of offline analysis to make a better initial guess at which point to use.

Edited by MJP, 01 September 2014 - 12:25 AM.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.