Performance question

lets put it this way: if your app needs to optimize vertex submission and isnt fillrate limited, chances are that you wouldnt want to run it on hardware that doesnt support for example vbo.
cva would only get you a few percent in most cases, so i dont think it will hurt too much if its not supported. and as its just calls to lock and unlock it would be trivial to only use it when the extension is supported.

also, what do you mean with static between frames? if the spheres stay spheres and you only move or rotate them you can still consider them static, because you dont touch the geometry. how many vertices would you have per sphere, how independent are they moving (rendering more than just one per call would be more efficient if possible).

Hi, thanks for the reply. What I mean by static is that there will be a scene consisting of spheres, and that scene will be translated and rotated by user input. At the moment this is made up of a display list containing thousands of calls to another list containing a gluSphere(). So yes, the geometry is untouched.

I''m not keen on using VBOs as the software would need to be runnable on lower-end hardware too, and I''m not convinced that any performance improvement would be worth the effort involved.

I''m aiming for as high a resolution as possible. At the moment, complex scenes can only be rendered with any kind of decent framerate if the user selects to render as glPoints.

I''m also a little confused as to whether it would be best to use a similar method to the one I''m using now, ie create a list with a sphere made up of a strip of triangles in a vertex array and go on to call that thousands of times within the main scene list, OR calculate the positions of each vertex in each sphere and end up with one big vertex array.

As you can see, I haven''t used vertex arrays before

-Simon

Hi, just been reading a bit more on VBOs, and perhaps they are more suited to this application than I originally thought. Can anyone give me some insight into hardware support for them?

On NVIDIA cards VBOs are available on GeForce 1 cards and newer. On a TNT/TNT2 you will run into fillrate problems anyway, so I''m not sure if you even want to care about a fallback, but if you need it supporting standard VAs for low-end cards would be no problem.

Then you said that the scene will be translated and rotated. Do you mean that each sphere''s position relative to the other spheres won''t change, so the whole scene is only moved all at the same time ? If each sphere needs to be translated and rotated independantly from the other spheres it will get much trickier (or just slower)

quote:

---

Original post by Alan_Grey
Hi, just been reading a bit more on VBOs, and perhaps they are more suited to this application than I originally thought. Can anyone give me some insight into hardware support for them?

---

http://www.delphi3d.net/hardware/extsupport.php?extension=GL_ARB_vertex_buffer_object

You should never let your fears become the boundaries of your dreams.

Hi, thanks for the replies.

The spheres will be in the same position relative to each other, unless settings in the program are changed. In that case the scene display list will be rebuilt. I like the idea of nesting the display list calls, as this means the entire scene doesn''t have to be rebuilt just because the user wants to increase the spheres'' radius.