How many is too many ?

OpenGL Development JOGL Development
#1

I have a scene into which I load several things, among which was 100 gluSphere() object that used a common gluQuadric instance and each had 32 stacks and 32 slices. This scene would render horrendously slow … and according to the NetBeans profiler, the drawing of these spheres was the main cause. In particular the ‘sin()’ and ‘cos()’ calculations accounted for about 50% of the effort and the other thing was called ‘Self time’ according to the netbeans profiler.

Is there a quicker/better way to draw gluQuadrics ? I’m suprised at the performance hit I took when I tried to draw 100 spheres even though I was sharing the gluQuadric object instead of creating a new one each time…I create it once at init() and then I just call gluSphere() during the display method.

Just to add a little perspective, in Java3D I had a scene with around 2000 spheres and I was nowhere near the poor frame rates that I was in this case which is why I’m surprised. I know in Java3D that the geometry was shared so that was a speedup and I figured by having only one instance of the gluQuadric for the sphere would be a similar geometry sharing…heck, I’m ignorant on this topic so any help would be appreciated - I don’t even know if and when to delete a gluQuadric instance so I don’t.

#2

I’d try creating a display list with one of those gluSphere() and then using that display list in place of your other calls to gluSphere(). I don’t think the display list will store the glu calls but rather the geometry and the gl state so you shouldn’t have the penalty for the sin/cos nearly so badly.

#3

In general I would try to do this, yes. But for my case I’m not sure how exactly to handle making display lists because I made a Sphere3D class which the user can use to create Sphere3D objects on the fly. I have a space scene and I could envision code that would place a sphere at the center of mass location of a moving vehicle every second or so and so it would keep creating a new one each time and it could be a different color and even size each time.

Would I create a glList just for the glu.gluSphere() call and perform the sizing using a scale factor and perform the color outside of the gluSphere call? and so in this case all of the sine and cosine calculations would already have been created ahead of time?

What about the slices/stacks changing…this is something I would have to have defined for the glList already and can’t be changing else I would need to create a new glList for the different geometry.

#4

Sounds like a classic speed vs. memory trade off to me. You either calculate everything on the fly (either manually or via gluSphere) and have lots of flexibility at the cost of CPU time, or you calculate the geometry beforehand and reuse it for less CPU time but increased memory use.

Depending on how they’re coloured/textured you could probably have a common set of geometry of different resolutions and scale /colour those as appropriate for all your spheres. Calculating the geometry manually and storing it in vertex arrays and/or VBOs would be preferable, but display lists should work fine too.

#5

[quote=“Z-Knight,post:3,topic:31922”]
That’s all exactly what I was thinking, I’d say you’ve got a handle on the situation. Though let us know how it turns out, you never know when the next person might find the technique useful.

#6

I’ll try to glList method soon, though right now it is on the back burner until I get other things figured out. Plus I had some crashing with lists in my 3DS loader (after I added some “features”) so I’m kind of leary.

BUT, when I do try this I’ll post if it was successful.