You create an OBB2 because OrientedBoundingBox extends TriMesh.
Why does it extend TriMesh (it’s the only bounding volume that does), and then creates the need for a second OBB that does the exact same thing. I would like to replace OrientedBoundingBox with OBB2 if possible.
All bounding volumes extend trimesh. That’s how they are drawn. Unfortunantly, the overhead of being a trimesh is too big for an OBBTree because it will contain thousands of TriMesh per object.
I’ld like to redo how jME draws bounding volumes so that they don’t have to extend trimesh. What about a drawMe(TriMesh) function inside boundingvolume where you pass the bounding volume a TriMesh and it fills the TriMesh with the information needed to draw that bounds. It makes drawing bounds slower (because of updating every time), but it makes the finished product game faster by using less memory per bounding volume (which grows very quickly in large games)
Oh geez, sorry, you’re right. Shows how long I’ve been out of the loop. I agree, I’d like to keep TriMesh and volumes seperate. However, Renanse should have the most input on this as he handle the drawing of the bounding volumes and has the most intimate knowledge of it. I’ll defer to him, I’d just like a solution where we don’t have to have two of the same volumes. 
Well, since bounds drawing is meant simply as a debug feature, we can always just have a TriMesh field in BoundingVolumes that is updated only in the draw call. We practically do this anyway in the renderer when we call recomputeMesh on the boundingvolume. Moving this information to an optional field (option in that it would default to null and be filled in with a trimesh on the first draw call) would cut out the nio buffers and a few other pieces of overhead when not drawing the bounds.
We’re still probably better off at least extending Spatial with our bounds themselves though because we’ll need a lot of the fields from that class (such as those that track rotation, translation, etc.) If there’s only a few of those fields and we’d pick up too much by extending Spatial, then I guess it doesn’t matter.
My quick analysis.
worldRotation, worldTranslation, worldScale. What else does a bounding volume need from spatial? And even that’s assuming a lot. Maybe a BoundingVolume of some unknown type doesn’t need that, it could just update its center and such when translated.
Yeah, you need all three for sure. Oversimplifying will only lead us to troubles in the future.