Path: utzoo!utgpu!news-server.csri.toronto.edu!dgp.toronto.edu!rodney
Newsgroups: comp.sys.sgi
From: rodney@dgp.toronto.edu (Rodney Hoinkes)
Subject: GL questions to the world
Message-ID: <1991May14.193934.6923@jarvis.csri.toronto.edu>
Organization: Centre for Landscape Research, University of Toronto
Date: 14 May 91 23:39:34 GMT
Lines: 86

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?

--- END of question 1 ---

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

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.  Can the z-buffer not maintain
and check the alpha planes?

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.

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?

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?

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