3D Collisions: Oriented Bounding Boxes! (Now: Ray casting?)

Seguer

Hey guys,

I have multiple oriented bounding boxes (yay) which can collide. Unfortunately, my collision reaction at the moment consists of:

1. Panic!
2. Inverse velocity
3. Inverse angular velocity
4. Hope no one notices

I've found a methodology for applying force (thrust/rotation) to an object based on a vector/etc, but I need some way of calculating where/how exactly that my OBBs collide - not just that they have.

Any ideas?

zilo

That's a complex problem. Box physics isn't trivial; what's the application?

Seguer

A 3D game engine I don't absolutely perfect physics, but if I could calculate the point at which they collide, I can go from there..

Hlubocky

I'm no expert at this, but if you are using bounding boxes instead of spheres, then you have multiple collision scenarios. It can collide at one point (like you mentioned), or it can collide on an edge (line), or on an entire face (plane). What I don't know is if there is some way to generalize this for physics engines or if you actually need to consider all of these different scenarios and apply forces in different ways depending on the type of collision. It seems using the billiard ball style of collisions is much easier...

Seguer

Yeah I may have overly complicated things unfortunately, but it really irks me that things don't "look right"

I discovered what seems to be the original "box physics" (rigid body physics) paper, as well as an XNA source solution, which works great. It's crazy, and I can't implement it. Luckily (somewhat?) our lecturer said we don't need to do this (out of scope - sent him an email).

All I'm trying to do now is to cast a ray from the position (center) of one object to another object's position (center).

Vector3 localPosition = Vector3.Transform(Position, other.OrientedBoundingBox.InverseRotation);
Vector3 localDirection = Vector3.TransformNormal(other.Position - Position, other.OrientedBoundingBox.InverseRotation);
Ray ray = new Ray(localPosition, localDirection);

This is apparently how you're meant to do it, but I then get a null float for that ray interescting the bounding box...

His Corkiness

Just taking a shot in the dark here.

Vector3 localPosition = Vector3.Transform(Position, other.OrientedBoundingBox.InverseRotation);

Is this meant to be using the other box's inverse rotation matrix, not its own?

Seguer

Yeah nevermind now. I'm going to change it completely. I did a whole ton of research and other collision testing and I'm going to change my 3D game to get rid of all this crazy need for crazy perfect collision response.

Thanks anyway guys!

shutz

Either use bounding spheres instead of boxes for collision detection, or if that's too imprecise, you can still use bounding spheres for collision detection, but then have a function that returns the normal to the surface that your projectile has hit, based upon the geometry of the object. This assumes you're calculating the collision between a small projectile and a large object with complex geometry. If you want to do collisions between two non-trivial solids, you're going to have to do per-polygon collision detection, which would probably be too much of a headache.

People wonder why video games still sometimes show clipping problems and objects going through one another in unnatural ways. It's because it's actually hard to avoid, while keeping performance at an acceptable level. You'd think that with more powerful hardware, it would become easier, but more powerful hardware is then used for more detailed geometry, so that per-polygon collisions are still a huge drain on performance.

Seguer

Yeah, no longer will I complain about clipping or bad collision detection/response.

I'm changing my game completely, just going to make a simple 3D Snake sort of thing (but you don't grow, FPS, and there are "enemies" - yay for assignment specifications).