vertex buffer object - sphere

Hello! I need to draw and animate many small spheres in my program. Currently I’m using gluSphere and display lists but an efficiency is not enough. Is it possible to use VBO and gluSphere together ?

Not really, no. You don’t have control over what function calls gluSphere uses for rendering, so you’d have to write your own sphere generation code and put those vertexes into a VBO if you wanted to do this.

Having said that, if display lists aren’t working out, it’s unlikely that switching to VBOs is going to give you much either (unless your OpenGL implementation has a really poor implementation of display lists - which is possible). You need to look elsewhere.

You’re saying that the spheres are small. What values are you using for the slices and stacks parameters of gluSphere? Could you lower these values without having any noticeable visible difference?

How many spheres is “many”?

Have you looked at implementing frustum culling? If not, this on it’s own might be all that you need to get back to good performance.

Have you considered using textured quads instead? These are often an acceptable substitute for small spheres, and what you’ll end up with is really just a particle system.

Define “efficiency is not enough”? What kind of performance are you getting? What kind of performance do you need to get?

Your bottleneck may be elsewhere. If you have complex lighting or shading going on, if you’re applying huge texture maps to small objects, if you’re running complex physics or other calculations on the CPU, if you’re fill-rate limited, if you’re not doing back-face culling, if you’re not using a depth buffer, these can all contribute to lower performance and switching from display lists to VBOs will do absolutely nothing to help.

I’m going to do some physics simulation but first I want to test OpenGL efficiency ( efficiency means how many FPS I can get) in the specific situations. I work in Java (Netbeans) and use JOGL 1.1.1.a. I have already done a camera class based on a vector class and a matrix class. I decided to generate a lot of spheres.

I did a Ball class and a Material class. Of course, I have also a simple lightning model for my scene. The Ball class contains fields relating to a physics, a position on the scene, a way of drawing the ball(I use gluSphere so I have fields such as slices , stacks, a radius, a GLUauadric object), an appearance(Material) and the field “int sphere” for a display list.

The method which build a display list for a Ball object:

public void buildDisplayList(GL gl)
     sphere = gl.glGenLists(1);
     gl.glNewList(sphere, GL.GL_COMPILE);

The draw method:

public void draw(GL gl)
     GL.GL_AMBIENT, material.getAmbient(), 0); 
     GL.GL_DIFFUSE, material.getDiffuse(), 0);
     GL.GL_SPECULAR, material.getSpecular(), 0);
     GL.GL_EMISSION, material.getEmission(), 0);
     GL.GL_SHININESS, material.getShininess(), 0);

     glu.gluSphere(quadric, r, meridian, parallel);

In the GLRenderer class where are implemeted methods such as init, reshape, display I use the Array List for store my balls. In init objects are constructed and display lists are built.

for(float x = - 19.5f; x <= 19.5f; x += 0.25f)
     for(float z = - 19.5f; z <= 19.5f; z += 0.25f)
          list.add(new Ball(/*parameters*/));

All objects have the same parameters for gluSphere(slices = 16, stacks = 16, r = 0.05f) but can have different parameters relating to an initial position, a physics etc.

Next the display lists are built:

for(Ball v : list)

I also set this:


In display method I draw my spheres. Then I can calculate a physics.

for(Ball v : list)
     v.getYPosition(),  v.getZPosition());

I have already done a simple physics(balls can fall from a random height and bounce off the floor accordingly to a gravity and an energy loss - a collision with the floor).
Currently this physics model doesn’t have an influence on the efficiency (FPS) so I switched him off (the balls lie on the floor). When you see on the loop where the objects are constucted you can calculate the number of the balls - 24336.
For that number of the spheres I have about 25 FPS (Core 2 Duo E6750 3.2GHz, DDR2 2GB, GeForce GTX 560 Ti). Of course When I decrease the number slices and stacks I have more FPS, but we can assume that we don’t want do this. Instead of this I’m looking another ways to increase the FPS in this particular situation so I consider VBO (in this case I should make my own mesh for a sphere). I think that I properly used display lists…

For more advanced physics I can use CUDA (JCUDA) but maybe it is possible also to use CUDA together with VBO for render many objects.

- - - - - >Screen

Currently this physics model doesn’t have an influence on the efficiency (FPS) so I switched him off (the balls lie on the floor). When you see on the loop where the objects are constructed you can calculate the number of the balls - 24336.

I am assuming that you are saying you have 24336 balls.
It is probably too much in terms of state changes (all the glMaterial calls) and perhaps even the number of polygons.

  1. Group your balls per material color. Perhaps some of them have the same color.

  2. Use a LOD technique for your geometry. When a sphere is at a certain distance, render a lower resolution version of it. Perhaps, render a billboard with a pic of a sphere on it.

  3. Use space partitioning techniques to avoid rendering balls that aren’t even in the scene. This is also called view frustum culling.

If u r not deforming the spheres, perhaps u might use point sprites and render points in place of spheres using shaders as given here

this will save a lot of geometry.

Yes, I have 24336 balls.

  1. As you can see on the screen all have the same material.
  2. LOD technique is obvious, but I want to test an another ways
    for optimization.
  3. I assume that all balls are in a field of view at all times.

I don’t want to using another objects(shapes) instead of the sphere. What about VBO ?

The point sprites can be rendered as spheres (as i hinted in the last reply) without any problem so long as they do not deform ofcourse.