Yea it is a little bit tightly coupled there, at least right now. We might be able to add a hint to Spatial, or a getCustomCollisionShape() method. Then custom spatials could use their own collision shapes or borrow from others. Something other than terrain might want to use that heightfield class. Thoughts @normen?
I was thinking more that if Spatial had a way to supply any collision shape supported by Bullet (Heightfield being one of about 7) then it could be useful to separate it out that way. But I’m unsure of the demand for these custom collision shapes and if it is worth implementing. These collision shapes would of course have to be abstracted out of the bullet project. So maybe for now a simple heightfield interface will be sufficient.
Well I did a quickie HeightfieldCollision interface that Terrain implements. It could in theory be used by anything else that cares to supply a square heightfield. The benefit also being that CollisionShapeFactory isn’t restricted to just TerrainQuad then, but possibly any other terrain implementing the same HeightfieldCollision interface. I wouldn’t suggest using it based on the 160kb terrain dependency, but it does soften the CollisionShapeFactory.