[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