Mixed geometry in Shape3d

[abies]

I'm considering porting nvidia stripifier to xith3d. It creates number of strips (or one long connected by degenerate triangles) plus number of single triangles not fitting in any of strips.

To render such output correctly (I'm mainly concerned about single long strip + triangle soup case), two draw calls are needed, but they share vertex data. In face, they could be even put into single index list, with just different range of elements to be drawn. With both coord and index data[1] in VBO, this possibly can even share vertex cache between calls ? Even if it is not a case, no rebind is necessary.

My question is how to do it in xith3d. In java3d, Shape3D supported mutliple geometries - so I could just create one IndexedTriangleStripArray and second IndexedTriangleArrray and put them into one shape. In xith3d, currently there is no support for multiple geometries. I wonder if it is really needed - after all, I don't want to render _different_ coordinates, just two times, using different mode and index list.

One, efficient and simple, but not  very elegant way comes to my mind - adding IndexedTriangleStripAndSoupArray. It would be a subclass of IndexedTriangleStripArray, with just extra index list for rendering 'triangle soup' after going through all strips. Just this subclass needs to be added - fan are not interesting case.

What do you think about it ? If IndexedTriangleStripAndSoupArray is no-go, what other choice do I have ? Multiple geometries per Shape3D, hoping that they will manage to avoid unneeded VBO spills ?


[1] - currently index data is kept by xith3d in main memory, instead of integer VBO. AFAIK, for indexed geometry, VBOs are not really accelerated until BOTH coordinate data and index list are kept in VBO. This is a sure place for improvement, especially given the fact that index data is going to be static in almost all cases (even for real time skin deformation, only coordinates change).

[Yuri Vl. Gushchin]

currently index data is kept by xith3d in main memory, instead of integer VBO. AFAIK, for indexed geometry, VBOs are not really accelerated until BOTH coordinate data and index list are kept in VBO. This is a sure place for improvement, especially given the fact that index data is going to be static in almost all cases (even for real time skin deformation, only coordinates change).

Sure, this is a place for enhancement. I spent a lot of time playing with VBOs trying to resolve VBO problems with NVidia driver on Linux. Anyway, I have similar problems with VBOs on WinXP, too, when use Detonator drivers (45xx are still making problems).

Now coming back to the topic. Maybe I am wrong, but after checking shapeAtomPeer.drawGeometry(...) I do not see support for IndexedTriangleStripArray... OK, we should add this I believe.

As of composing single geometry with multiple glDraw*** calls, I think we can create something like MixedGeometryArray/MixedIndexedGeometryArray/MixedStripGeopetryArray/MixedIndexedStripGeometryArray with the following functionality:

stripCounts should be exactly the same as in ***StripArray
stripModes [new!] should contain the modes for every strip (currently strip mode defined implicitly by geometry class, but here I want to specify this explicitly, on per-strip basis). stripModes can be one of LINE_STRIP, TRIANGLE_STRIP, TRIANGLE_FAN, LINE_ARRAY, POINT_ARRAY, TRIANGLE_ARRAY, QUAD_ARRAY, so we can make complicated mixed geometry inside one Shape3D.

This is just an idea and should be discussed in more details.

Yuri

[abies]

stripCounts should be exactly the same as in ***StripArray
stripModes [new!] should contain the modes for every strip (currently strip mode defined implicitly by geometry class, but here I want to specify this explicitly, on per-strip basis). stripModes can be one of LINE_STRIP, TRIANGLE_STRIP, TRIANGLE_FAN, LINE_ARRAY, POINT_ARRAY, TRIANGLE_ARRAY, QUAD_ARRAY, so we can make complicated mixed geometry inside one Shape3D.

I wonder if maybe this could be used as generic method for handling ALL geometry. Of course, old classes would stay with same interface, to preserve java3d and current xith3d compatibility, but to simplify renderer (as tree of instanceof ifs is not very elegant solution), they could just be in reality MixedGeometries with single strip or single strip type.

Games published by our own members! Check 'em out!

[Yuri Vl. Gushchin]

I wonder if maybe this could be used as generic method for handling ALL geometry.

Yep, this was exactly an idea behind the wording above - I was thinking on how to simplify and unify geom drawing process also leaving a room for optimizing the rendering process.

Yuri

[abies]

I have managed to port nvidia stripifier to java. I have tested it on few models - for most it gives quite a nice speedup, but in few case some of triangles are missing - but I suppose it is a problem with broken model defining illegal triangles somewhere.

I'll clean it up and make available on the web. It is currently xith3d agnostic and I think that it should stay this way until we will get java3d GeomInfo-like interface, which will allow to normalize/stripify/triangulate/etc arbitrary geometry.

Edit:

It is available at
http://nwn-j3d.sourceforge.net/xith3d/nvtristrip.zip

NvTriStrip.generateStrips is a most interesting method. If you want to use it with xith3d, you will need to patch renderer to accept indexed strips.

1   2   3   4   5   6   7   8   9   10   11   12

diff -u -r1.25 ShapeAtomPeer.java --- ShapeAtomPeer.java      6 Nov 2003 02:12:37 -0000      1.25 +++ ShapeAtomPeer.java      20 Dec 2003 17:01:34 -0000 -490,6 +490,8 @@                if (geoArray instanceof IndexedTriangleArray) {                  mode = GL.GL_TRIANGLES; // say that we want to draw points +            } else if ( geoArray instanceof IndexedGeometryStripArray ) { +                mode = GL.GL_TRIANGLE_STRIP;              }                IndexedGeometryArray igeoArray = (IndexedGeometryArray) geoArray;