From: smr@cs.stanford.edu
Newsgroups: su.class.cs248
Subject: Re: a request, a url, and another request
Date: 8 Nov 1999 05:14:03 GMT

James Hubert Falkner <jf0@leland.Stanford.EDU> wrote:
> In article <3826213E.274FCEA2@stanford.edu>,
> Susheel M. Daswani <sdaswani@cs.stanford.edu> wrote:

> >  to the tas: i think display lists are going to be very important for
> >this assignment (correct me if i am wrong), would it be possible to make
> >this a topic of significant coverage at the next help session?

> Yeah, I've actually been wondering about it myself.. I am pretty new to
> OpenGL, and the "Red Book" is a good starting book.. But it seems to
> present the basic API..  and then the last page of each chapter goes
> something like "Ok, now that you know the API, here's a short example
> showing you how to use the advanced API that you will REALLY use in
> practice" .. And while I'm all for "knowing what goes on under the hood",
> I'd really appreciate it if someone made it more clear what we should be
> using, rather than wasting 2 or 3 days writing some code and finding out
> that it runs poorly everywhere, because I didn't use a display list or
> didn't use a particular flavor of an API call.. We don't have time to
> explore and learn by trial and error for this assignment, unfortunately. 

Making your rendering efficient is certainly an important part of graphics
programming.  Using things like triangle strips, display lists, vertex arrays,
texture contexts, and other OpenGL features can often make a difference of
a factor of 5 or more in how fast a scene is rendered.  We'll try to include
some information on this in the OpenGL help session (the date and time still
have not been determined, by the way), but meanwhile here are some general
(and specific) rules of thumb:

1. If you are using many small polygons, definitely consider using triangle
strips.  Depending on the size of the triangle and the details of the hardware,
drawing triangle strips can be up to 3 times faster than drawing individual
triangles.

2. How much benefit you get from display lists is extremely system dependent. 
On lots of hardware, it does not speed things up at all.  On other graphics
implementations, you might see a substantial speedup (sometimes a factor
of 2).  If you have some piece of the geometry that never changes, you can
consider putting it into a display list.

3. Much the same argument holds for vertex arrays: it might or might not speed
things up.  Again, vertex arrays are probably most useful if you have some
piece of the scene for which the geometry is static.

4. If you are using multiple textures, definitely learn about and use texture
contexts.  Big win.

5. You should definitely be spending most of your time running with backface
culling enabled.

6. If you are doing glDrawPixels or glReadPixels, pay attention to the
datatypes.  In general, GL_RGBA, GL_UNSIGNED_BYTE will be the fastest on
most hardware.  Asking for your colors as floats will often require a data
type conversion for each pixel.

7. On the other hand, geometry you pass to OpenGL should always use floats. 
Doing something like glNormal3i will require a type conversion.

8. Avoid doing glScale, unless you absolutely need it.  The reason for this is
that if you have something scaled and lit, you will often have to
glEnable(GL_NORMALIZE).  That slows you down.

9. Using really fancy features like scissoring, stenciling, fog, pixel logical
operations, etc. will often be slow.  If you plan to rely on these in your
game, check your hardware first to see how badly they'll slow you down.

10. SGI has a guide to their implementation of OpenGL on their systems at
http://techpubs.sgi.com/library/tpl/cgi-bin/download.cgi?coll=0650&db=bks&docnumber=007-2392-002
You might find chapters 13-16 interesting reading.  Much of the advice they
present there is applicable to a reasonably wide range of modern graphics
hardware, including PC cards.


In addition to these hints, you should really consider algorithms in your game
that will try to cut down on the complexity of what needs to be drawn,
preferrably dynamically.  That is, if you have some object that uses tons of
triangles, consider including lower-res versions of it and switching to them
if you detect that your renderer is not keeping up with your desired frame
rate.  If you are using lots of texturing, blending, fog, etc., consider
having options to turn these features off.  In general, pretend you're a game
company and write a game that will run and remain playable on a wide variety
of platforms and graphics hardware of vastly differing capabilities and
speeds.

 - Szymon