Performance using GluQuadrics over OGL Parametives

Started by
5 comments, last by Roach 22 years, 10 months ago
Hi guys, I am almost finished a major milestone in our project here at Raytheon - soon to be starting fresh again in a few weeks. During that time I plan to be redesigning my OpenGL area so it can be more efficient and easier for the guy that takes over after me to maintain. For those of you that don''t know my project deals with a creation of a textured Globe(that does some cool stuff!!) Here''s my question - The current globe is drawn using numerous Triangle Strips, and then normals and texture coordinates are made for lighting and texturing. My question is if it would be better for me to use the GluQuadric gluSphere() to draw my globe instead of using the triangle strips. I know gluSphere has the benefits of already having the normals defined as well as a nice auto-generating texture coordinates. (Which saves me the hassle of coding them by hand!!). But is there a performance hit by using a GluSphere over doing everything by hand? I know that in the end the GluSphere eventually gets reduced to triangles and points anyways, but is there a hit taken in this process? If so -is it a big one? Using gluSphere would definitely be easier for an outsider (non OGL guy) to follow when reading my code. Instead of having a page and a half of normals, texture coordinates, and vertexes to look at - but if it''s a big performance hit -it probably wouldn''t be worth it. Any thoughts? Roach
Advertisement
it will definitly slow down.

http://members.xoom.com/myBollux
what makes quadratics so much slower than primatives?

Scott

Email
Website

"If you try and don''t succeed, destroy all evidence that you tried."
the extra calculations and rendering. (if you specify it to render more)
edit: more strips that is

HHSDrum@yahoo.com

Edited by - Julio on June 6, 2001 11:11:06 PM
My HomepageSome shoot to kill, others shoot to mame. I say clear the chamber and let the lord decide. - Reno 911
Thanks guys,
I knew that the calculations of auto-generating normals and texture coords would be a hit. BUT, how much of a hit would it be? I am figguring that this sphere would need about 40-50 Slices and Stacks, it would be required to rotate, zoom, pan, etc. It would also have things pop up on it on a one second basis (worst case synario).
Readibility of the code is important - we here at Raytheon are not graphics experts, so simple = better. Unfortunitly we also can''t afford to have a HUGE perfromance hit as well. I am willing to take a small one though. So if anyone know how much of a hit it will take? Will putting the GluSphere and all the Auto Generation of normals, vertexes, and texture coords in a display list help?
Looking for ideas . . .

Thanks
Roach
Well, I have no idea how much of a performance hit there will be, but my suggestion is to try it out. Since you already have the more difficult route working, it should be very simple to convert to the other way, and test to see for yourself how much of a difference it makes. If the sphere is going to be static then a display list could make the gluSphere() method just as fast as the primitive method.

j.w.
Good Idea, Thanks a lot JW!!!

Roach

This topic is closed to new replies.

Advertisement