Hi
I am making something regarding a heightmap.
well, i have the grid, and I want to use “GL_ARRAY_BUFFER” option (i dont have VBO on my laptop card :-).
I can make one long buffer of all my triangles, but I can also arrange my grid as a collection of triangle strips.
What is considered to be faster?
I can have just one single call for an ordinary triangle array, and I can have multiple calls for my multiple triangle strips.
whats usually faster and regarded as better method?
Just use individual indexed triangles*. Triangle strips are so 1990’s 
Cas
I found this article from Tom Forsyth’s blog that describes a LRU algorithm for achieving O(n) sorting of indices to obtain nearly optimum cache behaviour independant of cache size.
Here’s the link: http://home.comcast.net/~tom_forsyth/papers/fast_vert_cache_opt.html
Its pretty easy to code and got me around 0.65 ACMR (average cache miss ratio) which is not too shaby at all…
DP
Im using glDrawArrays, and I haven’t seen any “index pointer” yet.
I would also like to enable VBO. Is there a way to upload the index array to the card’s memory?
How are you able to put anything on screen if you don’t us an index pointer? :o
glDrawArrays != glDrawElements
the first doesn’t use indices.
Sorry, never actually used that method call.
I do everything on the CPU and then lump everything in large quantities via vertex buffers using glDrawRangeElements. Apparently that’s the most efficient way of doing things.
It’s not.
VBOs (geometry in vRAM) beat the crap out of VAs (geometry in RAM)
Actually you might be hard pressed to get any increased performance from VBOs over glDrawRangeElements. It depends how you use the data.
Cas
You do realise that VBOs use glDrawRangeElements but take the VBO id as the pointer address instead of the actual indices.
Umm…ever done any large static data (i.e. terrain/buildings/anything thats not animated models) ? If you have, then you’ll see that interleaved VBOs do really beat the crap out of VAs and I have the benchmarks to prove it:
[quote]NonInterleavedGeometry and VA
PlanarTerrainNode with 32x32 cuts: 24fps
PlanarTerrainMesh: 8fps
InterleavedGeometry with VA
PlanarTerrainNode with 32x32 cuts: 24fps
PlanarTerrainMesh: 8fps
NonInterleavedGeometry and VBO
PlanarTerrainNode with 32x32 cuts: 83fps
PlanarTerrainMesh: 63fps
InterleavedGeometry with VBO
PlanarTerrainNode with 32x32 cuts: 155fps
PlanarTerrainMesh: 143fps
[/quote]
Look at the interleavedGeometry with VBO against the InterleavedGeometry with VA, thats 155 vs 24 respectively. I can’t see how you dont call that a significant performance increase.
DP
That’s what I said/meant.
I split my geometry up into 2MB junks in an oct tree and then buffer each segment in video memory via VBOs.
However, I usually test my algorithms with data greater than what my video card can handle, so then I have to use statistics to determine what objects are visible and what sub objects of those objects are visible.
It’s far more complicated than that but in any case the way I do things now makes things performingly viable. I’ve yet to see anything faster than what I do now.
Ah yes, static data for sure. Nearly everything I do/did was dynamically generated every frame though.
Cas
So thats frustum culling?
@princec, if your data doesn’t completely change all of the frame (im thinking lod here or something), you can use glMapBuffer or glBufferSubData to only send a small chunk of data (much like textures) to VRam. You can also hint that the data is DYNAMIC, STREAMING or STATIC to give the driver a hint about the type of data so that it could optimise a few things.
Be careful of glMapBuffer tho, it syncs the GPU and CPU for a period of time
DP
Only thing I’m doing with OpenGL right now is blitting sprites - basically nearly every frame is totally different. Mostly I’m fillrate limited anyway.
Cas
1/8th of what I do.
[quote]So thats frustum culling?
[/quote]