I want to create some physics collision geometries early, and choose which physics node to attach them to afterwards. To do this, I was planning to use (for example):
PhysicsSpace.createBox("name",null);
So my question is this: Is there a reason that all of the collision geometry creation methods are protected, not public, in PhysicsSpace? (For example, maybe there is a technical reason why all geometries should be immediately attached to a physics node).
And, secondly, why is it that some, but not all, of the collision geometry methods in OdePhysicsSpace are public (for example, createCylinder is public, while createBox() is protected.
And, if there aren't any special reasons, I'd like to request that those methods be made public in PhysicsSpace().
Actually, just reading the javadoc it looks like for PhysicsSpace, these methods are kept private in case other, non-ode implementations do require the PhysicsNode before they can create collision geometries. I'd still like to be able to take advantage of ODE's ability to create collision geometries on their own (assuming that this is in fact possible).
Would it be possible, as an alternative to making these methods protected, to have them public but allow implementations that require the PhysicsNode to throw an exception if it is not provided? These methods already can throw a PhysicsNotAvailable exception.
As you should never have a OdePhysicsSpace but always a PhysicsSpace the visibility in OdePhysicsSpace does not matter.
There are physics engines which do not support creating geoms without bodies (e.g. PhysX). Thus I chose to disallow it in jME Physics. You can change that in your local copy, as ODE allows it. But it won't go into the official API.
Which is what I've done. And I understand that the jme-physics API must be physics-engine agnostic.
However, why not modify the API so that physics engines that support this feature can provide it, and those that don't can throw an exception?
For comparison, that is the approach you've taken with creating the various types of Geometries - if a geometry is not supported by an implementation, the method throws an "errorNoGeometry".
Actually, it just turned into more or less a moot-point; it seems that OdePhysicsMesh does require the PhysicsNode for it to be created properly, and possibly other Ode Collision Geometries do as well. This probably isn't a feature worth exposing in the API after all.