[ODE] XML ODE Data Interchange Format

[Limor Schweitzer]

Great work on the RFC!

I would put colours as OPTIONAL cause otherwise, editors/apps that dont use 
colors will HAVE to put the color tag, which will inflate the file with 
useless <color R=255 G=255 B=255> tags...

PLEASE add a tag for transform matrix. (matrix can be represented preferably 
by 4x4 numbers but can also be by dx,dy,dz, yaw,pitch,roll or quaternion or 
whatever -- anything under a transform tag is in the combined coordinate 
system represented by the multiplication of the transform matrices before 
it; hence herarchy)

advantages:

1) If one editor knows about a herarchy of proxies/meshes/joints but 
flattens it out before exporting, that information is lost for ever. if an 
app doesnt care about the heirarchy in a XODE file, it can just ignore it 
and use the flatened coordinates (generated by the c++ wrapper after reading 
the file).

2) the coordinate-system herarchy information would be retained strictly in 
the C++ wrapper without ODE actually knowing about this. it would be pretty 
simple to extend the current C++ ODE wrapper to support herarchy. I think 
someone has done this in the past, i remember seeing something of this sort 
it in the contrib subdir, but cant find it as i'm writing this.

Limor

>From: William Denniss <lists at omegadelta.net>
>To: Steve Baker <sjbaker1 at airmail.net>
>CC: ODE at q12.org
>Subject: Re: [ODE] XML ODE Data Interchange Format
>Date: Sun, 07 Mar 2004 14:22:59 +1000
>On Sun, 2004-03-07 at 13:41, Steve Baker wrote:
> >
> > I havn't read your description yet - but perhaps I might make a
> > suggestion about the 3D meshes?
> >
> > 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.
>
>My sentiments exactly.
>
> > 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.
> >
> > This would enable physics editing packages to have at least some kind
> > of 3D representation to use when displaying the model for user 
>interaction.
> >
> > 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.
>
>An interesting suggestion.  We could as you say add some extra
>primitives to the the "graphical" components but in fact we might
>already have a solution.
>
>One of the debug modes in my project simply takes the collision geometry
>and create the 3D representation from them (ignoring my custom meshes
>which are usually used instead).  I think this way makes a lot of sense
>because the geometry is already defined for collision and so it's no
>extra work.  It is also a pretty good approximation as the closer your
>collision geometry mirror your meshes - the more realistic it will feel.
>
>Adding a RGB colour attribute is a good idea, in fact perhaps bodies
>should have colours associated with them as well - mainly for the editor
>(most editors I have seen let you pick colours for objects).
>
>Cheers,
>
>Will.
>
>---
>William Denniss - will@ http://tanksoftware.com/
>
>_______________________________________________
>ODE mailing list
>ODE at q12.org
>http://q12.org/mailman/listinfo/ode

_________________________________________________________________
Create a Job Alert on MSN Careers and enter for a chance to win $1000! 
http://msn.careerbuilder.com/promo/kaday.htm?siteid=CBMSN_1K&sc_extcmp=JS_JASweep_MSNHotm2