> Date: Thu, 11 Apr 2002 14:12:14 -0600 > From: Raj Vaidya <[EMAIL PROTECTED]> > Subject: Re: Signed auto-install AND USE_COORD_INDEX_ONLY > > Hi Paul, > > Very nice to hear from you and, as last year, much appreciate your > illustrative example. > > OK ! The reason why I was a little curious about the getIndexedGeometryArray() > taking a longer time when one sets the USE_COORD_INDEX_ONLY bit is > because of the following: > > 1. I am feeding in only unindexed tri-coordinates to GeometryInfo. Actually, > if you see my immediately preceding post today, it gives you the > code snippet.
OK. > 2. I am running NormalGenerator on GeometryInfo which would automatically > converted un-indexed tris to indexed ones. Yes. > 3. So, at the time when I call the getIndexedGeometryArray(), everything > is already in place with respect to the indices. All now this > method has to do is grab everything from Step 2. In fact, it should > be faster to the extent that it doesn't have to create an indices > array for the normals and set it on the IndexedTriangleArray. Once you call the NormalGenerator, your data has two data lists (coordinates and normals) and two index lists into those data lists. Extracting the data with USE_COORD_INDEX_ONLY will have to change everything, as I illustrated yesterday. First it creates an index list into your index lists, then it rebuilds the data lists, discards the old index lists, and replaces the coordinate index list with the new index list. Take a look at my example from yesterday: > Take an example of two triangles: > > 3 __2 > |\ | > | \ | > |__\| > 0 1 > Coord Color > 0 (0,0,0) (1,0,0) > 1 (1,0,0) (0,1,0) > 2 (1,1,0) (0,0,1) > 3 (0,1,0) > > CoordIdx ColorIdx > 0 0 0 > 1 1 1 > 2 3 2 > 3 1 1 > 4 2 1 > 5 3 2 > > Convert to USE_COORD_INDEX_ONLY: > > Coord Color > 0 (0,0,0) (1,0,0) > 1 (1,0,0) (0,1,0) > 2 (0,1,0) (0,0,1) > 3 (1,1,0) (0,1,0) > 4 (0,1,0) (0,0,1) > > Idx > 0 0 > 1 1 > 2 2 > 3 1 > 4 3 > 5 4 Your case is exactly the same, except your data has normals instead of colors. Notice how rows 1 and 3 of the index lists can use the same index in the new list because they have the same index values in all columns ( (1, 1) in this case). Only rows with identical values in *all* columns can share an index in USE_COORD_INDEX_ONLY. What GeometryInfo does is create an index into your index tables. It creates this index by creating a hash table. In the example above, the hash table would get five values - (0,0), (1,1), (3,2), (2,1), and (3,2). One row is duplicated, so it would hash to the same entry, and therefore those two rows can share the same index in the output index table. After the hash table is created and the new index list is generated, it uses this list along with the original data and index lists to create new data lists. Row 0 in the new data lists would get entries 0 and 0 from the old data lists, row 5 in the new data lists would get entries 3 and 2 from the old data lists, etc. (Row 5 in the new index list has 4. Row 5 in the original index lists has (3,2). Values 3 and 2 in the original data lists are (0,1,0) and (0,0,1) so put those into row 4 of the new data lists.) Also notice how, in the regular indexed geometry case, the data lists can be different lengths, whereas in the USE_COORD_INDEX_ONLY case, they must all be the same length. This is a major hint that the tables are all going to have to be rebuilt. > Good luck with everything, and hope to see you on this Forum > more frequently. Thanks. I've been lurking on the list and responding when I have extra time and something comes up having to do with the part of Java 3D for which I was responsible. -Paul =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
