NvTriStrip assert - anyone had anything similar?

I was wondering if someone could tell me if they’ve every had the following assert from the nvtristrip library? :-

edgeInfo != NULL

I’m getting this when calling it like this:-

PrimitiveGroup* primGroups;
unsigned short numGroups;

SetCacheSize(CACHESIZE_GEFORCE3); // optimise for geforce3 cache size
SetListsOnly(false); // generate strips
SetStitchStrips(false); // stitch seperate strips together using degenerate triangles
SetMinStripSize(0);

GenerateStrips(m_pusIArray, m_uiICount, &primGroups, &numGroups);

Now, m_pusIArray is a valid pointer of 53 unsigned short indices making up a triangle list, m_uiICount is 159.
Can anyone help me get round this problem?

Err, I’ve just printed out the contents of that array of indices that I’m passing to the tri-stripper, and it has revealed some odd triangles, so maybe the tri-stripper has done me a favour…check out these triangles:-


40,41,42
43,29,44
45,46,47
34,34,36 //JESUS! How did that get in there?!
36,34,36 // ditto!
36,36,38 // ditto!
38,36,38 // ditto!

I’m getting these indices from a model exported in VRML97 from 3dsMax4. Looks like some weird ones are being created by the exporter…
Could this be the cause of the ASSERT?

Wow! Got it working - and it has drastically improved the performance of my renderer.

I strip out any of triangle that has duplicate vertices for corners before I send it to the tri-stripper.

Found what I think is a true bug in it though - it seems to be (every so often) giving me indices that are outside the vertex range - well, when I say outside, I mean that its giving me the occasional max value for an unsigned short (65536 or whatever it is). The indices I provide it with do not have such large values, so it must be a bug.
I have to do a pass over the index arrays it gives me, stripping out any triangles that index outside the vertex range - which solves the problem, and doesn’t seem to affect the final image at all…weird.
Is anyone at NVidia maintaining the tri-stripper? It’s a lovely piece of code, but with a few quirks - not bad for free, though!

Right, another question…probably answer it myself, the way things are looking (has ANYONE used the NvTriStrip lib at all? )
I want to take advantage of the RemapIndices() function in the library, where it’s supposed to reorder the indices so that they’re more cache friendly.
I’m a bit puzzled as to how I remap my vertices after the function call…do I build a new vertex/normal/texcoord array in the following way? :-

for (grp=0; grp<numGrps; grp++)
{
for (i=0; i<newPrimGroup[grp].numIndices; i++)
{
float* vertex = &oldvertexarray[oldPrimGroup[grp].indices[i]*3];

newvertexarray[newPrimGroup[grp].indices[i]*3][0] = vertex[0];
newvertexarray[newPrimGroup[grp].indices[i]*3][1] = vertex[1];
newvertexarray[newPrimGroup[grp].indices[i]*3][2] = vertex[2];

}
}

Is this correct?
I’m going to try it…I just realised that I’ve just written the code in this post! Whether it’s correct or not, I shall soon find out…

[This message has been edited by knackered (edited 01-24-2002).]

Another question:-
Am I right in thinking that if you ever disable GL_VERTEX_ARRAY_RANGE_NV in your render loop, you lose a massive amount of performance?
It seems that way to me…

Yes, but you can use VAR2 instead ( disable GL_VERTEX_ARRAY_RANGE_WITHOUT_FLUSH_NV ).

Thanks PH.
BTW, that code for remapping the vertices is correct. Didn’t notice any performance increase, though.

I used NvtriStrip.lib and didn’t have any problems at all. worked perfect 1st time.

I am not using the RemapIndices stuff tho, and I stitch all my lists together using degenerate tri’s.

Amazing how much of a performance increase you get.

Nutty

[This message has been edited by Nutty (edited 01-24-2002).]

What kind of performance improvement are you getting with it?

I’m programming my own stripper, and with the latest version I get twice the fps (31fps -> 64fps).
I use a 60,000 polygons model for those tests, the high polygons version of the 3D skull in Lightwave (6.0 or higher).

It’s hard to give you figures - the scene I’m running the stripper on consists of many seperate objects, some quite small…total triangles before stripping is about 120,000. After stripping, this number goes up considerably, to about 250,000, but most of them are probably degenerate triangles…I’ve got huge groups of trees, which are part of the same primitive group, but are discreet triangles…then after stripping they are turned into one tri-strip linked together by degenerate triangles.
I’m getting about double the frame rate after tri-stripping.