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

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