GL questions to the world

[Kurt Akeley]

In article <1991May14.193934.6923 at jarvis.csri.toronto.edu>, rodney at dgp.toronto.edu (Rodney Hoinkes) writes:
|> We have run into great problems due to the fact that we are
|> running IRIX 3.3.2 but want to give our program to a group
|> running 3.2 (Alias supported <- probably why they are still
|> behind).  Our code is NOT using and 3.3 specific code but
|> unless we go back to 3.2 on our system and compile it, they
|> cannot use it.
|> 
|> Does anyone at SGI have a better solution?  Could something be
|> done about this in the future? Shouldn't shared libraries handle
|> this?
|> 
|> Note, we are also using libfm, lidbsd which are not shared.  Would
|> that be the technical reason?

I don't think that there is a better solution.  Anyone else?

|> Now while I'm using net bandwidth, I'll save the space of the header
|> and ask a few other questions.
|> 
|> Not having the source to Flight, I can only speculate how the fog is
|> done as I am trying to replicate the effect in some of my code. If
|> someone with the code could set me straight, this is how I think it
|> must be done:
|> 
|> A number (based on desired fog thickness) of fogged/alpha'd polygons
|> are set perpendicular to the viewer at certain distances apart to
|> get thicker fog in the distance.
|> 
|> 		V -->|  |  |  |  |
|> 			 ^
|> 			 fogged/alpha'd planes

VGX models use the fogvertex() GL capability.  In the general case image
quality is improved by also using scrsubdivide GL capability, which
subdivides polygons at planes perpendicular to the view direction.
Flight avoids the performance loss of scrsubdivide by pretesselating
its terrain.

|> Also,
|> 
|> Is there any way to avoid having to calculate which alpha'd objects
|> are closest to the viewer and draw them in the order from back to
|> front in software rather than using the z-buffer?  This problem
|> exists with anything that is alpha'd including textures and makes
|> the rendering of 1000's of alpha'd objects in real-time difficult
|> due to CPU-intensive caculations.

To get the right answer you must sort the polygons back to front.  There
are, however, may tricks that result in acceptable images with less
sorting overhead.  

|> Can the z-buffer not maintain and check the alpha planes?

It can "check the alpha planes", but then what?  It would need to maintain
a sorted list of polygons at each pixel to produce the correct result.
The VGX hardware does not have this capability.

|> And while I'm on a roll,
|> 
|> I am trying to draw some really warped polygons, with each x,y point
|> on it having a different z value.  Some of them fail to be rendered
|> even with concave(TRUE) on.

Warped polygons become self-intersecting polygons when viewed at bad
angles.  The GL makes NO promise about how self-intersecting polygons
with more than 4 vertexes are drawn.  To achieve maximum performance,
subdivide ALL of your polygons into triangles, and assemble these
triangles into meshes.

|> And to keep going,
|> 
|> If I turn subpixel(TRUE) on my VGX, I only notice about a 10% speed
|> increase on fairly raw gl drawing (little CPU-intensive work), but
|> I have seen much greater benefits of code with this in it?  Is there
|> something I might be missing that would lower the benefits of this
|> routine?  And speaking of speed, what sort of degredation does
|> concave(TRUE) impose?

Your application is probably pixel fill limited, rather than transformation
limited.  Hence subpixel, which affects transformation rate, has little
effect on the overall performance.

|> And one more to people out there,
|> 
|> Why is Feedback so machine dependant?  Not the fact that it is
|> different for each machine, but the fact that the headers are different
|> on each type of machine (PI, GTX, VGX) so you MUST compile
|> a separate version for each machine, rather than determining
|> machine type at runtime and having all options in code.  I have had
|> to make my own defines for FB_POLYGON etc. for each machine type
|> and call the appropriate handler based on machine determined at
|> runtime.  I have been lucky in that I have access to PI's, GT's, and
|> VGX's to do this.  Why couldn't SGI have done this?

Feedback has not been a priority, so it has received minimal attention.
As partial justification, note that pipeline hardware systems with long
latencies (i.e. high performance GL machines) perform poorly when run
in feedback mode.  Thus, if you are striving for "the optimum performance",
as you mention below, you won't be using feedback anyway.

|> Ok, I've spoken my piece.  I hope people out there have answers as I
|> have been trying to get the optimum performance out of my new VGX and
|> I don't think I yet understand the true implications of various
|> gl routines on graphics performance.  The manuals only state vague
|> "this will slow down the system" or "this will speed up the system"
|> statements.
|> 
|> I am using a 310VGX, 5-span, 3.3.2.  Any comparisons of various GL
|> routines around versus GTX, GT, or PI machines?  I also use a 70GT,
|> 20TG, and 25TG.
|> 
|> -- 
|> ---
|> 	Rodney Hoinkes
|> 	Centre for Landscape Research
|> 	University of Toronto