Oriented Bounding Box

#1 I made fish swim by making a 10x10x10 bounding box in the FishBody datablock and reducing their mass to 1 (produces a nice random look to their movements), it seems to work pretty good.

#2 It's a good idea but I need the oriented box because I'll be having the player character swimming and he's longer than he is wide when swimming, and I also need to not have the box be AA because I will be rotating him on the X axis to pitch him up and down - the collision needs to take that into account as well.

#3 Ohh I see you mean like this?

http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=4348

#4 That's the resource I implemented, but it suffers from the problem I describe. :(

#5 I need the exact same help.

#6 Using an oriented bounding box will give you problems too, sorry.

The demo's player collision code wasn't made with rotations in mind, so you will get bugs while rotating nearby other objects (passing thru them or getting stuck).

Since I *need* non-uniform bounding boxes with rotation support for my game, I'll try to modify the whole player collision stuff to use a rigid instead of a boxConvex.

The rigid class and the collision code in the vehicle classes fully support rotations while solving collisions, so it's just a matter of feeding the rigid a linearVelocity and angularVelocity based on the resulting mVelocity and rotation offset. Maybe I'll also need to remove all that momentum stuff so the player won't bounce around like a vehicle does, and simplify the collision response so the rigid just stops moving/rotating at collision point, with no new forces being applied (to keep the player from probably tripping and falling on the ground - but it would be funny).

#7 Here's another interesting issue: I placed some Con::errorF calls into the first lines of player::buildPolyList and player::buildConvex to try and figure out the exact order of calls, but oddly enough, neither are ever called... yet if you remove them, no more collision.

#8 They are called - they are the key methods responsible for collision...

#9 Yeah, as I said, they _have_ to be called, because if you remove them, no more collision. It's just baffling that calls to Con::errorf placed at the very first line of those functions do nothing.

#10 Btw, Ben, any clue on how I can change the engine to use OBB? It seems like Box3F is hardwired to be AABB only.

#11 If I create a version of Box3F that stores the actual corner coords instead of a center and min/max, and utilize this new class in Player::buildConvex and Player::buildPolyList, being sure to transform it by the players rotation, would that work?

Thought I'd ask before I go spend some more time on it. ;)

Edit: You think spelling would be a strong suit for a programmer...

#12 Well, if all you care about is the raycast, you don't have to modify them, right? As for example implementations, I'd suggest checking out, ah, TSStatic, ShapeBase, Interior, and Terrain's implementations.

You can get the corner positions out of Box3F pretty easily. Hmm. Wait, it stores the min/max. You have to do work to get the center/extents out of it. Overall this works pretty well (there's no clear win to be had by changing it to be a center/extent structure, since half the time you want it one way and half the time the other way).

The Convex interface can support a true sphere, while the polylist has to return an approximation if that's what you want. Note that polylist is also used to cast shadows with.

#13 Thank you so much Ben. Back to work on the game. :)