[ODE] XML ODE Data Interchange Format (revision 5)

[William Denniss]

On Tue, 2004-03-16 at 13:37, Nate W wrote:
> On Mon, 15 Mar 2004, Jon Watte wrote:
> 
> > > The XSL argument is a very good one, and one which solves the whole
> > > ordering format argument (ie. being able to specify x,z,y) without the
> > > need for smarter importers.
> > 
> > There is a huge time penalty for putting each vertex in an element.
> 
> Nothing stops anyone from writing their own custom formats for speed.  If
> the goal here is to provide common means of import/export between editors,
> or a means of providing a format that a single application can use to
> import data from multiple editors, then I think XPath addressability is
> well worth the performance penalty.

This is the primary goal yes.

But, just how large is the XPath addressability advantage?  Wouldn't it
almost be easier just to tokenize an array of floats into an array than
using many XPath calls?

What would the pseudo code for XPath look like?

For an array of floats the code is very straight forward:

tokenize string using "," as the separator
iterate though the tokens, converting them to floats and adding to a
list
convert the list to an array
construct ODE trimesh object using array

Not only is the code simple, and the data size small, but the parsing
speed is also very fast.

> > Do you ACTUALLY intend to process your vertex data with XSLT? I mean,
> > enough to make up for the fact that the format just won't scale for
> > large level loads?
> 
> Yes, but I only expect to see that kind of thing happen rarely.  I'd
> expect an editor to use its own custom format, optimized for speed.  
> You'd load and save with the fast format all day long.  Then export to
> XODE so that an application (game, etc) can import from XODE.  
> 
> > Anyway, you does what you does. Except I believe it won't scale if you
> > do it in a particular way.
> 
> And I believe that you're right, but I don't believe that scalability
> should be a concern for a common file format.  Not when there is a big
> portability advantage to using only XPath-addressable values.

The debate whether or not using XPath-addressable is better or worse
aside.  While I agree that the goal of the XODE format is mainly for
interoperability between editors and applications, is there any point in
making it slower than need be - it may be good enough for some people
who don't need the speed of a binary format.  If there is an
optimisation that we can do which doesn't come with an expensive trade
off we may as well take it.

Will.

-- 
William Denniss - will@ http://tanksoftware.com/