As was foretold, we've added advertisements to the forums! If you have questions, or if you encounter any bugs, please visit this thread: https://forums.penny-arcade.com/discussion/240191/forum-advertisement-faq-and-reports-thread/
Options

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

SeguerSeguer of the VoidSydney, AustraliaRegistered User regular
edited October 2008 in Help / Advice Forum
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?

Seguer on

Posts

  • Options
    zilozilo Registered User regular
    edited September 2008
    That's a complex problem. Box physics isn't trivial; what's the application?

    zilo on
  • Options
    SeguerSeguer of the Void Sydney, AustraliaRegistered User regular
    edited September 2008
    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..

    Seguer on
  • Options
    HlubockyHlubocky Registered User regular
    edited September 2008
    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...

    Hlubocky on
  • Options
    SeguerSeguer of the Void Sydney, AustraliaRegistered User regular
    edited October 2008
    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...

    Seguer on
  • Options
    His CorkinessHis Corkiness Registered User regular
    edited October 2008
    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?

    His Corkiness on
  • Options
    SeguerSeguer of the Void Sydney, AustraliaRegistered User regular
    edited October 2008
    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!

    Seguer on
  • Options
    shutzshutz Registered User regular
    edited October 2008
    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.

    shutz on
    Creativity begets criticism.
    Check out my new blog: http://50wordstories.ca
    Also check out my old game design blog: http://stealmygamedesigns.blogspot.com
  • Options
    SeguerSeguer of the Void Sydney, AustraliaRegistered User regular
    edited October 2008
    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).

    Seguer on
Sign In or Register to comment.