[ODE] XML ODE Data Interchange Format

[William Denniss]

On Mon, 2004-03-08 at 20:03, Billy Zelsnack wrote:
> Excellent. Maybe this will actually happen.

Lets hope

> Still. That won't stop me from whining. Here are some random things I
> jotted down while reading the spec and people's responses so far:
>  
> there should be some sort of extension tag, but what goes inside it is
> up to the individual apps.

there is :) - that's in the first draft I released (revision 03)
http://tankammo.com/xode/xode.txt

<ext>

> no color node. this belongs in the extension tag (what's wrong with
> random colors!), but if you must, have it a raw name and call it
> material so you can use a material instead. if you want to encode a
> color, you could put it in the name.  color_FF00FF. or whatever.
> regardless, this is app specific, but there could be a single common
> convention for colors.

we talked about this too and I agree, it belongs in an "standard"
extension (defined elsewhere).

> no mesh. that lives in the extension. supporting a mesh is a
> nightmare. it starts down the.. oh.. the recommended mesh loaders
> are.. 3ds, ase, obj, openflight. blah. just say no.

Totally agree, and there is this line in the spec about "not limiting to
one display method or another".  Obviously this needs clarifying but
it's there:

"   It is domain specific to ODE to avoid compromises and hence is
suited
   to people using the built in ODE physics and collision objects but 
   like ODE, doesn't limit them to one display method or another."

There has been no attempt to support a mesh for displaying only
discussion of a good extension to handle this.

>  
> why not nodes for all the geom types? boxgeom, cylindergeom, etc. that
> is how the api works anyway. you don't create a geom and then assign a
> collision type to it. you create the geom directly.. geom=dCreateBox
>  
> what is the point of the <properties> node? it seems redundent. also,
> a cylinder is not a property of a geom, it is a type of geom.

There will be.  Possibly <properties> can be removed, I agree.

My idea was that all geom should be in a "<geom>" node, just like all
joints in a "<joint>" node.  This is nice as there is less clutter and
it's easy to identify what tag means what and is also kinder on the
parsers.

How we specify what type of geom a geom is within that node is open for
debate.  Perhaps this is more meaningful:

<geom shape="cylinder">
	etc...

</geom>

<joint type="hinge">

</joint>

I opted for the other way at first, although this one is probably better
in hind sight.

> use matrices. ode uses matrices internally, not some wacky structure.
> matrices should always  be relative to their parent. the matrix layout
> should be exactly how ode is internally.

this was discussed and we will support several ways of representing this
data so it's up to you which you use.  Some people may find that editing
translation, rotation and scale values is simpler than editing a matrix.

> groups are not part of the regular hierrarchy in many editors. they
> are often a parallel hierrarchy. because they are a parallel
> hierrarchy they can just live in the extention tag anyway.

true - but in this case what's the harm?  There's a big case for not
supporting 3D meshes, but I thought groups would be helpful in the
official spec.  Note that they are flagged as OPTIONAL and importers are
free to disregard their meaning.

 
> what is the <settings gravitymode business doing in the body?
>  
> i think the more common convention in xml is id="" instead of name=""

'id' is ambiguous due to its extensive use in ODE.  Some distinction is
necessary in my opinion.

This was just the first draft release of the spec.  In a few hours I
will brush it up taking into account all the comments to date -
hopefully your concerns will be dealt with in that revision.

Thanks for your input.

Cheers,

Will.

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