Jump to content

  • Log In with Google      Sign In   
  • Create Account


grhodes_at_work

Member Since 31 May 2000
Offline Last Active Jun 04 2013 12:37 PM
-----

Posts I've Made

In Topic: How to get sliding response to collisions (voxel terrain, mini-voxel camera)

04 June 2013 - 12:40 PM

Are the cubes all the same size (as in, say, a voxel representation)? Let's say your player cubes are larger than some of your terrain cubes. Then, your test that only checks the containment of the corners will be insufficient. The player cube could entirely surround a terrain cube such that no corner is inside a terrain cube but the cubes would still volumetrically overlap. For example, see below....the player cube corners denoted by 'p', and terrain by 't':

 

                                      p---------------------------------------p

                                      |                                                |

                                      |              t--------------t               |

                                      |              |                 |               |

                                      p-----------|--------------|------------p

                                                     |                 |

                                  t---------------t--------------t---------------t

                                  |                  |                 |                  |
                                  |                  |                 |                  |

                                  t---------------t--------------t---------------t

 

One approach to deciding which plane to slide against would be to consider the outward-facing surface normal of all the faces of the colliding cubes. The collision/contact plane will be a plane between two cube faces whose normals point in opposite directions. The bottom plane of the black cube points down and the top plane of the red cube points up....opposite directions, so the bottom plane of the black cube would be your collision/contact plane.

 

grhodes_at_work


In Topic: OBB calculating extents

04 June 2013 - 11:46 AM

Thank you for the additional background information. I now understand better what you are doing, and what your references are.

 

I hope I'm not overstepping your bounds to make additional suggestions and send additional references.

 

With respect to the separate transform object, I agree that you wouldn't want to create a new transform class. And, certainly, it does not necessarily make sense for OBB to inherit from transform. The OBB could have a property that is a transform object, and I wonder if it might still make sense to take advantage of the existing scene graph transform class. If you do something like this in your collision detection engine, then it might make it easier to sync your collision detection with the scene graph to be rendered. Or, the OBB shape could be a child of a transform object...making it easier to support compound shapes or different types of collision shapes. Many physics engines are set up sort of like this. I realize that rendering engines and collision detection/physics engines often have separate representations of the scene, but the collision/physics engines usually provide helpful built-in mechanisms to point back to a rendered scene graph.

 

I can think of another OBB reference, which might be useful if you can find a copy online. It is the OBBTree paper written by researchers at UNC Chapel Hill many years ago. Yes, its really old now, but is one of the early presentations of OBB for collision detection, and still useful. Here is a link to the paper. (I admit that I haven't ready it in a long, long time.)

 

http://www.cs.unc.edu/~walk/papers/gottscha/sig96.pdf

 

Pierre Terdiman also has done some work that you might find useful:

 

http://www.codercorner.com/Coder.htm - see OPCODE for example

http://www.codercorner.com/RAPID_Hack.htm

 

Graham


In Topic: New version of ColDet

04 June 2013 - 11:11 AM

Thank you for the post! I wonder if you would be willing to write a description of ColDet here, ideally something that is a bit more detailed than the short summary on the sourceforge page. And maybe link to some projects or YouTube videos demonstrating it use?

 

grhodes_at_work


In Topic: OBB calculating extents

03 June 2013 - 03:50 PM

There are some things about your presentation that are worrisome to me, in terms of language use, variable names, and coding style. I offer some suggestions, which you can use if you find them useful.

 

First, you say that your OBB's having "3 perpendicular normals," but I wonder why you call them normals. Is it because the faces of the OBB are perpendicular to these vectors that you called them "normals?" Why not call them just local coordinate frame axes, or basis vectors, or basis directions, all of which are more general and more appropriate for vectors that define the rotation of a generalized shape? I would also suggest that you completely separate the dimensions of the OBB from the basis vectors in the constructor, for clarity. Embedding the size of the OBB inside the incoming basis vectors...is confusing. There is nothing in the variable names of the OBB constructor parameters that indicates the length of the edges is equal to the length of those vectors.

 

If I were to write a simple OBB class, it'd look something like this. This is just quickly written code, incomplete, not really designed, not tested, and not exactly what I'd use for a project. This code illustrates an idea. The idea is to suggest building your transformation (location and orientation) as a separate object and just include it in the OBB class. By building the transformation separately, you can re-use it to represent other things in the scene, too. Not just OBB's.

 

/// simple 3x3 matrix class, to be used to store orientation as a 3x3
/// rotation matrix
class RotationMatrix3x3
{
public:
    RotationMatrix3x3(const vec3 &xDir, const vec3 &yDir, const vec3 &zDir)
    {
        m_basisVectors[0] = xDir;
        m_basisVectors[1] = yDir;
        m_basisVectors[2] = zDir;
    }

protected:
   vec3 m_basisVectors[3]; ///< x, y, and z direction basis vectors
};

/// transformation class to be used to store translation and rotation
/// relative to a parent or world Cartesian coordinate frame
class Transform
{
public:
    Transform(const vec3 &translation, const vec3 &xDir, const vec3 &yDir,
              const vec3 &zDir):
              m_translation(translation), m_orientation(xDir, yDir, zDir)
    {
    }

protected:
    /// translation vector, represented in a parent or world coordinate frame
    vec3 m_translation;

    /// orientation as a 3x3 rotation matrix, represented in a parent or world
    /// coordinate frame
    RotationMatrix3x3 m_orientation;
};

/// Oriented Bounding Box class, which inherits its location and orientation
/// relative to a parent or world coordinate frame via the Transform class
class OBB : public Transform
{
    OBB(const vec3 &translation, const vec3 &xDir, const vec3 &yDir,
        const vec3 &zDir, const vec3 &extent) :
        Transform(translation, xDir, yDir, zDir), m_extent(extent)
    {
    }

protected:
    /// extent along local object basis directions
    vec3 m_extent;
};

 

I hope this is somehow useful.

 

grhodes_at_work


In Topic: A Daft Statement

03 June 2013 - 02:51 PM

I'm going to move this thread to the lounge. The discussion is somewhat interesting, philosophically, and there's been some meaningful interaction. But the thread is not in fact about math or physics, or game development. Therefore, it doesn't belong in the math and physics forum.

 

grhodes_at_work


PARTNERS