   Frustum culling with spheres - lil help?
  I'm at a loss as to why my frustum culling (based on spheres and the 6 planes method) is not working properly.  The near plane clipping works fine, and probably the far plane (but I haven't tested that), but the left/right/top/bottom plane tests are not working correctly.I'd appreciate it if someone could check over my plane generation and testing code to ensure I'm doing it right.  I'm a little hazy on how the planes are constructed from the view/projection matrices, but the code seems to match up to those in books/on the web...The plane construction:D3DXMATRIX VP = viewMatrix * projMatrix;vec4 col0(VP(0,0), VP(1,0), VP(2,0), VP(3,0));vec4 col1(VP(0,1), VP(1,1), VP(2,1), VP(3,1));vec4 col2(VP(0,2), VP(1,2), VP(2,2), VP(3,2));vec4 col3(VP(0,3), VP(1,3), VP(2,3), VP(3,3));frustum[EF_Front] = (D3DXPLANE)col2;frustum[EF_Back] = (D3DXPLANE)(col3 - col2);frustum[EF_Left] = (D3DXPLANE)(col3 + col0);frustum[EF_Right] = (D3DXPLANE)(col3 - col0);frustum[EF_Top] = (D3DXPLANE)(col3 - col1);frustum[EF_Bottom] = (D3DXPLANE)(col3 + col1);for (int i=0; i!=6; ++i){D3DXPlaneNormalize(&frustum, &frustum);}This is called every time after updating the view matrix for a new camera position/direction.Then there's the frustum test:bool DXCamera::FrustumCheck(const vec3& pos, const float& radius){if (D3DXPlaneDotCoord(&frustum[EF_Front], &pos) < -radius)return false;if (D3DXPlaneDotCoord(&frustum[EF_Left], &pos) < -radius)return false;if (D3DXPlaneDotCoord(&frustum[EF_Right], &pos) < -radius)return false;if (D3DXPlaneDotCoord(&frustum[EF_Top], &pos) < -radius)return false;if (D3DXPlaneDotCoord(&frustum[EF_Bottom], &pos) < -radius)return false;if (D3DXPlaneDotCoord(&frustum[EF_Back], &pos) < -radius)return false;return true;}A simple plane/coord test against the bounding sphere radius.It's probably something really simple, but like I said, I'm a bit hazy on the plane construction code, so my guess is there's something wrong there.If anyone can see what I'm doing wrong, please tell me.Thanks.   
  A thought occurs to me...Is the code I listed above for a left handed coordinate system?  I think it is, but like I said, I'm a bit hazy on how we extract the data from the view*proj matrix.   ;  IMO you're forgetting the 4th member of the plane.if (D3DXPlaneDotCoord(&frustum[EF_Front], &pos) + frustum[EF_Front].d < -radius)    return false;Edit:NVM, D3DXPlaneDotCoord adds it.   ;  The frustum code looks OK to me, might be a problem with the matrices. From that source you can't tell if it's left handed or not.   ;  The view and projection matrices are both left handed, as the app has been developed as all left handed.Am I right in thinking that the planes taken from the view*proj will be in world space?  The position being sent into the frustrum check is in world space, which I think is correct.I stepped through the code and looked at the plane values and they all look normal.  The near plane points in the direction of the camera, and the side planes are pointing roughly 45 degrees inwards.  The far plane points back towards the camera.  The top/bottom planes point roughly down/up by 45 degrees.Stepping through, it seems only the near and far planes are behaving as expected.  The left/right planes are really screwed up, with seemingly random results.  The top/bottom planes never fail, even when the bounding spheres are well above or below the frustum.It has to be something simple and fundamental.  The code I listed above I'm sure is fine - it matches every bit of info I can find on frustum culling.  It must be something outside of that code, but I don't know what.  The position sent in is in world space, the planes are (I think) in world space, the sphere radii are all expected values.  I can't see what it is I'm missing.Is it perhaps something to do with the camera movement?  Perhaps the rotation of the camera isn't being accounted for somewhere?  But I'm pretty sure that info is taken from the view*proj matrix.   ;  Not sure about the plane's spaces, I passed the view and proj mats to the API I wrote back then when I was experimenting and then the world space coords of the sphere.Anyway, I got it working that time IIRC, if you want you can mess around with it, see if it works with mine. No guarantees thou.http://www.megaupload.com/?d=AMF3JENY   ;  Thanks for the code darkelf.  In the code, you have the following switch case enums:VFC_D3D_RMVFC_D3D_CMwhich determines the type of matrix being passed in, and hence which elements to extract.  The VFC_D3D_RM case extracts the planes in exactly the same way as the code I posted up top, so is VFC_D3D_RM a left-handed matrix?  And what does VFC_D3D_CM stand for?The code you have for the testing spheres against the frustum is identical to mine, albeit without the use of the D3DX functions.I tried using the code you had for the case section VFC_D3D_CM to extract the planes from my view*proj matrix, but the results were gibberish.  So I assume VFC_D3D_CM is for right handed matrices.   ;  No, it stands for row major and column major. D3DXMATRIX is row major by default. That's why you need 2 different extraction methods. I think the handedness of the matrices have nothing to do with it, it's only to determine if the Z axis is positive going into the monitor or negative. From the SDK docs:LeftHanded: zaxis = normal(At - Eye)RightHanded: zaxis = normal(Eye - At)That means only that they face the opposite direction should you render the frustum from a different viewpoint IMO.You'd use VFC_D3D_CM if you transposed your matrices, because for example you want column major packing in the shaders to do the calculations with dp4 instructions.Dunno what's the problem. You can try posting more code, the matrix inits, and where you update your matrices. One debug you can try is to render the frusutm.Google the equation for the intersection of 3 planes. You can read it in my code partly, but I am pretty sure it isn't  working, messed up something and forget what, so it's commented out. Once you got that, set the camera, get the 8 corners of the frustum cone using the intersection points. Now, use those to build the 6 faces of the cone with quads and render it but from a different viewpoint so you can actually see it. If you got a free moving FPS camera already, it's simple to just walk around the frustum, see if it looks correct.That's all the ideas I got now.   ;  Thanks for the help DarkElf.  The code used to build the matrices is very straightforward.  To build the proj matrix I use:D3DXMatrixPerspectiveFovLH(&worldMat, fovAngleRads, aspectRatio, nearPlaneDist, farPlaneDist);and to build the view matrix in the camera's update method I use:vec3 v3;Matrix m;switch(camType){case(ECT_RTS):m.Reset();m.Rotate(RTSTilt,RTSRot,0);v3 = vec3(0,0,-RTSzoom);v3.Transform(m);cameraPos = targetPos+v3;break;case(ECT_FPS):v3=vec3(0,0,1);m.Reset();m.Rotate(FPSrot.x, FPSrot.y, FPSrot.z);v3.TransformNormal(m);targetPos = cameraPos+v3*1000;break;}D3DXMatrixLookAtLH(&viewMatrix, &eyePos, &targetPos, &upVector);// cut out plane extraction code listed aboveIt's about as simple as it gets, so I doubt it's anything wrong there.  I'll look into your idea about rendering the view frustum with quads.;  Well, the rendering the view frustum idea tells us one thing - something is seriously screwed up...There are several issues.  First of all, if I place the camera at 0,0,1500 and the view target at 0,0,0 - the frustum looks like this:Only not exactly.  The frustum was placed in an inverted z position.  That is to say, the camera was at 0,0,1500, but the view frustum near plane was at 0,0,-1500.  Very peculiar.More worrying, if I place the camera at 0,0,-1500, the view frustum looks like this:(note - on both images I didn't bother rendering the top/bottom planes.  Nor did I bother working out the proper winding order - they are drawn without culling)As you can see in the second pic, the left/right planes are on the wrong sides, and probably facing outwards instead of in.  And the near plane seems to be upside down (looks like it's rotate 180 degrees around z) but the far plane seems to be the right way up. (which would probably explain the screwy left/right planes)Another weird thing is the far plane - the distance component of the far plane is saying it's 1500, which is the view target distance to camera, rather than the far clipping plane distance.  However, in rendering it, the far plane is drawn miles away from the near plane - so much so that it's always being clipped, even when I move the camera towards it for ages.And I have absolutely no idea why it's all so fubar.  My best guess is it's something to do with the reason why the frustum is starting at the z-opposite of the camera.  As if the z-component of the world (or maybe the view) is inverted somehow.Anyone have any ideas where to start looking?   