Hi, in some threads if read its good to avoid GLUT and GLAUX functions. But now I want to draw some speheres (for some billiard project) and with a quadric from GLUT it would be the easiest way (even with the textures). Now is it a good way or not?? I can''T imagine why it should be a bad idea too use! I''m not sure, but does the user have to have dll in his window folder? Or is it enough when its included in the folder of my project?? Lots of questions and a lot of thanks for a lot of answers

Yes, why not.

If you use GLUT or not, the output will be the same.

========================
Leyder Dylan
http://ibelgique.ifrance.com/Slug-Production/

If you''re already using GLUT for the graphical user interface, then it''s not really a problem to use GLUT.
But if you want to use GLUT *just* for drawing a sphere, then it''s a bad thing because you force the end-user to download and install the glut library, or you need to include glut.dll with your project sources/executables.

Either way, I don''t recommend GLUT because it''s slower and less flexible.

Performance : for instance, GLUT and GLAUX spheres have normals, texture coordinates, and vertexes, but... if your sphere is not textured, it''s a waste of time to call glTexCoord and if there''s no lights then calling glNormal is a waste of time too.

Flexibility : if you want to multitexture your sphere, or any fancy effect from per-pixel lighting to environment-mapped bump-mapping, then your control over the sphere mesh is almost null.

So what other way is there to draw an sphere easy??
I don''t want to make a model or loop thru endless sine loops just to get a simple spehere with texture and light?!

Glu has a quadratic function gluSphere() that will let you draw a sphere using a quadratic object.

Its quick, can have all GL transformation, color, material and texture commands applied to it and can be store in a display list.

Look it up in the red book.

Personaly I''d go with rendering the sphere myself - as you say with lots of sine. It''s not that hard, and it''s the most flexible method possible since you''re at the lowest level possible in OpenGL.

Though, I like reaptide''s solution too. It''s a good deal between my "brute" solution and the GLUT/GLAUX solution.

GLU is faster and more flexible than GLUT/GLAUX, but is still slower and less flexible than brute rendering.
GLU quadrics are harder to use than GLUT/GLAUX''s spheres, but still easier than brute rendering.

And as far as I know, all OpenGL implementations also support GLU (that means you don''t have to provide glu32.dll : chances are the end-user already has it in his computer), and some implementations can use hardware acceleration for some GLU operations.

Or a subdivided icosahedron if you want LOD! That way you can use more polys for the billiard balls closer to you, and less for the ones further away.

See Example 2-13 on this page for the basic technique, or this FlipCode IOTD for an advanced example with LOD.

Although I''m having problems texturing mine right now...

Since successive calls to glut*Sphere() functions could pass in different parameters for stacks and slices, glut re-generates the geometry at each function call.

Therefore, make sure to create the sphere in a display list and to call the display list instead of glut*Sphere(), that will substantially increase your performance.

Documents [ GDNet | MSDN | STL | OpenGL | Formats | RTFM | Asking Smart Questions ]
C++ Stuff [ MinGW | Loki | SDL | Boost. | STLport | FLTK | ACCU Recommended Books ]

Fruny, love the sig

www.coldcity.com
code, pics, life