Heya - need to know if theres a quick way to rotate Planes which have been defined via the Plane Equation.. I'd like to implement RavenSoft's fast frustrum plane extraction algo, but I'm concerned about how to go about transforming a boundingbox that's only been defined by Planes...

I know if I keep vertices as WELL as planes, I can transform the vertices of the BB and re-establish the planes from there. Can I avoid this nastiness and transform the Planes without vertices? This would do away with the need to recalculate them, I could just transform a Master...

I know if I keep vertices as WELL as planes, I can transform the vertices of the BB and re-establish the planes from there. Can I avoid this nastiness and transform the Planes without vertices? This would do away with the need to recalculate them, I could just transform a Master...

Firstly, you never have to rotate the planes, you can just extract the frustum from the space you want, by concatenating the right matrices before extracting the planes, which I already mentioned a few times before. Please try to think along when someone tries to explain something. This should be the most efficient and robust way.

Secondly, if I am not mistaken, a simple 4x4 homogenous transform will work on the 4d homogenous vector that is the plane. You will need the transpose inverse (or inverse transpose, whichever is more economic to generate at the time) of the 'regular' transform matrix for this, just like with 3d vectors.

Thirdly, you still don't seem to understand the difference between a frustum and a bounding box.

Secondly, if I am not mistaken, a simple 4x4 homogenous transform will work on the 4d homogenous vector that is the plane. You will need the transpose inverse (or inverse transpose, whichever is more economic to generate at the time) of the 'regular' transform matrix for this, just like with 3d vectors.

Thirdly, you still don't seem to understand the difference between a frustum and a bounding box.

I guess I'll have to post some code before I rant any further - my situation is that I have a lot of objects each with their own transform matrix, and a frustum thats defined by the projection and view matrices - at the moment it sounds like you are telling me I should be re-extracting the frustum planes at the last moment in the context of each object - which sounds silly.

I admit I see little difference between a boundingbox and a frustum - they're handled very similarly, its only the fact that the frustum hinges on the proj and view matrices that distinguishes them.

btw I did find a couple of algos for applying a 4x4 transform to an empirical Plane, and they worked by transposing the plane equation to solve it as a differential equation.

I admit I see little difference between a boundingbox and a frustum - they're handled very similarly, its only the fact that the frustum hinges on the proj and view matrices that distinguishes them.

btw I did find a couple of algos for applying a 4x4 transform to an empirical Plane, and they worked by transposing the plane equation to solve it as a differential equation.

I think what I'm trying to say is that I'll need to transform the untransformed frustrum by the inverse of the transform matrix that is applied to any given object's boundingbox, sound right?

The alternative is to transform the object and its boundingbox, and then extract the frustrum planes in the context of the transformed object, which means RE-extracting the frustrum planes for EACH object.

If I call the first method mine, and the second method yours, then I must say yours wouldn't suit high numbers of entities.

That being said, its fine to use that method for culling, particularly if the cull is hierarchical, but its definitely not useful for comparative math like collision detection between A and B where A and B are BOUNDINGBOXES DEFINED BY PLANES.

I'm looking at re-using the cull selection code for generic box intersection testing where boxes are defined by a set of planes and a transform matrix.

In other words yes, I AM treating the frustrum as just another box for purposes of intersection testing, because I hope to use the same codebase to compare any two boundingboxes against each other. This seems to be standard practise, as evidenced in CBoundingBox and CCullableThing classes.

The alternative is to transform the object and its boundingbox, and then extract the frustrum planes in the context of the transformed object, which means RE-extracting the frustrum planes for EACH object.

If I call the first method mine, and the second method yours, then I must say yours wouldn't suit high numbers of entities.

That being said, its fine to use that method for culling, particularly if the cull is hierarchical, but its definitely not useful for comparative math like collision detection between A and B where A and B are BOUNDINGBOXES DEFINED BY PLANES.

I'm looking at re-using the cull selection code for generic box intersection testing where boxes are defined by a set of planes and a transform matrix.

In other words yes, I AM treating the frustrum as just another box for purposes of intersection testing, because I hope to use the same codebase to compare any two boundingboxes against each other. This seems to be standard practise, as evidenced in CBoundingBox and CCullableThing classes.

Maybe I'd be best to phrase my question with pseudocode.

It pertains to where the world transform fits into the picture.

Thing struct

pPosition vec3 <>

pRotXY float ?

pRotXZ float ?

pRotYZ float ?

pCMesh dd ?

localmat MATRIX4 <>

pPlanes D3DXPLANE 6 dup(<>)

Thing ends

LPTHING typedef ptr thing

apThings LPTHING 50 dup (?) ;array of ptrs to Things

Assume we load 50 Things and store pointers to their structs in an array.

For each Thing, we calculate a yawpitchroll matrix and a translation matrix, multiply them and store the combined world transform matrix for the object in localmat.

Then we calculate the bounding planes of the Thing's mesh and store the boundingbox for the thing just as 6 planes.

Now imagine we have camera code already working, and now we are inside the Render code, where the View and Proj matrices have already been applied.

We enter a loop to render our 50 Things.

If we were not culling, we'd save the world transform, apply the object local transform, render it, then restore the world transform and loop.

Now we are culling, should we apply the world transform for an object , then extract the frustrum planes (so extraction of planes occurs per object) , culltest/render then restore world transform and loop,

or should we extract the frustrum planes once, then begin our loop : transform the object, transform the planes (including frustrum),culltest/render, restore and loop?

If I was to add object bounding vertices, is it faster to test intersections of a set of corner vertices/planes and a set of planes, or u think object planes versus frustrum planes is going to end up faster for box to box testing? I'm expounding on the notion that planes alone suffice to describe any box...

It pertains to where the world transform fits into the picture.

Thing struct

pPosition vec3 <>

pRotXY float ?

pRotXZ float ?

pRotYZ float ?

pCMesh dd ?

localmat MATRIX4 <>

pPlanes D3DXPLANE 6 dup(<>)

Thing ends

LPTHING typedef ptr thing

apThings LPTHING 50 dup (?) ;array of ptrs to Things

Assume we load 50 Things and store pointers to their structs in an array.

For each Thing, we calculate a yawpitchroll matrix and a translation matrix, multiply them and store the combined world transform matrix for the object in localmat.

Then we calculate the bounding planes of the Thing's mesh and store the boundingbox for the thing just as 6 planes.

Now imagine we have camera code already working, and now we are inside the Render code, where the View and Proj matrices have already been applied.

We enter a loop to render our 50 Things.

If we were not culling, we'd save the world transform, apply the object local transform, render it, then restore the world transform and loop.

Now we are culling, should we apply the world transform for an object , then extract the frustrum planes (so extraction of planes occurs per object) , culltest/render then restore world transform and loop,

or should we extract the frustrum planes once, then begin our loop : transform the object, transform the planes (including frustrum),culltest/render, restore and loop?

If I was to add object bounding vertices, is it faster to test intersections of a set of corner vertices/planes and a set of planes, or u think object planes versus frustrum planes is going to end up faster for box to box testing? I'm expounding on the notion that planes alone suffice to describe any box...