[ODE] XODE trimesh structure - please vote

[William Denniss]

In addition to the points you make - #2 (the XML option) also is more
future-proof as we should be able to harness whatever great new tools
come out.

I have been talking to Jon Watte off list about his need for storing
extra elements with the vertex data.  I'm sure it would not be a burden
if we added (to the XML schema and spec) an additional CDATA 'e' (for
"extension") attribute to the vertex tag along with x,y & z, and marked
the support for it as OPTIONAL in the spec.  In fact - for the developer
it is much easier to ignore an extra XML attribute than elements in a
float array.

Since we are using XML for the rest of the format - it does seem strange
not to use it in one particular case.  Shaul's yafray example seems to
counter the argument that the #2 won't be as scalable as #1.

Will.


On Wed, 2004-03-17 at 15:47, Shaul Kedem wrote:
> 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/