GL_TRIANGLE_STRIP and VBO fail.

[menzel]

What's wrong with strips? Generally if someone like Tom Forsyth says something I tend to assume that the likelihood he knows what he's talking about is reasonably high, so here's what he has to say (link: http://tomsdxfaq.blogspot.com/)

http://home.comcast.net/~tom_forsyth/blog.wiki.html#Strippers

You have to note however, that Tom Forsyth compared index triangles against non-indexed stips in your quote. 7 years into the future we can use index stips with primitive restart instead of degenerated triangles. He also writes about that:

"Some APIs (not PC DX5-DX9, but some consoles, and possibly future PC APIs) also allow a "restart" index, which means you don't need to use degenerate triangles, and they can make strips better than lists" (http://tomsdxfaq.blogspot.de/).

As each strip needs 2+N indices for N triangles, in a list with primitive restart we need (3*M)+N-1 for N triangles in M strips (the last strip does not need a restart index). A plain list needs 3*N indices.

So when will we save space in the index?
3M +N-1 < 3N
3M +N < 3N
3M < 2N
M < 0.66N
When we have less that 0.66 stips than triangles. As the average stripsize is N/M that means that an average strip must contain 1.5 triangles. Let's check that: A strip of 2 triangles needs 4 indices + 1 restart index == 5 indices while 2 triangles seperated need already 6 indices.

To take advantage of your post transformation cache, your stripsize has to be short, but as we have seen, shortness is not a problem, we will still save memory.

So in theory short strips that make use of the post transformation cache with primitive restart should be the optimal solution (in practice you DCC tools might not be optimized for this setup or the restart itself is a hidden bottleneck, but i'd like to see benchmarks on newer hardware to beleave that).


BTW: Does anyone have numbers of the post transformation cache sizes of current GPUs?

[Dark Photon]

To take advantage of your post transformation cache, your stripsize has to be short...

This does not follow.

BTW: Does anyone have numbers of the post transformation cache sizes of current GPUs?

I haven't seen anything on that in ages. Back in ancient days of fixed-function GPUs, sizes were up to 45 in the GeForce 7 days. And way back in GeForce 8 days (unified shader core generation), saw some info in the NVidia GPU Programmer's guide for that generation that indicates the size of the vertex cache was dynamic and subject to the amount of varyings output by the vertex shader (more varyings, shorter vertex cache, and vice versa). I'm guessing they were/are using the shared memory on the SMs as a vertex cache, but that's a total guess.

So in practice, I expect your minimum vertex cache length is more than you need. And if you read studies by Forsyth and others, you see that in practice 45 is way more than you need for near-optimal performance with a half-decent vertex cache optimizing triangle sorting.

[Darkpower]

I need a little bit help.
I have to use glDrawElements(GL_TRIANGLE_STRIP, indices), glEnable(GL_PRIMITIVE_RESTART) and glPrimitiveRestartIndex(restartIndex).

But how can I get all the indices? Look at the example code below. I think I'm going to have to create a new buffer that holds all the indices.

Inner loop=Filling the buffer with indices. But, what kind of values?
Outer loop=add "restartIndex".

float[][][] heightMap =  new float[WIDTH][DEPTH][q];
int restartIndex = 0xfffff;
 
//First: Loop and fill array with data and other stuff.
 
 
FloatBuffer buffer = BufferUtils.createFloatBuffer(heightMapSize);
IntBuffer indices = BufferUtils.createIntBuffer(how big??????);
 
//indices.put(), what kind of values? (inner loop)
 
for (int z = 0; z < DEPTH-1; z++)
{
    for (int x = 0; x < WIDTH-1; x++)
    {
        buffer.put(heightMap[x][z][q]).put(data).put(data); //Vertex
        buffer.put(0.0f).put(0.0f); //Texture
 
        buffer.put(data).put(data).put(data);
        buffer.put(data).put(data);
 
        buffer.put(data).put(data).put(data);
        buffer.put(data).put(data);
 
        buffer.put(data).put(data).put(data);
        buffer.put(data).put(data);
    }
    indices.put(restartIndex);
}

[tonyo_au]

The indices are the relative offset into the vertex buffer.

restartIndex must not be a valid vertex buffer index.

If you have 2 strips with say 6 unique vertices each, the vertex buffer will have 12 vertices and the index buffer will be
0,1,2,3,4,5,restartIndex,6,7,8,9,10,11,restartInde x

[Darkpower]

Ok, tried it. The result: http://oi47.tinypic.com/5k5280.jpg

Something is terribly Wrong Here. Lines + holes, yes....

Before: glDrawArrays(GL_TRIANGLE_STRIP, 0, numberVertices) = lines.
Before: glDrawArrays(GL_TRIANGLES, 0, numberVertices) = no lines.

Now: glDrawElements(GL_TRIANGLE_STRIP, indices) = lines.
Now: glDrawElements(GL_TRIANGLES, indices) = lines.


Have to check my code again.

[Darkpower]

Look at this picture: http://oi50.tinypic.com/2me4a3k.jpg

GL_TRIANGLES, so you can see the lines more clearly.

All lines goes from one side to the other. Why?

[Darkpower]

Nobody knows?

[Mars_999]

I haven't read any of these two pages but I will state this are you using degenerate triangles? If so you will probably need to and mess with the winding order on the row ends to keep going to the next row and run back again.

[Darkpower]

No, i'm using primitive restart.

[Darkpower]

WOHO, solved everything now!=D=D=D