Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to calculate a view/projection/bounding frustum for the 6 directions of a point light and I'm having trouble with the views pointing along the Y axis. Our game uses a right-handed, Y-up system. For the other 4 directions I create the LookAt matrix using (0, 1, 0) as the up vector. Obviously that doesn't work when looking along the Y axis so for those I use an up vector of (-1, 0, 0) for -Y and (1, 0, 0) for +Y. The view matrix seems to come out correctly (and the projection matrix always stays the same), but the bounding frustum is definitely wrong. Can anyone see what I'm doing wrong?

This is the code I'm using:

camera.Projection = Matrix.PerspectiveFovRH((float)Math.PI / 2, ShadowMapSize / (float)ShadowMapSize, 1, 5);

for(var i = 0; i < 6; i++)
    var renderTargetView = shadowMap.GetRenderTargetView((TextureCubeFace)i);
    var up = DetermineLightUp((TextureCubeFace) i);
    var forward = DirectionToVector((TextureCubeFace) i);

    camera.View = Matrix.LookAtRH(this.Position, this.Position + forward, up);
    camera.BoundingFrustum = new BoundingFrustum(camera.View * camera.Projection);

private static Vector3 DirectionToVector(TextureCubeFace direction)
    switch (direction)
        case TextureCubeFace.NegativeX:
            return -Vector3.UnitX;
        case TextureCubeFace.NegativeY:
            return -Vector3.UnitY;
        case TextureCubeFace.NegativeZ:
            return -Vector3.UnitZ;
        case TextureCubeFace.PositiveX:
            return Vector3.UnitX;
        case TextureCubeFace.PositiveY:
            return Vector3.UnitY;
        case TextureCubeFace.PositiveZ:
            return Vector3.UnitZ;
            throw new ArgumentOutOfRangeException("direction");

private static Vector3 DetermineLightUp(TextureCubeFace direction)
    switch (direction)
        case TextureCubeFace.NegativeY:
            return -Vector3.UnitX;
        case TextureCubeFace.PositiveY:
            return Vector3.UnitX;
            return Vector3.UnitY;

Edit: Here's what the values are coming out to for the PositiveX and PositiveY directions:


Position = {X:0 Y:360 Z:0}
camera.Projection = 
    [M11:0.9999999 M12:0 M13:0 M14:0]
    [M21:0 M22:0.9999999 M23:0 M24:0]
    [M31:0 M32:0 M33:-1.25 M34:-1]
    [M41:0 M42:0 M43:-1.25 M44:0]


up = {X:0 Y:1 Z:0}
target = {X:1 Y:360 Z:0}
camera.View = 
    [M11:0 M12:0 M13:-1 M14:0]
    [M21:0 M22:1 M23:0 M24:0]
    [M31:1 M32:0 M33:0 M34:0]
    [M41:0 M42:-360 M43:0 M44:1]

    Matrix =
    [M11:0 M12:0 M13:1.25 M14:1]
    [M21:0 M22:0.9999999 M23:0 M24:0]
    [M31:0.9999999 M32:0 M33:0 M34:0]
    [M41:0 M42:-360 M43:-1.25 M44:0]

    Top = {A:0.7071068 B:-0.7071068 C:0 D:254.5584}
    Bottom = {A:0.7071068 B:0.7071068 C:0 D:-254.5584}
    Left = {A:0.7071068 B:0 C:0.7071068 D:0}
    Right = {A:0.7071068 B:0 C:-0.7071068 D:0}
    Near = {A:1 B:0 C:0 D:-1}
    Far = {A:-1 B:0 C:0 D:5}


up = {X:0 Y:0 Z:-1}
target = {X:0 Y:361 Z:0}
camera.View = 
    [M11:-1 M12:0 M13:0 M14:0] 
    [M21:0 M22:0 M23:-1 M24:0] 
    [M31:0 M32:-1 M33:0 M34:0] 
    [M41:0 M42:0 M43:360 M44:1]

    Matrix =
    [M11:-0.9999999 M12:0 M13:0 M14:0]
    [M21:0 M22:0 M23:1.25 M24:1]
    [M31:0 M32:-0.9999999 M33:0 M34:0]
    [M41:0 M42:0 M43:-451.25 M44:-360]

    Top = {A:0 B:0.7071068 C:0.7071068 D:-254.5585}
    Bottom = {A:0 B:0.7071068 C:-0.7071068 D:-254.5585}
    Left = {A:-0.7071068 B:0.7071068 C:0 D:-254.5585}
    Right = {A:0.7071068 B:0.7071068 C:0 D:-254.5585}
    Near = {A:0 B:1 C:0 D:-361}
    Far = {A:0 B:-1 C:0 D:365}

When I use the resulting BoundingFrustum to cull regions outside of it, this is the result:

Pass PositiveX: Drew 3 regions
Pass NegativeX: Drew 6 regions
Pass PositiveY: Drew 400 regions
Pass NegativeY: Drew 36 regions
Pass PositiveZ: Drew 3 regions
Pass NegativeZ: Drew 6 regions

There are only 400 regions to draw and the light is in the center of them. As you can see, the PositiveY direction is drawing every single region. With the near/far planes of the perspective matrix set as small as they are, there's no way a single frustum could contain every single region.

share|improve this question
I thought a point light went in all directions? – Polar Mar 18 '13 at 21:40
@Polar It sounds like the OP is doing omnidirectional shadow mapping, with cube shadow map and a frustum for each face. – Nathan Reed Mar 18 '13 at 22:40
Yea, that's exactly what I'm doing Nathan – Telanor Mar 18 '13 at 23:22

This is not a direct answer to your question, but may be a possible alternative with some added benefits.

You seem to be trying to generate a frustum bounding box so you can do some frustum culling before generating each face of a cubic shadow map. If you were to switch to using dual-paraboloid shadow maps you will get a performance gain by only using 2 render calls to generate the shadow map rather than 6.

The other benefit, which relates more to the question, is that culling is now a process of detecting whether an object is at the back, at the front or intersecting the plane which divides the two hemispheres of your dual-paraboloid shadow maps.

share|improve this answer
I've tried implementing that technique before unsuccessfully. I may try again in the future, but it does have a downside of creating seams. I'd like to try getting this basic method working first though. – Telanor Mar 27 '13 at 4:37
If doing the shadow map generation in a geometry shader, only one set of render calls is required (and you can frustum cull in a GS too) but this depends on what DX version the OP is targetting (I assume 10+ but confirmation would be nice). – 21st Century Moose Sep 23 '13 at 19:47

According to the MSDN documentation, the BoundingFrustum constructor only takes Left-Handed projection matrices:

share|improve this answer
I'm using SharpDX which has its own BoundingFrustum class. The documentation doesn't say whether it takes left or right handed matrices, though I have used it elsewhere and it seemed to work fine. – Telanor Mar 19 '13 at 21:24
That code is also based on DirectX's left-handed coordinate system, derived from this paper. – Mokosha Mar 20 '13 at 0:30
To follow up, there is a very interesting discussion about this topic at the Real-Time Rendering Blog – Mokosha Mar 20 '13 at 0:58
Hmm, the equations do indeed match that paper exactly, but the paper doesn't specify if its for left or right handed. It does mention OpenGL though, which seems to be right handed. In any case, I tried switching to the left-handed view/perspective matrix constructors and still got the same result. – Telanor Mar 20 '13 at 4:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.