I use a huge array rendering system to draw everything and... I read that by restricting that huge array I`m using through glDrawElements some kind of performance can be gained right ? So this glDrawElements Function uses the minimum and maximum offsets. So... minimum and maximum, I don`t really get it, does it refer to Min/Max(Indices) or... Min/Max(Vertex[Indices]) ? if they would mean min/max of the indices I would just have to replace min and max with R->Object[y].offset R->Object[y].offset+R->Object[y].nrindices right ? Ok so... after seing there`s no performance in all of this, I started to put that 0 and 100 values, guess what ? is still renders everything, even puttin 0,0 makes no difference, that`s kind of odd ? May it be because my array is made of... 17 000 Polygons and 12 000 vertices ? and the GL_MAX_ELEMENTS_VERTICES/INDICES is something like 4096 ? Thanks for reading the post and in advance :D

I can't help you much but I can tell that the only time I got a speedup was when I was rendering only a part of mesh, not the whole one. I made one vertex array from a bunch of little ones and modified index buffers with correct offsets. In that case I gaines a few % using glDrawRangeElements over glDrawElements. In the end I just keept it everywhere as it never slowed down anything.

The range parameters to glDrawRangeElements tell the driver the minimum and maximum values in the index array you are passing, i.e. the min and max accesses into the vertex array. This information allows the driver to do some fairly useful operations based on ranges. The only time there is no reason to use DrawRangeElements is when you know you'll be accessing the entire VB, from begin to end.

[Promit] Well I thought of that as well since I`m having 17 000 indices and have objects for like 20->100+ indices. But... no effect. It seemed really stupid to just put 0,0 as min and max and still get things rendered... I mean what is going on ?

[_DarkWIng_] How much % ? if it`s less than 10% I may give out.

Oh by the way, I tryed glMultiDrawElements and it`s really a for() with the normal DrawElements calls, no speed at all, actually I was having speed decrease because I allocated and deleted memory to encompass the indices/count arrays

In the end, what`s better ? Big Array vs Individual Array ? I think I`m turning back to individual because the Huge one is killing me...

Ideally, all static geometry is in a single vertex buffer (you should be using VBO, btw, because that IS a major performance boost), using offsets and DrawRangeElements to draw only the section of the buffer that you want to draw.

I read in one nVidia paper that it's advisable to make buffers a bit smaller, around 2-4MB, because that's a good size for the driver to manage memory efficiently (buffer is big enough to be efficient, but small enough to allow fairly granular management).

But yeah, if you want to be faster, use VBO for BOTH vertices AND indices.

Quote:

Original post by cippyboy How much % ? if it`s less than 10% I may give out.

About 5%. But I would say more than enough for a simple fix.

Quote:

Original post by cippyboy I`m having 17 000 indices and have objects for like 20->100+ indices

NVidia states that if you have under around 400 indices per call you are ultimatly CPU limited so performace gains will be minimal.

400 indices per call ? hm... seems interesting, I guess I could try and group objects even more...

Return to my original implementation with the single arrays proved... inefficient. i`m having a 5 FPS drop, and I think that is because now I have the Setting of the pointers per object(and at about 100-200 objects in frustum it`s a pain). Putting them in display lists is very unworth, from 150 FPS drops to 50 FPS(because of the material properties set per object).

I thought of individual arrays because maybe the glDrawElements takes the whole array and gets me speed decrease, but it now seems pointless, and I can make even better optimizations with the full array anyhow, sticking to that, and I`m gonna try VBO also.

glLockArrays seems to prove the functionality for glDraw[Range]Elements, when not set corectly you can see it clamps less vertices and stuff.

But I`ve seen one more bug though... I tryed to minimize my glDrawElements calls by setting up a different array of indices but keeping the same vertex array. It proves to be innefficient, getting un-compact vertices from the array proves to be time-consuming...

I could make an image of how things are generally done but I guess the topic is alreayd 'closed'

Quote:

Original post by cippyboy glLockArrays seems to prove the functionality for glDraw[Range]Elements, when not set corectly you can see it clamps less vertices and stuff.

Stay away from glLockArrays. That is a part of CVA extension that is considerd dead/useless since HW T&L.

Quote:

Original post by _DarkWIng_ Quote: Original post by cippyboy glLockArrays seems to prove the functionality for glDraw[Range]Elements, when not set corectly you can see it clamps less vertices and stuff. Stay away from glLockArrays. That is a part of CVA extension that is considerd dead/useless since HW T&L.

Although a recent test I did revealed that if there's no other AGP bus traffic, CVA is actually remarkably fast, and can keep up with VBO in a lot of cases.