[ODE] (no subject)

[adam.moravanszky@novodex.com]

Hi Nate,

we discussed file formats before.  I know about MathEngine's XML based asset
format used by KAT, which is admittedly more organized than our format which
sort of evolved over time.   I know Richard T. of ME is on this list.  I
don't know if he can speak for ME, but I wonder if ME would consider
thinking of their format as an open format which other entities (other
middleware providers like us or the open source community) are welcome to
use and augment.  Of course it is quite possible that they are abandoning
the format due to their integration with Criterion, I wouldn't know.
Technically the format is very clear cut so that's not a problem.  I am
not
a big fan of XML but it has its advantages, especially when a format isn't
to be closed and proprietary.  For example, it would be desirable if anybody
could add their own extensions to the format.  If ME has the right attitude
concerning this then we'd be happy to support this format in our toolset
as
well, parallel to our current format.

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

Only if this data is physics relevant.  For example, our soft body and
fracture technologies are not, and cannot be as mesh-agnostic as traditional
rigid body physics like ODE.  Because these sims need write access to a
renderable mesh, they effectively provide the renderer with the mesh.  Of
course they need an input mesh as well, and this mesh needs to include all
vertex attributes that will be needed for rendering.  In fact, in the most
general case these attributes need to be supplied with the appropriate
interpolators (eventually callbacks to user code) in case new attributes
need to be generated along a fracture seam.  So this can get quite involved.
Mesh-based collision detection is a bit simpler, because here a subset of
the mesh intended for rendering may be reused (data sharing).  Another
important point is whether the file is indented for a generic prototyping
/
simulation application (such as your Juice) that also needs to display the
results of the simulation, or whether its just an input to an SDK that
drives the physics in a game, but doesn't do any rendering itself.  In the
second case the authors of the game most likely already have a graphics
engine fed by existing file formats.  When you start including graphics
in
the format, you will have to ask yourself if you want to also animate
'ragdoll' characters, and thus supply the appropriate skin mesh, bones,
etc.
If so, you will soon end up with a generic "game" file format with all bells
and whistles.  The question is if that is the purpose of the format?  A
middleware company that provides complete authoring solutions would no doubt
answer 'yes', but I would rather distinguish two alternative goals: an
authoring format and a game format.  The first would be used as the primary
format of authoring tools such as Juice or KAT, with the primary goals being
flexibility, expandability, and portability.  The game format would be used
by files that get loaded daily by the millions of people playing a
particular game on a particular platform, so a quickly loading memory
mappable file with exactly the needed eventually compressed, eventually
preprocessed information.  It may be worth a discussion whether one should
compromise and have a single format, or have two and a requirement to
convert.  In any case, an authoring format for physics could either use
simple proxy graphics, or the final game artwork for a more desirable
WYSIWYG effect.  Unfortunately the second case implies a coupling to the
game graphics engine, which is quite a complex beast these days, and needs
to be fed with data that a physics authoring tool may not want to deal with.

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

I would not include any mesh data in a text file format (XML), but rather
reference external binary files.  (I know we use text mesh files in our
demos, but those are just quite small, and we do have a binary alternative.)
One may be tempted to say that the physics format does not define the nature
of these external files.  While that would make the format compatible with
many existing graphics formats, it would make the entire package that the
format represents much less portable.

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

AFAIK this is what KAT's XML format does in UT2003 to facilitate bone
animation for skinning.  It is good enough for this purpose, but other
physics applications like the ones I mentioned above will need access to
the
meshes.

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

Yes, see above.

> 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. :-)

If this is to be an open format, go with OpenGL.  Reinvent as little as
possible.  There are other arbitrary choices like what order to store the
4
quaternion elements, etc.

> 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

Supporting primitives is as important as anything else.  In particular
because you can easily convert a primitive to a mesh, but going in the other
direction is harder.

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

Yes, of course.

> 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.

Traditionally in Robotics motors drive joint DOFs, so that bit of ODE is
reasonable.  What exact parameters to use to specify a motor is of course
debatable.

> 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?

I would use a behavior scripting language for this, which is as much
decoupled from the structure representation as possible.

> What else should be asked and answered?

I think the first question to ask and answer is what our specific goals
are
with this format.  Is this only for Juice, or for other authoring tools
too?
Is it to be loaded directly by games?  Is it an issue to be able to read
and
tweak the format in a text editor, or not?  Is it only for rigid body
dynamics and collision detection, or also for other physics effects, like
cloth, etc?  Do we want to describe entire game levels, or just separate
'machines'?  Would we like to script the behavior of these machines?  Is
the
graphical and audio rendition of the scene to look exactly like what we
will
see in the game, or only an approximation?

I think only after you have covered the above (and possibly other issues
I
can't think of now) should you move on to technical details like bounding
volumes.

--  Adam Moravanszky
/*================*\
|Chief Software Architect
|NovodeX AG
|physics middleware
|www.novodex.com
\*================*/