Here's a snippet that shows how to calculate the current Frustrum.
It assumes that the View and Projection transforms have been applied, and that the World transform is Identity.
Code is untested, I just wanted to record this snippet in the Public Domain for the sake of those few who might be interested in performing Frustrum Culling in their D3D apps in the near future.

;The following example shows calculation of the Camera View Frustrum in terms of World Space.
;If we wanted Camera Space (aka world and view matrices are Identity) we use matProjection only.
;If we wanted World Space (only world matrix is Identity) we use this code, ie projection and view.
;If we wanted Object Space we would concatentate the World, projection and view matrices.

FrustumUn D3DXVECTOR3 <-1.0f, -1.0f, 0.0f>
D3DXVECTOR3 < 1.0f, -1.0f, 0.0f>
D3DXVECTOR3 <-1.0f, 1.0f, 0.0f>
D3DXVECTOR3 < 1.0f, 1.0f, 0.0f>
D3DXVECTOR3 <-1.0f, -1.0f, 1.0f>
D3DXVECTOR3 < 1.0f, -1.0f, 1.0f>
D3DXVECTOR3 <-1.0f, 1.0f, 1.0f>
D3DXVECTOR3 < 1.0f, 1.0f, 1.0f>

class CCamera
void CalcFrustrum
des viewMat D3DXMATRIX
des projMat D3DXMATRIX
array Points,D3DXVECTOR3,8
array Planes,D3DXPLANE,6

;This procedure is to be called AFTER the camera view has changed.
;It calculates the current Viewing Frustrum using the current view and projection matrices.

CCamera_CalcFrustrum proc uses ecx
local mat:D3DXMATRIX
local ppt0, ppt1, ppt2, ppt3, ppt4, ppt5, ppt6, ppt7:DWORD
local me:DWORD
mov me,ecx

lea eax,[ecx].CCamera.Points ;First set up some lazycoder local pointers
mov ppt0,eax
add eax,sizeof D3DXVECTOR3
mov ppt1,eax
add eax,sizeof D3DXVECTOR3
mov ppt2,eax
add eax,sizeof D3DXVECTOR3
mov ppt3,eax
add eax,sizeof D3DXVECTOR3
mov ppt4,eax
add eax,sizeof D3DXVECTOR3
mov ppt5,eax
add eax,sizeof D3DXVECTOR3
mov ppt6,eax
add eax,sizeof D3DXVECTOR3
mov ppt7,eax

;Calculate the inverse matrix of the combined view and projection matrices
invoke D3DXMatrixMultiply, addr mat, addr [ecx].CCamera.viewMat, addr [ecx].CCamera.projMat
invoke D3DXMatrixInverse, addr mat,NULL, addr mat

;Transform the untransformed boundingbox of the Frustrum by the inverse view/projection
xor ecx,ecx
.while ecx<8
push ecx
mov eax,sizeof D3DXVECTOR3
mul ecx
lea esi,FrustrumUn
add esi,eax
mov ecx,me
invoke D3DXVec3TransformCoord, addr [ecx+eax].CCamera.Points,esi, addr mat
pop ecx
inc ecx

;Now calculate the planes of the new Frustrum boundingbox
mov ecx,me
lea edi,[ecx].CCamera.Planes
mov pPlane,edi
invoke D3DXPlaneFromPoints, pPlane, ppt0, ppt1, ppt2 ;Near
add pPlane,sizeof D3DXPLANE
invoke D3DXPlaneFromPoints, pPlane, ppt6, ppt7, ppt5 ;Far
add pPlane,sizeof D3DXPLANE
invoke D3DXPlaneFromPoints, pPlane, ppt2, ppt6, ppt4 ;Left
add pPlane,sizeof D3DXPLANE
invoke D3DXPlaneFromPoints, pPlane, ppt7, ppt3, ppt5 ;Right
add pPlane,sizeof D3DXPLANE
invoke D3DXPlaneFromPoints, pPlane, ppt2, ppt3, ppt6 ;Up
add pPlane,sizeof D3DXPLANE
invoke D3DXPlaneFromPoints, pPlane, ppt1, ppt0, ppt4 ;Down
CCamera_CalcFrustrum endp
Posted on 2004-01-20 02:03:53 by Homer
Perhaps you can post it on Thomas's snipplet library? He maintains a snipplet library on his site
Posted on 2004-01-20 05:55:14 by roticv
Well I would, but his site has no uplink for posting, and doesn't seem conducive to public postings, maybe he could alter his layout, but then he's have to actually monitor the incoming posts to determine which were worth keeping, and which were just junk I suppose... however, he might change his mind if he though people would contribute useful code... besides, anyone interesting in asmcoding is likely to run into this forum before they find a link to his site...
Posted on 2004-01-20 08:58:59 by Homer
That method sucks, here is a better one:
It's faster and more stable.
Oh and it's frustum, not frustRum.

Oh, and f0dder says I can't say your method sucks... Why not? I'll be banned anyway, who cares. That's how this Nazi-board works... You get banned everytime hutch says something stupid... Which is all the time.
When you try to help, nobody values it anyway, nobody is friendly to you anyway, so why be friendly to anyone else?
Fuck it.
Posted on 2004-01-20 17:56:57 by Jan
Hey thanks for the feedback.
I had actually come across a link to that document somewhere else, however after speedreading it once, I came to the following two conclusions: both are similar in that they rely on the precalculation of a combined matrix, but the "faster" method does not yield the boundingbox itself in terms of its vertices in world coordinates, which is so critical to me - it's a fast way of extracting planes only, leaving me some work to extract the vertices themselves, which pretty much evens them in terms of execution speed at a guess. So I guess in terms of non axially aligned bounding boxes, the fast planes extraction is the one that sucks.
I can't guarantee my frustRum will always be axially aligned, and I prefer the tightest-fit model. Which brings me to the term frustRum. Obviously, frustum is one of those butchered Americanisms of the English language, but I guess both are acceptable. I was taught frustrum, and a quick search for the term reveals its historical use with a second R, and its modern use with both, or just one R.
I'll continue to use the second R, and if you don't like it, you can run my source through an American spellcheck :tongue:
No offence was taken, as I am sure none was meant :)
As for the gestapo elements around here, I have no real comment since they don't bother me personally, and don't appear to shoo away newbs in general, maybe familiarity does breed contempt .. heh.
Posted on 2004-01-20 22:11:29 by Homer
Why would you need the vertices? You can do frustum culling by checking against the planes.
And what I don't see is how axis-alignment has anything to do with it.
The plane-extraction will just get the 6 frustum planes from the compound matrix.
There's no issue of axis-alignment or not, or tightest fit or not...
You just get the exact frustum planes, however the frustum is transformed, in any space. So you can do the culling in whatever space is most convenient. I generally find object-space msot convenient, because then you don't have to transform your bounding volume, which means it's very easy to support non-uniform scaling and translation.
Posted on 2004-01-21 02:36:48 by Jan
I guess maybe you missed my point then :)
Axially-aligned boundingboxes are fine for performing plane-based culling of geometry against a single boundingbox.
Imagine now a situation where we have two boundingboxes, lets call them BB1 and BB2. BB1 is axially aligned, and BB2 is rotated by 45 degrees on two axes to form a diamond shape. One corner of BB2 intersects BB1. Don't you think it makes sense to perform a test of all POINTS of BB1 against all PLANES of BB2 (or vice-versa)? We can determine partial occlusions this way. Note that I don't want to simply test geometry against the frustrum boundingbox, I want to test boundingboxes against boundingboxes in the same way as used in hierarchical bounding volumes used in the newer model of osp, and cannot make the assumption that those boxen are aligned in any way. Am I making sense? :)
Posted on 2004-01-21 02:45:57 by Homer
Not really, box-to-box checking is probably easiest by using half-axis vectors for the BB of the object and the planes of the frustum. There is a decent algorithm for it, but sadly the name escapes me at this time.
In general I always keep the frustum as a set of planes, and the bounding volumes of the objects are in a 'handy' format. Either sphere (center and radius) or box (center and half-axis vectors), usually.
Since you can get the frustum planes in object-space without much effort, you can simply do all frustum checks in object-space, without requiring any transforms to the sphere or box whatsoever, making it simple, fast and robust.
So what is your point?

Besides, you specifically said your code was for calculating the bounding box of the frustum, which the plane-extraction paper does in a more efficient and more stable way..
So I don't really care how you try to defend your unrelated BB-stuff now. It's not relevant.
Posted on 2004-01-21 03:00:54 by Jan
Bleargh at your bitching... you can't use a half-axis method on a deformed boundingbox such as a transformed frustrum. You did mention that you prefer to do this in object space, which implies that not one, not two but all three major transforms have been applied. I can't assume that bounding boxes will always be cubes any more than I can assume they will have coplanar symmetry - my bounding boxes can be any shape that can be afforded by eight vertices.
If you know of an algo which precludes this logic and is applicable in all cases, sure I'd love to hear it. As for politics... I'd vote for hiro or hutch before any of the candidates I have to choose from...
Posted on 2004-01-21 06:19:34 by Homer
You bring it onto yourself scali. If you'd actually behave and not insult people then I would not care that you'd be a member (even if I would know you'd have registered). Yet somehow, you deem it fit to throw insults at people right from the start. No doubt such behaviour is tolerated on "Scali's DX messageboard" but not here and you've known that for a few years already.

It's all very simple: behave -> you can post, act like a child and insult people -> you get banned.
Posted on 2004-01-21 06:42:54 by Hiroshimator
you can't use a half-axis method on a deformed boundingbox such as a transformed frustrum.

I think you are missing the point.
The frustum is NOT a bounding-box defined by half-axis vectors.
The frustum is ALWAYS a set of 6 planes... By definition your frustum is always a (perspective) deformed cube, so therefore all faces of the cube are still planar, and it can ALWAYS be represented by 6 planes (which does not necessarily have to be a box, obviously).

And since you are able to get these planes in any space you want, including object-space, you can use the half-axis vectors of the bounding box of the OBJECT in object-space, meaning that you can simply form the bounding box in object-space, and use it as-is, and test each vector against the planes of the frustum.
This is quite trivial stuff, really. You might want to get a clue.

my bounding boxes can be any shape that can be afforded by eight vertices.

You mean you even have deformed boxes in object-space? Then they're not boxes anyway, are they? What the hell are you talking about anyway? You mean you have convex hulls of 6 planes or something?

If you know of an algo which precludes this logic and is applicable in all cases, sure I'd love to hear it.

If you mean frustum vs AABB/OOBB, I already gave it, you just didn't get it.
If you mean arbitrary convex hulls, perhaps you should re-think your strategy, these are considerably less efficient. And don't call them boxes then!

act like a child and insult people -> you get banned.

Then by all means, ban hutch... Obviously he was full of shit about the SGI stuff (yes they use Taiwanese Terrors! ATi GPUs!), and he only started a flamewar, which he blamed on me. HE should be banned, then I can behave because I won't be provoked and blamed for things I didn't cause. THINK damnit
Posted on 2004-01-21 06:45:57 by Henk
Thanks for your insight anyway, it's always refreshing to hear another point of view.
My issue with BB's defined by planes AND points stems from my translation of the doxygene engine (or whatever the hell it's called) which uses that in its CBoundingBox class, and in all the math therein. They test for intersections of point and plane, line and plane (just two point checks) and plane and plane, etc. Now I see what you were driving at, and I think you are right about this. Now take a deep breath and relax, I'm not an idiot, and I'm glad I didn't have you as a math teacher in my school days :)
Posted on 2004-01-21 07:26:32 by Homer
Now take a deep breath and relax, I'm not an idiot, and I'm glad I didn't have you as a math teacher in my school days

Perhaps it's a blessing in disguise, after all, you DO learn in the end :)
I just don't really get the smugness of most asm-coders... They think they know everything, and won't accept it if you present a better method...
Also, if you just look at your box... You defined points with only 1, -1 and 0...
Now I don't know about you, but when I see such numbers, and multiplies are involved, I realize that these can only translate in add, sub or nop operations... Therefore, you can optimize them considerably... Which is how the plane-extraction came to life... It (ab)uses the properties of the viewing volume in post-projection space.
Especially asm-coders should have an instinct for picking up this sort of stuff, after all, you code asm because you want to get faster and smaller code, right? Then start by optimizing your algorithms!
Posted on 2004-01-21 09:13:31 by Henk-Jan