[ODE] File formats

[Anselm Hook]

> Should the 'one true physics file format' include rendering-related
> information like mesh data?

The failure of VRML was the slight ambiguities that led to different
implementations and fractured the user base.  Minimizing the functionality
is a good way to avoid fractures.  While it is appealing to subsume extra
features (especially this one) it is one more responsibility.  Then there
are issues like texturing, UV coordinates, stripping of polys etc.  This
is as bulky as the rest of the format.

Also if one person can be sufficiently autocratic and own the spec then
that would help prevent feature bloat.  (A joke my father once told me
about decision making by committee:  intelligence of groups is not the sum
of member intelligence but the multiplier of - the intelligence of each
person multiplied by the other - ie if joe is .90 percent perfectly
intelligent, and tom is .80 percent perfectly intelligent then together
they are .72 ...).

> Or should each object include a reference to rendering data stored in
> another file?  Elsewhere in the same file?

Some kind of url or named external reference must be possible in valid
XML.  I'd vote for that.

> Or should objects just have unique identifiers so that the application can
> apply mesh to bodies using information from multiple files?

Is a name unique enough? relatively unique in path?  effectively an url.

> What about collision data?  The above questions apply here too.

This is harder - at least texturing and suchlike is not a consideration at
all.  Obviously the answer has to be yes; although I can imagine things
like BSP (although that could be computationally generated) and seamless
terrains and elevation maps versus polygon soups.

> Juice used primitives shapes so I just set up an enum for each shape type,
> and some float parameters for dimensions.  Should support for such
> primitives be part of the file spec, or should it just treat all things as
> arbitrary meshes?  I prefer the former, but I'm open to argument.  The
> latter approach has a nice uniformity to it, but I'm not sure how to take
> advantage of built-in primitive collision detection without primitive data
> in the file format.

I'd vote for the former since even though different types introduce more
complexity - there is fantastic bang for bug.

> Which axis is up?  Which is left-right and which is front-back?  Should we
> adopt the OpenGL axes?  D3D axes?  Invent our own?  In Juice, +Z is up, +Y
> is forward, and +X is right.  That's probably not compliant with anything
> else. :-)

Imitate VRML?

> What about motorization?  Should the file format include that sort of
> information?

Routes might help?  Controller nodes might be stubs where real behaviour
is elsewhere.  Actual routes between controllers and ODE objects could be
implemented by bridge objects - routes in VRML.

Routes are needed even for trivial visualization of behavior; connecting
an ODE body to a graphical representation.

The data-flow and wiring together of stuff is a big question actually -
what about perhaps using hierarchy to specify routing relationships?

> In the ODE paradigm, motors are basically properties of joints.  I
> personally hope to eventually see motors have their own axes and
> orientations, independent of any joints.

No ideas.

> Should the file format treat motor parameters as just joint parameteres,
> or should motor paramters (including orientation) be decoupled from joint
> parameters?

Not a clue.

> What about higher-level behaviors, like mapping keyboard and joystick I/O
> to motors and gaits?  Should the file format deal with such things, or
> should that be treated as a separate matter?

Question is where is the cut-off?  Does the doc include just ode bodies,
collision hulls, geometries, motors and relationships, or also switch
nodes, cloning nodes, user input, camera control, controller widgets, arc
ball controllers, sensors, timers, system events, layout management -
hmmm... it is a slippery slope!

What would be great is if the parser could respectfully ignore things it
did not recognize.

> What else should be asked and answered?

This will be a very far reaching discussion undoubtably.

Nate, I think you've definately got the issues down.

 - a