[ODE] XML ODE Data Interchange Format

Jani Laakso jani.laakso at itmill.com
Sun Mar 7 10:12:21 MST 2004


In short, I suggest that:
-XODE does not contain any visual representation data (for Geoms/Bodies)
-XODE contains a tag that links Geoms/Bodies to external visual 
representation file (e.g. 3ds)
-if linkage is not found, visual representation should be constructed 
from the Geom definition itself

Perhaps I'd remove the <mesh> tag and let editors use <ext 
source="juice" /> tag for linking visual representation to bodies. 
Visual representation is naturally "external" for XODE.

Steve Baker wrote:

> William Denniss wrote:
>
>> Driven by my own need for importing an ODE scene described by XML, I
>> have developed a draft XML ODE format named 'XODE' which I am proposing
>> as a standard and request comments.
>
Excellent, excellent! This should get things going..

> I don't think the ODE file format should venture into the domain of
> also being a 3D file format - since many applications will place
> far more demands on their 3D models than the ODE team would want to
> support.

Definately not, it would bloat the file excessively and imho the actual 
visual representation does not belong to XODE definition. But.. Somekind 
of linkage beetween XODE files and visual representation files should 
exist. XODE might contain unique identity numbers (or name) for each 
object so the objects can be linked externally. Or XODE could contain 
external link info to some other file.

Just like XODE now has:

<ext>
  <extension name="file-location">
    <location>./data/models/tire-small.3ds</location>
  </extension>
</ext>

> However, rather than completely punting on the issue, I would suggest
> that a very few basic shapes be defined to approximate the geometry
> of the 3D viewable mesh - eg Cuboid, Spheroid, Cylinder - with a simple
> RGB colour for each.

Wouldn't the Geom itself define basic shapes, e.g. boxes sizex,y,z? I'd 
suggest using Geom's itself for representing the visual side of ODE 
objects on editors. These are exact and good choiche for the editor side 
when developing new simulations. Of course the simulators can ignore 
"the real" visual representation (Geoms) and replace these with any 3ds 
file.

I am using a helper class that creates implicitly the visual side of ODE 
objects based on the Geoms, unless I've explicitly defined my own mesh 
for the body.

> This would enable physics editing packages to have at least some kind
> of 3D representation to use when displaying the model for user 
> interaction.

Again, the Geom definitions itself define these basic shapes exactly. 
Just like ODE's drawstuff-lib acts.

> The final application can then choose to ignore that representation and
> instead attach 3D geometry loaded from elsewhere.   All that's really
> needed is a way to associate the matrices coming from ODE's view of the
> world with the matrices in the 3D rendering.

Check William's proposal, it contains <ext> tag which is one option to 
do this. Even the editors could use this tag for linking visual 
representation to XODE objects.

Any editor can add their own special tags using the <ext> tag.
 

-- 
Jani Laakso / IT Mill Ltd | Tel. +358 40 5898086 | http://www.itmill.com




More information about the ODE mailing list