Re: [Plib-devel] How many triangles in a leaf?
Brought to you by:
sjbaker
From: Vikas N K. <vik...@us...> - 2007-06-19 20:43:41
|
Hi John and Paolo, As you might already know, unsigned int is always 4 bytes. short is 2 bytes (signed and unsigned). So going to assembly syntax on x86 and x86-64 machines, unsigned int will read values from the register EAX wheras short will read values from the register AX. If for example, the user's applicaiton is doing tricky bitmap stuff with the 2 byte short values, then it might break his code if you move from short* to unsigned int* because now suddenly the memory is 4 bytes and a rotate bit operation will not work the way it should. As you might already know, a pointer to unsigned int points to 4 bytes and pointer to short points to 2 bytes. Typecasting from short to unsigned int or vice versa also will not work correctly if the user's app is doing tricky stuff with the bits in the short. C++ compilers "should" take care of the overloading of the functions whether pointer or not a pointer correctly since they mangle the names of the functions with the argument types (eg. g++ does it. On Linux, run "nm --defined" on your object file and you can see mangled names of symbols. Once you select your symbol of choice you can run c++filt on it and it will show you the demangled name of the symbol. MSFT VC++ does it too depending on the calling convention. The standard calling convention adds the number of bytes of size of the arguments to the function name as well, IIRC ) if you are upgrading the function you might want to use size_t* instead of the short* or unsigned int* so that it works fine on both 64 bit and 32 bit systems in the near future. Regards Vikas On 6/19/07, Fay John F Dr CTR USAF 46 SK <joh...@eg...> wrote: > Paolo, > > SSG is not my forte, but here is my reaction. > > (1) I don't think we want to keep the limitation on the number of > vertices. We will need a method that returns unsigned int rather than > short. > > (2) We definitely do not want to break existing applications that are > expecting a "short *" argument type. > > (3) I don't think we want two functions of the same name, one public > and one private, with different argument types. > > Something I don't know (my C++ is a little rusty) is whether > applications will be able to distinguish between two public functions > > ssgVtxTable::getTriangle( int n, short *v1, short *v2, short *v3) > > and > > ssgVtxTable::getTriangle( int n, unsigned int *v1, unsigned int *v2, > unsigned int *v3) > > Since the arguments are pointers, I think C++ can make the distinction. > If this is the case, I would suggest that we add a new public function > with "unsigned int *" arguments and that we deprecate the present > function. > > John F. Fay > Technical Fellow > Jacobs Technology TEAS Group > 850-883-1294 > > -----Original Message----- > From: pli...@li... > [mailto:pli...@li...] On Behalf Of Paolo > Leoncini > Sent: Tuesday, June 19, 2007 3:31 AM > To: pli...@li... > Subject: [Plib-devel] How many triangles in a leaf? > > Dear Plib friends, > > I'd faced again (see my post on the list "Large geometry objects and > crash > in ssgLOS" on 2005-11-24) with the unclear limit on the number of > primitives > the IndexArray can index. > > Even if we accept filling the VertexArray with no more than > sizeof(short) > vertices, the problem is that we can't index more than sizeof(short)/3 > triangles per ssgVtxTable (and derived leaf types), and it only arises > when > doing LOS or other queries on the geometry. > > Look at the code in ssgVtxArray.cxx: > > void ssgVtxArray::getTriangle ( int n, short *v1, short *v2, short *v3 ) > { > short vv1, vv2, vv3 ; > > ssgVtxTable::getTriangle ( n, &vv1, &vv2, &vv3 ) ; > > *v1 = *( indices -> get ( vv1 ) ) ; > *v2 = *( indices -> get ( vv2 ) ) ; > *v3 = *( indices -> get ( vv3 ) ) ; > } > > ssgIndexArray::get would take unsigned int argument type, but it is fed > with > the results from ssgVtxTable::getTriangle, which does return short > indices. > > Thus, by summarizing: max number of triangles in LOS-compatible > ssgVtxTable > and ssgVtxArray: 10922. > > For overcoming the limit we could either > > - leave such limitaion for ssgVtxTable, yet making > ssgVtxArray::getTriangle > independent of the ssgVtxTable::getTriangle call; > > Or > > - change the return type for ssgVtxTable::getTriangle indices to > unsigned > int; > > Or even > > - introduce a private method ssgVtxTable::getTriangle( int n, unsigned > int > *v1, unsigned int *v2, unsigned int *v3 ), and call this from both the > official ssgVtxTable::getTriangle ( int n, short *v1, short *v2, short > *v3 ) > and from the ssgVtxArray::getTriangle above. > > Waiting for reactions - > > Paolo > > > ------------------------------------------------------------------------ > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > plib-devel mailing list > pli...@li... > https://lists.sourceforge.net/lists/listinfo/plib-devel > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > plib-devel mailing list > pli...@li... > https://lists.sourceforge.net/lists/listinfo/plib-devel > -- http://www.vikaskumar.org/ |