This topic is 4555 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Cant fremember if its Frustum frustrum fustrum or whatever. Anyways... I'm hoping to begin implementing shadow mapping in opengl. And ive got a pretty good idea how I'm going to generate the modelview matrix for rendering the shadow map. (this is assuming point lights) Create a look at matrix from the light to the center of the object (or in this case the center of the object's bounding volume (ive chosen sphere unless anyone believes an OBB or AABB would be better) )But unfortunately I'm at a loss about creating the projection matrix. I assume it would need to be a perspective projection matrix since it is a point light. But my question is how would you create the projection matrix so that it JUST BARELY encloses the objects bounding volume (in this case a bounding sphere) thanks a ton -Dan

##### Share on other sites
Hrm, no one? Is this not a common approach?

thanks
-Dan

##### Share on other sites
I'm sure someone can answer, just you posted in the wrong forum. Try opengl or graphics programming and theory.

##### Share on other sites
Hrm, I suppose, i felt it was math-y enough, but i guess not. Could a mod move this to graphics programming and theory?

Thanks
-Dan

##### Share on other sites
Given the light location E, sphere center C, and sphere radius R. The frustum has unit-length direction vector D = (C-E)/, where L = Length(C-E). The near value is n = L-R. Notice that the point E+n*D is the closest sphere point to the light location. The far value is f = L+r. If you have a frustum just bounding the sphere, any rotation of that frustum about the view direction is valid. Choose an up vector U and a right vector R so that {D,U,R} is an orthonormal set: all unit-length vectors, mutually perpendicular, R = Cross(D,U).

For the next part of this, draw the 2D scenario for illustration. You have a circle with center C and radius R, and a light location E. The "x" axis is the line through E in the direction of R. The "y" axis is the line through E in the direction of D. Two rays emanate from E and are tangent to the circle. Let Q be the tangent point for the ray on the right. The triangle <C,Q,E> has an edge opposite C with length R and a hypotenuse of length L. The angle A between edges <C,Q> and <C,E> is determined by tan(A) = r/L. The field of view in the R direction is 2*A = 2*arctan(r/L). By the symmetry, the field of view in the U direction is also 2*A.

You can set the coordinate frame with
gluLookAt(E.x,E.y,E.z,E.x+D.x,E.y+D.y,E.z+D.z,U.x,U.y.U.z);
You can set the frustum with
gluPerspective(2*A,1,n,f);
where 1 is the aspect ratio. Naturally, you will need other OpenGL calls to correctly set up the matrix stack, especially for the frustum setup since you need the texture-matrix stack.

##### Share on other sites
Thanks a TON. (havent read the whole thing yet, so i may come back with questions) but thank you thank you thank you

cheeers
-Dan

##### Share on other sites
Yep, I ended up with some questions. First, is it necessary to use gluPerspective ? (as in is there a way to do it with just glFrustum or just fill in the matrix yourself) And second, should, for the light's modelview matrix, the "z" component vector be pointing towards the shadow caster, or away?

thanks a ton
-Dan

##### Share on other sites
You mentioned doing this in OpenGL. Is there a problem using gluPerspective? Same question about using gluLookAt.

To use glFrustum, you need to compute the left, right, bottom, and top frustum values. The angle A is as in my previous response. I should have mentioned that 2*A needs to be in degrees, but my calculations have it in radians. The frustum is symmetric, so left = -right and bottom = -top. Once again an appeal to right triangles and trigonometry produces right = near*tan(A). By the symmetry, top = right. Call glFrustum with the parameters in the correct order.

The vector D is just a direction. It is possible to orient the frustum so that it does not even contain a shadow caster.

##### Share on other sites
Well im actually trying to avoid use of the glu library, but aside from that I was hoping that I could avoid dealing in angles (to avoid unneccesary trig functions if at all possible)

thanks
cheers
-Dan

##### Share on other sites
have i understood that right? you want to do shadow mapping with a point light? i don't know if there's such a great difference between directX and opengl but i think what you're trying to achieve is only possible with rendering to a cubemap at the lights position...the usual shadowmapping only works for spotlights and directionallights

regards,
m4gnus

##### Share on other sites
Quote:
 Original post by Ademan555Well im actually trying to avoid use of the glu library, but aside from that I was hoping that I could avoid dealing in angles (to avoid unneccesary trig functions if at all possible)thankscheers-Dan

As you can see from my construction, you have to use a trigonometric function. Calling the trigonometric function is not going to be the bottleneck in your application. The multipass rendering is.

##### Share on other sites
Quote:
 Original post by m4gnushave i understood that right? you want to do shadow mapping with a point light? i don't know if there's such a great difference between directX and opengl but i think what you're trying to achieve is only possible with rendering to a cubemap at the lights position...the usual shadowmapping only works for spotlights and directionallightsregards,m4gnus

You do not need an actual light that you use glLight to set up. The scene is rendered from a point in space. You have a coordinate system at that point (origin is the point, axes are view direction, up vector, right vector). And you select a frustum for the drawing. The rendering itself is just to obtain depth information, which is used in the second drawing pass from the camera's perspective.

##### Share on other sites
Quote:
 Original post by Dave EberlyYou do not need an actual light that you use glLight to set up. The scene is rendered from a point in space. You have a coordinate system at that point (origin is the point, axes are view direction, up vector, right vector). And you select a frustum for the drawing. The rendering itself is just to obtain depth information, which is used in the second drawing pass from the camera's perspective.

i know how shadow mapping works but i think you cannot create a view matrix with fov 360 (which you need for a pointlight) or at least it wouldn't give the right results...

regards,
m4gnus

##### Share on other sites
Actually, you dont need a fov of 360, you would just have separate shadow maps for each shadow caster (which works pretty well i assume as long as the number of shadow casters is low) (note: i dont actually know if this is a viable solution, its just an idea I had) Additionally, there are alternatives to cubemaps for omnidirectional shadow mapping, (dual parabloid shadow mapping) not that they're a better solution

cheers
-Dan

[Edited by - Ademan555 on June 23, 2005 5:02:55 PM]

##### Share on other sites
why do you want ot do that? you can have dynmaic shadowing of the whole scene at the same/lower performance cost. Because as i understood that right you want to render every shadowcaster from the light's pov with the usual shadowmapping you can generate the shadow for 'em all but the number of passes doesn't increase per caster... But surely if you want it why not...i think cs:s uses the same technique for their player shadows(they're quite bugged though)

regards,
m4gnus

##### Share on other sites
cs:s uses a shadow map per caster iirc. (EDIT: maybe thats what you were saying, im quite tired lol )Omnidirectional shadow maps have very big problems still (one of which cypher is attacking, which is great) Omnidirectional shadow maps become aliased very easily, they never were intended for outdoor scenes really, but cypher's skewbie maps may very well be the answer (they look great). Then, the lack of a depth cube slows down storage and access of depths in omnidirectional shadow maps.

I guess here are my thoughts for choosing "my" method over omnidirectional shadow maps (through cubemaps)
-can devote a much higher percentage of each shadow map to the shadow casters
-no "compression" needed to store depth (because of lack of depth shadow maps)
-by simply extending the frustum you can collide it with the view frustum and cull shadows easily (you can cull cube faces of the cubemap, but considering shadow casters may span cube borders, you end up not culling as many objects) (though there are more tests to this per object method)
-i plan on having a low number of shadow casters (this may change, but for now its the case)

I suppose I wouldnt mind hearing some discussion on this topic

just my two cents
cheers
-Dan

[Edited by - Ademan555 on June 24, 2005 5:05:44 PM]

##### Share on other sites

This topic is 4555 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628676
• Total Posts
2984179

• 13
• 12
• 9
• 10
• 10