Bounding box transforms

Started by
9 comments, last by RobM 10 years, 5 months ago
I was just wondering about bounding boxes and the best way to keep track of them in terms of the transformation of the object they are bounding.

When I add a mesh to my world, I currently just create a bounding box from the local extents of the mesh (at some point this will obviously be pre-computed). When I come to frustum cull this bounding box, should I transform it by the same transform that the object has? Only that's 8 extra transforms. I can't move the box to fit around the world positions of the object as that would obviously be too slow.
Advertisement

Why would it be slow? Transforming a mesh of 8 coordinate-only vertexes is negligible, and it would 'move the box to fit'. More importantly, why are you doing frustum culling manually?

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

More importantly, why are you doing frustum culling manually?

What do you mean manually?

Oh. Ninja'd.

I mean isn't there hardware support for frustum culling? What api are you using?

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

I think all frustum culling is done on the CPU. I never read anything about frustum culling on GPU.

Eh? My mistake, the platform I learned on had hardware culling, but poking around it looks like that's not present in DX or OGL. That actually surprises me, since the GPU could easily optimize it so well, though it does mean that you have to run everything across the bus.

Anyway, just running a cube through a transform is really very lightweight. Possibly you could do a point/radius test by applying your scale to your radius and then just translating the center point, but if you do any uneven scaling or shearing then that wouldn't work.

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

You'd have to get the data back from the GPU as well, unless you sent all the vertices to be transformed across the bus, which frustum culling is trying to avoid. GPUs work best by being given a lot of data to operate on with no branching. The most extreme example of that was on the PS2 where the GPU didn't like back face culling, it was usually quicker to draw everything double sided than check for back faces ;)

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley
I think I've kind of answered my own question, but thanks for the replies. I've never heard of frustum culling on the GPU either - you're not confusing it with clipping are you? That happens on the GPU

Talking to seg in the chat, realized that I was thinking about clipping rather than culling. My bad.

Edit: ninja'd again. lol

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

In a normal setup you have a source object/model which is then shared by all the instances of that model in the game world.

The shared model will have the base bounding box and bounding sphere and each instance will have its own copy, updated when that object’s transform changes, to reflect its real world bounding box. As few objects in a game scene actually move this is not very expensive.

Frustum culling is then done on the transformed bounding boxes as they are.

L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

This topic is closed to new replies.

Advertisement