[Plib-devel] R: How many triangles in a leaf?
Brought to you by:
sjbaker
Menu
▾
▴
[Plib-devel] R: How many triangles in a leaf?
|
From: Paolo L. <p.l...@ci...> - 2007-09-24 12:35:19
|
> -----Messaggio originale----- > Da: pli...@li... > [mailto:pli...@li...] Per conto > di Steve Baker > Inviato: domenica 23 settembre 2007 21.57 > A: joh...@cy...; PLIB Developers > Oggetto: Re: [Plib-devel] How many triangles in a leaf? > > I would strongly advise against this change. Sending 32 bit > indices instead of 16 is a big penalty on reasonably size > meshes. It's not hard to split big meshes into 65536 vertex > chunks and it's a bad idea to slow the package down for > reasonably sized models just in order to support the clueless. I never thought to move all indices to 32 bit, and to support 2^32 vertices per mesh. Today the following limits hold for a ssgVtxArray: - max number of vertices: sizeof(unsigned int) (a ssgVertexArray is a ssgSimpleList) - max number of indices: sizeof(unsigned int) (a ssgIndexArray is a ssgSimpleList) - max vertex index: sizeof(short) (indices are actually stored as shorts in a ssgIndexArray) Here's the mother of all inconsistencies: we can have up to 2^32 vertices, but can address only the first 32768. So by loaders' point of view, it's not important to have a limit, whatever it be, it's important to enforce the respect of such a limit at ssgVtxArray creation. I don't know each loader compliance to that, I took care of it only recently in the 3DS loader by splitting larger meshes in sizeof(short)/3 (10922) triangles (triangle n has indices n*3, n*3+1, n*3+2) (this is already in the SVN version of the 3DS loader). Other loaders could make a more smarter use of the 32K-limited indices so to address many more triangles than the 3DS one. So it's solution time now: a. cleanness: move to unsigned short indices, and limit the number of vertices to that size - we would thus stay still within the 16-bit indices so performances wouldn't suffer; b. freedom: move to unsigned int indices, leave ssgVertexArray as it is (since it is already unsigned int-capable) - virtually no mesh split longer needed, performances would probably suffer a bit; c. future: don't do anything now, let's wait to redesign the leaf geometry storing from scratch in a possible Plib 2.0 version, where we could parametrize several aspects of a ssgVtxArray, including whether to go to Vertex arrays, VBOs, or possible newer, more performant OGL mechanisms. As far as we are all aware of such intrinsic subtle limitation, I'm not in a hurry to anything could compromise performances or Plib instability. Wolfram, thanks for your agreeableness. Greetings - Paolo Leoncini > John F. Fay wrote: > > If somebody can send me some patches I can put them into > the code. I > > have re-read Paolo's post and the responses and I do not > want to make > > such a subtle change to a library that I do not know well. > > > > - John > > > > > > -----Original Message----- > > From: Wolfram Kuss > > Sent: Saturday, September 22, 2007 3:02 PM > > To: PLIB Developers > > Subject: Re: [Plib-devel] How many triangles in a leaf? > > > > I agree we should increase the limit. > > The argument that this will encourage bad models is only half true > > IMHO as often I have to work with finished models and am > not even in > > contact with the modeller. > > > > I am using "unsigned short" instead of "short" for a long time now > > (probably 2 years or so) without issues. Going to unsigned > int would > > probably be a bit more work, but would be welcome by me. > > > > Bye bye, > > Wolfram. > > > > > ---------------------------------------------------------------------- > > --- This SF.net email is sponsored by: Microsoft Defy all > challenges. > > Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > plib-devel mailing list > > pli...@li... > > https://lists.sourceforge.net/lists/listinfo/plib-devel > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > --- This SF.net email is sponsored by: Microsoft Defy all > challenges. > > Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > plib-devel mailing list > > pli...@li... > > https://lists.sourceforge.net/lists/listinfo/plib-devel > > > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by: Microsoft Defy all > challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > plib-devel mailing list > pli...@li... > https://lists.sourceforge.net/lists/listinfo/plib-devel > |
