[ODE] XML ODE Data Interchange Format

[William Denniss]

On Mon, 2004-03-08 at 01:08, Steve Baker wrote:
> William Denniss wrote:
> 
> >><ext>
> >>  <extension name="file-location">
> >>    <location>./data/models/tire-small.3ds</location>
> >>  </extension>
> >></ext>
> 
> Bad idea.  This still presumes that the ODE file is the center of the
> universe - ie in loading this file, we also pull in the 3D files that
> it refers to.
> 
> This is very unlikely to be what a complex application (that happens
> to have some physics in it) will want.
> 
> It also assumes that 3D geometry is read from file on disk - it might
> be generated internally to the application (eg in the case of a particle
> system).
> 
> What is needed is just some handy ASCII string that relates to each
> entity that ODE could give me a position/rotation from (ie Matrices).
> 
> Anything more specific than that is **WRONG**.

It is a bad idea to include this in the spec I agree and it won't be. 
People who do view the ODE file as the center of the universe are free
to use their own extensions to achieve their goals.

> However, in the case of tools that help us design and tweak our physics,
> we need to have at least some control over how the model looks in those
> tools - so it would be nice to have some crude surrogate geometry (boxes
> and spheres and such) with colour control so I can use colour for clarity.

This is a nice thing to have - how do you feel about just (re)using the
geometry objects?  I find that most of the time I approximate my meshes
with geometry anyway for use in collision.

> > Maybe as you say we don't need the <mesh> tag at all.  The way I see it
> > is the the importer doesn't necessarily have to have a file name...
> 
> In many cases, it flat out can't have one - because there may not *BE*
> a file to represent that geometry - and even if there is, it's most unlikely
> that the physics modeller that I'd prefer to use would happen to adequately
> support the 3D file format of the polygon modeller I'd prefer to use.
> 
> My current project is a simulation of ancient greek naval warfare - I have
> a ship model with 170 oars and two large sails.  Having physics drive these
> things would be useful - but there is no way that either of those things
> will be represented by files on disk.
> 
> When I load my physics model of the ship into an editor - I'd like to see
> each oar represented by a cuboid and the spring/damper model of the sails
> as a little cube at each control vertex or something.
> 
> The physics modeller couldn't possibly render the ship as it's really
> going to look because much of the work of rendering oars and sails is
> going to be happening in a vertex shader - the complexities of which
> are something I don't thing physics editors should be distracted with.
> 
> It's just better to keep all references to skinning geometry out of
> the way of the physics and all references to physics out of the way
> of the 3D skinning process - letting the application connect them
> together.

This is definitely the goal of the format.  I am very aware that there
shouldn't be ties to a specific format.  For example in my case, my
editor supports only .3ds files, where as I use .ASE files in my
application.  This way I can have one set of .3ds modelling helper files
in the editor (as you say - low poly ones) and a completely different
set of higher detail models for my application.

Thanks for your comments.

Cheers,

Will.

-- 
William Denniss - will@ http://tanksoftware.com/