Drawing a Sphere

Does anyone know of any good, fast sphere drawing algorithms?

#include <GL/glu.h>

float radius = 1.5f;
int numSlices = 32;
int numStacks = 8;

GLUquadricObj* pQuadric = gluNewQuadric();
assert(pQuadric!=NULL);
gluSphere(pQuadric,radius,numSlices,numStacks);


DOCS …

gluSphere
The gluSphere function draws a sphere.

void gluSphere(
GLUquadricObj *qobj,
GLdouble radius,
GLint slices,
GLint stacks
);
Parameters
qobj
The quadric object (created with gluNewQuadric).
radius
The radius of the sphere.
slices
The number of subdivisions around the z-axis (similar to lines of longitude).
stacks
The number of subdivisions along the z-axis (similar to lines of latitude).
Remarks
The gluSphere function draws a sphere of the given radius centered around the origin. The sphere is subdivided around the z-axis into slices and along the z-axis into stacks (similar to lines of longitude and latitude).

If the orientation is set to GLU_OUTSIDE (with gluQuadricOrientation), any normals generated point away from the center of the sphere. Otherwise, they point toward the center of the sphere.

If texturing is turned on (with gluQuadricTexture): texture coordinates are generated so that t ranges from 0.0 at z = –radius to 1.0 at z = radius (t increases linearly along longitudinal lines); and s ranges from 0.0 at the positive y-axis, to 0.25 at the positive x-axis, to 0.5 at the positive y-axis, to 0.75 at the positive x-axis, and back to 1.0 at the positive y-axis.

Good Luck!

BTW: This type of question would get more positive responses if posted in the beginners forum.

[This message has been edited by pleopard (edited 05-30-2001).]

It´s possible to calculate a sphere when

x = cos(theta) cos(beta)
y = cos(theta) sin(beta)
z = sin(theta)
where
-phi/2<=theta<=phi/2
-phi<=beta<=phi

Good luck!

i think he was asking for a FAST - (the fastest?) sphere drawing algorithm.
how fast is the gluSphere algo ?
i assume that every time gluSphere is called, this function uses a glBegin(GL_…) and glEnd() block. but i found with my graphics card that many calls to glBegin(…) are very slow. so it would better to have it’s own routine “fastsphere” or such so one can place many calls to fastsphere in one glbegin(…) glend() block.

so how could one best construct it’s own sphere drawing routine (maybe with precomuted vertices?) that optimizes opengl-performance?

use gluSphere, and if you want more speed, put it into a list.

you guys missed the most obvious!

A single billboarded quad with a pretty picture of a phong shaded sphere.

If you wwant a textured sphere, then if the ball has to role or something, then you have a small problem.

V-man

I’m not sure what method this uses but being a benchmark program I would imagine it will be the fastest.
http://developer.nvidia.com/view.asp?IO=SphereMark

Most sphere drawing will be fill rate bound anyway, right? Therefore, how you emit the geometry shouldn’t matter much (unless they’re all 4 pixels in size and you emit 1000 tris each).

grr. i really need a good paper describing opengl optimization methods! does one knows such ?
another unexpected thing about optimization i found in this forum is that a glPushMatrix() … glPopMatrix() may be faster than another consecutive transform, for example a shift back to origin.

it really optimizes my fps - count if i use displaylists with gluSphere !!
some weeks ago i tested displaylists with a handcoded beveled cube - and there was no speed improvement with displaylists. maybe as stated somwhere in this forum the triangle count was too low.

ah, another question: (again i’m to lazy to write a simple test proggy) is the cosine / sin function on modern cpu’s fast enough so that precalculation and storing in arrays
(prebuilding an array wich holds vertices for a given stack/slices size) is slower than directly calling these functions ?

Originally posted by jwatte:
Most sphere drawing will be fill rate bound anyway, right? Therefore, how you emit the geometry shouldn’t matter much (unless they’re all 4 pixels in size and you emit 1000 tris each).

Why would NVIDIA design a tnl benchmark that draws spheres if it was fill rate bound?

[This message has been edited by Adrian (edited 06-23-2002).]

Originally posted by herc:
ah, another question: (again i’m to lazy to write a simple test proggy) is the cosine / sin function on modern cpu’s fast enough so that precalculation and storing in arrays
(prebuilding an array wich holds vertices for a given stack/slices size) is slower than directly calling these functions ?

Don’t be silly!

u could use a mesh and scale it to your needs :wink:

Heyhey… Drawing visually pleasing spheres takes some more overhead. The slices thingy looks crappy, so go from a cube or an octahedron, subdivide the faces and project the vertices on a unit sphere. Scaling is easy then. However this technuiqe is still not really pleasing. So i wrote an algo some time ago which evens out the sizes of the triangles… It’s using some sort of rubber-net to simulate forces between the vertices. The finished unit sphere can then be saved to a file for speeding stuff up.

Check the Opengl Red Book for the code for an Icosohedron (spelling?); I have, in the past, used it as a sphere approximation because the tris are uniformly distributed across the surface (note drawing a sphere as longitude and latitude slices bunches up the tris at the poles). The surface is also inherently subdivision capable, so higher levels are easy to calculate. This takes fewer tris to render a good looking sphere approximation, so renders faster in my experience.