[ODE] XODE trimesh structure - please vote

[Shaul Kedem]

I vote #1.

If I may, I think that XODE should be as XML-oriented
as possible because of the accompanying tools a true
XML file (note that CDATA is false, but you get my
drift) supports. All of the XML parsers, DOMs as well
as the xpath, xquery (etc) standards and other tools
support elements and attributes much better than CDATA
sections. By introducing free text into the system it
means you will have *big* trouble using XSLT to
transform information into other formats, which in
turn will make reflection of information from XODE
into binary format (on the fly, not customized) into
hell.

Shaul

--- William Denniss <lists at omegadelta.net> wrote:
> My vote is for #2 and NO.
> 
> #2 because I think it will probably be easier to
> parse than a whole
> bunch of attributes and tags, and also due to the
> smaller size and
> greater readability it provides.  
> 
> Any conversions of the xyz order can be done at
> loading time by the
> application if necessary.  I think it is unwise to
> burden everyone with
> supporting conversion when it is not something
> everyone needs and isn't
> essential to the format.
> 
> and
> 
> NO because it's not part of ODE and I think the
> format will be more
> successfully if, like with the conversions it
> doesn't try and solve too
> many problems beyond that of representing ODE
> scenes.  Using extensions
> should be able to cater for most other needs such as
> this one.
> 
> Will.
> 
> 
> On Tue, 2004-03-16 at 10:33, William Denniss wrote:
> > This is an important issue and I would like to get
> as much feedback as
> > possible.  Already there have been arguments for
> several different ways.
> > 
> > The issue with storing the trimesh data is that
> you can either opt for
> > the XML way of doing it (ie. in XML tags) or using
> CDATA and making up
> > our own structure.
> > 
> > XML can be easily parsed by XML parsers, is larger
> in size, requires
> > less "intelligence" on the side of the importer
> and can be organised by
> > using XSLT.  On the other end of the spectrum we
> have a custom format
> > which is smaller in size, requires more
> "intelligence" on the side of
> > the importer and can not be organised using XSLT.
> > 
> > We also have option #3 which is being able to use
> either.  This combines
> > all the pros but makes the importers harder to
> write which could slow
> > adoption of the format (and render the debate
> basically moot).
> > 
> > Another question is that if we choose the custom
> data structure should
> > we allow more than 3 elements?
> > 
> > 
> > Below are the two issues, each with several
> choices.  Could everyone who
> > is considering using this format (and also those
> who are not but have
> > some advice anyway) please say which choice they
> prefer (please feel
> > free to give reasons).
> > 
> > Issue 1:  Structure of trimesh data
> > 
> > Choices:
> >    #1 - XML
> >       eg.
> > 
> >    <geom shape="trimesh">
> >      <trimesh>
> >         <vertices>
> > 	    <v x="0" y="1" z="1" />
> > 	    <v x="1" y="2" z="2" />
> > 	    <v x="2" y="0" z="1" />
> > 	    <v x="0" y="1" z="2" />
> > 	    <v x="2" y="2" z="1" />
> > 	</vertices>
> > 	<indices>
> > 	    <i>1</i>
> > 	    <i>2</i>
> > 	    <i>3</i>
> > 	    <i>4</i>
> > 	</indices>
> >      </trimesh>
> >    </geom>
> > 
> > 
> >   #2 - custom format
> >    <geom shape="trimesh">
> >      <trimesh>
> >         <vertices>
> > 	  0, 1, 1,
> > 	  1, 2, 2,
> > 	  2, 0, 1,
> > 	  0, 1, 2,
> > 	  2, 2, 1,
> > 	</vertices>
> > 	<indices>
> > 	1,
> > 	2,
> > 	3,
> > 	4,
> > 	</indices>
> >      </trimesh>
> >    </geom>
> > 
> >   #3 - ability to choose both.
> > 
> > Issue 2
> > 
> > In the event that format #2 is chosen - should we
> allow the option of extra elements?
> > 
> >   Yes/No
> > 
> > 
> > Thank you,
> > 
> > Will.
> > 
> > 
> > On Tue, 2004-03-16 at 03:09, 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.
> > > 
> > > 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?
> > > 
> > > Big arrays of data works better. I'd be happier
> if you could specify some number of extra elements
> per vertex (and per triangle!) but I think
> element-per-vertex is WAY over-flexible (much worse
> than allowing X, Y and Z to be in different orders
> in a format specifier, which I'm also not for :-).
> > > 
> > > Anyway, you does what you does. Except I believe
> it won't scale if you do it in a particular way.
> > > 
> > > Cheers,
> > > 
> > > 			/ h+
> > > 
> -- 
> 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