[ODE] XODE trimesh structure - please vote

[Shaul Kedem]

Hi,
 From my experience, you'll be surprised how fast XML
is. For example, yafray (yet another raytracer -
www.yafray.org ) stores its meshes in an XML file.
These XML files can get pretty large but yafray
doesn't seem to mind, it parses the files very quickly
(milisecs) - using expat, I think.

 The difference in performance between #1 and #2
should be that big, using the right tools it should be
minimized to a couple of extra CPU instructions per
entry, which isn't that big of a deal (because option
#2 will require parsing within the CDATA section as
well)

 Also, please remember that we need a fully XML
compliant format to work with XSLT, XPATH and other
tools which rely on the XML-ness of the data.

 *Yet another argument* for option #1 is that if you
use option #2 you'll have to parse the mesh
information twice: once for XML and then another time
for the commas and other XODE specific format. This
means you'll probably have the same performance in
both cases...

 Anyway, don't forget that the only point which will
"suffer" (if at all) will be at the loading and
creation of the objects. Assuming you will not load so
many ODE objects (even in a game) you can load it at
the start of the execution and bind it to the world
when needed. Today's computers have enough RAM to deal
with that.

Shaul

--- William Denniss <lists at omegadelta.net> wrote:
> On Wed, 2004-03-17 at 03:30, Jon Watte wrote:
> > > And because it is only meant as an interchange
> format I think the advantages 
> > > of XPath and XSLT outweigh the disadvantages of
> slower parsing and larger 
> > > filesize.
> > 
> > I think this is the real question. Is this a
> format that can
> > conceivably be used for real storage, or is it
> specifically designed
> > to be as slow as possible to ease obscure
> interchange cases? If so,
> > what, specifically, are those concrete interchange
> cases?
> 
> While the primary goal is interchange, I think a
> secondary goal should
> be for real storage.  As Roel mentioned before, a
> gzipping XODE file
> will pretty much be the same size be it using #1 or
> #2 (for a large
> trimesh).  XML by nature will have a low entropy due
> to the repetition
> of the tags so the cost of even an unabbreviated
> <vertex> tag is little
> after compression.
> 
> > I'm not very interested in an interchange format
> that's not useful for
> > actual work. Thus, my vote is for comma-separated,
> and I don't care
> > about extra attributes (I can stuff per-triangle
> friction and whatnot
> > in a separate element). I don't see XSLT transform
> as particularly
> > relevant to the common-case use of these files.
> > 
> > If it's all interchange, then I don't care (though
> I still don't see
> > XSLT transforms actually being used :-).
> 
> The main advantage of XML it seems is XSLT and the
> disadvantage is the
> alleged slowness in parsing and larger file sizes. 
> Larger file sizes
> can be dealt with using compression.  How much
> slower would the parsing
> be using #2 rather than #1?  If this is the most
> important issue then we
> will have to benchmark it - else we are just
> stabbing in the dark.
> 
> We need to evaluate just how useful XSLT transforms
> are.  I did a bit of
> digging as I haven't had much experience with them
> and it seems that
> they could be extremely useful in conversions.  XODE
> to binary seems a
> possibility, or even going the other way say
> converting a X3D mesh into
> an XODE trimesh.
> 
> It seems XSLT could avoid the need for coding a
> converter entirely -
> that is a big plus in my book.
> 
> 
> Heres some random links that I turned up from my
> search:
> 
> Finding the Fit for XSLT - Filling a hole in the
> puzzle
> http://www.sys-con.com/xml/articleprint.cfm?id=763
> 
> Binary Killed the XML Star?
>
http://www.xmlmania.com/documents_article_112-Binary-Killed-the-XML-Star-.php
> 
> Binary XML, Again
> http://www.xml.com/pub/a/2003/08/13/deviant.html
> 
> 
> Cheers,
> 
> Will.
> 
> -- 
> William Denniss - will@ http://tanksoftware.com/
> 
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode

__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com