Okay, so, I've been doing reading on some sites for physics stuff, especially gamasutra (great site once you take the time to register). I've realized that there is no 'swept volume' equivalent for calculating collisions for objects that rotate. The article that discusses the hitman physics says that each limb is enclosed in a cylinder, and that the collision detection is done via a cylinder to mesh overlap test. I can see why the overlaps are done because I cannot think of any kind of "exact" method for calculating a collision for something such as a machine arm pivoting, or something like that which rotates. Here is what I want your opinions on: I've thought up of a what I think is a fairly original method for handling objects that rotate. The project is a hovertank game, and so far I've actually implemented realistic physics with linear impulses, conservation of linear momentum, linear friction is applied, coefficient of restitution for specific cases, etc, and this is all handled with a simple euler integrator with a fixed timestep. My idea is that I enclose each object with an 'absolute' bounding box, such that the object can rotate and always stay inside the box. When two objects collide, I handle the rotations by calculating where their absolute bounding collide by treating their boxes as brushes. I have this, and it works fine (I use brush collision detection to calculate collisions with the world as well, and I quite like the brush coldet algorithm for some reason). I then take the bounding box of object A, and calculate where exactly on the mesh it hits object B. I would then run the same test onto object A, and from this data the torque would be produced. Obviously, the object meshes never *really* touch each other, but it will still produce both linear and angular impulses. When I want a torque to be produced when an object hits the world, I am going to just create a 'fake' object that has a bounding box of the same dimensions as the object itself, and trace it from the outside of the bounding box against the actual mesh of the object itself. So, yeah, I know I just wrote a lot, but what do you guys think? I don't like the idea of doing overlap/penetration tests. I am hoping that if I implement it, it will be convincing enough. EDIT: and the most obvious scenario that this method would not work too well on is when two objects which are rotating in the opposite directions hit each other, because in reality they DONT hit each other, because nothing is allowed to enter the 'absolute bounding box'. [edited by - shadow12345 on May 20, 2004 11:57:12 AM] [edited by - shadow12345 on May 20, 2004 11:59:16 AM]

For the overall bounding box on an object, doesn''t this make a bounding box on an oblong object unnecessarily huge?

Think of a long, thin pencil (i.e. an object elongated in only one dimension). Now you need to take the longest dimension and make your bounding box that big in all dimensions to cover any rotational case of the pencil, correct?

Or did I totally miss what you meant?

Regards,
Jeff

[ CodeDread ]

Yes it does. The point of that bounding box is such that when something hits it, or the pencil moves and hits the world, then I know that I have to perform a more exact test to see where exactly on the mesh the object was hit.

I think you understood what I was saying exactly.

And let me just re-iterate what would happen when the pencil would hit the world: I would just create another bounding box with the same size as the pencil's absolute bounding box, and then send that against the mesh of the pencil to see where it hit.

I am going back and forth between my idea, and just using an object oriented/aligned bounding box with overlap/penetration tests.

EDIT:
it is just really hard describing what I mean because it seems as if it has not been implemented anywhere else.

[edited by - shadow12345 on May 20, 2004 3:11:26 PM]

well, the purpose of the bounding volume, whether it be a box or sphere, is just used so that I know when a more exact test is needed. If the bounding box hits the world, then I would determine what side of the box hit the world, then I would place a box of the same dimensions on the side that hit the world, and trace from the new box to the mesh of the actual object that is being moved. Nothing is allowed in the bounding region except the actual object itself (which, in this case, would be a hovertank).

The reason I don''t like the idea of the overlap / penetration tests is that it seems too easy for the collisions to be totally missed, i.e it only works when the object is moving slow enough for a given timestep (otherwise you get the timestep problem where objects pass through each other without having overlapped on any given frame). It also seems too difficult to resolve the line of action for a given collision, and that it is prone to many errors (with my method, an exact collision normal would be found because ultimately a ray trace is performed against the actual meshes of the objects).

Im just wondering, what have YOU guys used for this type of scenario? I assume most of you just do overlap/penetration tests.

that sounds like a good way to go...even in professional games there are always small 'glitches', well, they're not really glitches, but problems like that where a part of an object can go outside of the world, because the bounding volume doesn't exactly fit the geometry (you can see this in hitman, because every volume is actually a cylinder).
EDIT:
I've got a specific question for you:
what happens when the frame time is less than the time given for a tick?

[edited by - shadow12345 on May 21, 2004 1:33:04 PM]

It sounds like a great idea to me. However I''ve just had another idea...
You may be able to do excellent collision with a rotating object if you convert everything into polar coordinates relative to your rotating body. This would require a totally new set of ray-tracing or collision type of functions that work in polar coordinates though. I can see how this should be do-able though and it would look totally kick-ass!
It could be a bit hard to make them work like those swept-sphere etc type of functions.