[ODE] XODE trimesh structure - please vote

[William Denniss]

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/