Path: utzoo!attcan!uunet!decwrl!lll-winken!ames!sgi!shinobu!odin!rudedog!bam
From: bam@rudedog.sgi.com (Brian McClendon)
Newsgroups: comp.sys.sgi
Subject: Re:  gl question - editing large objects
Message-ID: <10940@odin.corp.sgi.com>
Date: 26 Jul 90 17:37:55 GMT
References: <9007251346.AA24480@acf4.NYU.EDU>
Sender: news@odin.corp.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 54

In article <9007251346.AA24480@acf4.NYU.EDU> karron@ACF4.NYU.EDU (Dan Karron) writes:
>My understanding that graphical objects are not the way to go since
>the new cpus can keep up with the graphics pipeline. 
>
>Is it correct to say that the entire compiled objects part of the gl is
>obsolete ? Are there any specific instances where you should use it ?
>
>dan.

Here's the story:  

The main advantage of objects (aka display lists) is their ability
to draw quickly once generated.  In a large program with hundreds (or
thousands) of lines of rendering code, its much easier to generate
an object with the complex code and view it with a tight loop of
callobj()s than it would be to tune the rendering code up to
the speed of the graphics.

On a GT/GTX it was discovered that there was no reasonable way to
make v3f() object-able without impacting its immediate mode performance.
This caused the GT version of the GL Reference Manual and GLPG to
have words to the effect that objects were heading for obsolescence.
This is no longer true.

With 3.3, we discovered a way to use the shared library jump table
to make all of the high performance routines object-able without
slowing their immediate mode performance.  On the VGX in particular
there are a couple of cases where objects draw slightly faster
than the best immediate mode code (slightly = <20%).


To meet the performance of the GT/X and VGX graphics, immediate
mode code should have no more than 3 lines of MIPS assembly for
each call to v3f/c3f/n3f (and equiv).  This applies for "fast path"
quads and tmeshes where fast path is a single-infinite-light, 
flat-or-gouraud, ~50-pixel-tri-or-~100-pixel-quad.  More options
will slow down graphics to the point where more MIPS code can fit 
in without degradation.

On a Personal Iris, the balance is more in favor of the CPU, but
if you want your code to remain graphics limited when you move
up to faster graphics hardware, keep the above in mind.

Editing objects always has been, and probably always will be
slower than users would like.  The main question is: how much
editing are you going to be doing?  If you change most of your
scene every frame, objects probably aren't a good idea, but if
you keep most of your scene constant or change it infrequently
then objects could be used to your advantage.

Experimentation is the best way to find out if its right for your application.  
----------------------------------------------------------------------------
   Brian McClendon bam@rudedog.SGI.COM ...!uunet!sgi!rudedog!bam 415-335-1110
-----------------------------------------------------------------------------