[ODE] ODE GUI Editor #2...

[Steve Baker]

William Denniss wrote:
> On Thu, 2004-02-26 at 12:36, Martin C. Martin wrote:
> 
>>For once I agree with Jon Watte.  For my ODE simulation, I wrote out the 
>>  state of the simulation at every tick.  The position & rotation of 
>>every body, as well as a bunch of stuff about what the AI was thinking. 
>>  I did it in XML, as a way to explore the format.  The files ended up 
>>being a couple gigabytes.

But that was because you were saving the complete state a gazillion times
a second for a bazillion seconds.

We're talking about a format to store the ODE setup for the start of such
a run - what joints are there - how are they connected - what spring/damper
parameters are there.

I don't know what anyone might imagine as a 'typical' model - but I'd guess
it has a couple of hundred entities - with 100 characters per entity.  So
we are talking maybe 10kbytes.  Really - file size and parsing times aren't
going to be much of a factor.

Also, ASCII files compress really well and binary files don't - so a quick
pass through gzip/libz will get the size of an ASCII file down to not THAT
much more than the binary equivelent.

> Just to make sure we're all on the same page - there's no need to remove
> the binary support, I was only suggesting the addition of some
> text-based export utility.  As someone mentioned before it is easy to
> compress text files to a fraction of their size, but I am not trying to
> start an XML/Text vs binary debate - I'm saying it would be good to have
> both!

IMHO, a good modelling tool would have a plug-in architecture.  That's the
modern way.   File input and output is the first thing that you'd want to
open up to plugins.

In most 3D polygon modellers (the nearest analog I can come up with to what
we're discussing here), people use the 'de-facto' file format that comes
with the package (which ought to be ASCII IMHO) for long term archiving
and day-to-day working - and write a plugin to export files into whatever
format their application needs.   That way, it's perfectly possible to
set up the file format the final application loads to be lean and efficient
binary - and you still have the original ASCII file which has the merits of
being easy to extend off into the future - and easy to hack with a text editor
if that's needed.

For a NEW tool that I was just in the process of writing, an ASCII format
would be a 'must have' feature because of the risk that a bug in some future
version might subtly screw up the file in a hard-to-recover-from manner.
Being able to go in with a text editor is a big win under those circumstances.

One final big win for ASCII formats it that they work well with version
control.  CVS (for example) can look at an ASCII file and tell you what
changed from one version to the next - and perhaps even merge together
changes made at the same time by two different people.   This is of inestimable
value on large projects - especially if they are OpenSourced.

Binary files are totally unable to play nicely with version control systems.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1 at airmail.net>    WorkEmail: <sjbaker at link.com>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----