[ODE] XODE trimesh structure - please vote

[William Denniss]

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/