[ODE] GUI Editor, to XML or not?

[William Denniss]

I also agree with all of Jani's points.  Text files for development work
are much nicer to work with.  The benefits of binary storage can be used
- but only when needed (ie. at production).

Is there any chance we can agree on a standard ODE data storage format?

How I would like to use this is basically model the ODE parameters of an
object in one of the fine editors currently being created - exporting to
XMl, loading it in my project and attaching my custom meshes (built with
a separate program) in place of the geometry.

I don't believe a full 3D package is necessary just to lay out the ODE
components and properties - I think a custom ODE editor would be better
suited.

Cheers,

Will.


On Thu, 2004-02-26 at 20:02, DjArcas wrote:
> Seconded on all points. All the games companies I've worked for use XML for
> their intermediary data format, obviously compiled to a binary for the final
> game release.
> 
> Except possibly BF1942, which might explain it's loading time ;)
> 
> ----- Original Message ----- 
> From: "Jani Laakso" <jani.laakso at itmill.com>
> To: <ODE at q12.org>
> Sent: Thursday, February 26, 2004 8:31 AM
> Subject: [ODE] GUI Editor, to XML or not?
> 
> 
> > My opinion for an export goes still for XML, if you know basics of XML
> > (and XSL), you get things done very quickly. And in bonus, structures
> > tend to be well defined even when things later grow more complex.
> >
> > For developers this would mean that everyone can then use XSL (like
> > xpath expressions) in any imaginable way to extract simulation parts or
> > modify simulation data before inserting it to my application.
> >
> > Here's couple important points more imho:
> >
> > 1. Integration to custom applications
> > -I would not like to construct totally custom parsers from ground up to
> > read editor data into my application, I'd exploit existing XML tools
> > here (XSL, DOM or even SAX).
> >
> > 2. Transforming
> > -I would not like to programmatically convert one simulation format to
> > another, I'd use XSL here.
> > -Example, transform simulation X to simulation Y: increase all jeep cars
> > geoms mass by %12 and extract only basic simulation parameters + jeep
> > cars. I'd use XSL here than to create custom converters. Add lot's of
> > custom examples here.
> >
> > 3. Debugging
> > -problems are easier to solve, xml is easier to comphrehend
> >
> > This format is meant for developers on development stage, so it should
> > be extensible and easy to use in all kind of situations. On production
> > platforms one can convert XML files into developer's own custom format
> > if needed.
> >
> > A physics editor that is meant for constructing complex simulation
> > setups for ODE, Novodex.., I'd go for XML when exporting / importing
> > e.g. bodies definitions to / from a file. I do not know how similar
> > these two are but there could be possibility to do one XML
> > implementation for an physics editor and then use plain XSL to export
> > simulation data to ODE, Novodex.. users. It might be that this is not
> > suitable but author's of physics editors know this better than me.
> >
> > The first impression for XML world can be quite disturbing, but once you
> > get into it and know where it's suited best, you'll love it. Learning
> > basic XML and XSL (+XSLT) is simple.
> >
> > Summary, there exists this XML/XSL and bunch of other tools for various
> > platforms, let's exploit them :)
> >
> >
> > Comments are welcomed, Jani.