Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!mips!sgi!shinobu!odin!cashew.asd.sgi.com!kurt
From: kurt@cashew.asd.sgi.com (Kurt Akeley)
Newsgroups: comp.sys.sgi
Subject: Re: VGX graphics and depthcueing
Message-ID: <1990Oct22.204337.1164@odin.corp.sgi.com>
Date: 22 Oct 90 20:43:37 GMT
References: <1990Oct22.015204.24603@ux1.cso.uiuc.edu>
Sender: news@odin.corp.sgi.com (Net News)
Reply-To: kurt@cashew.asd.sgi.com (Kurt Akeley)
Organization: sgi
Lines: 47

In article <1990Oct22.015204.24603@ux1.cso.uiuc.edu>,
kahn@uxh.cso.uiuc.edu (Scott Kahn) writes:
|> I have found that generally speaking, the high-performance drawing
|> routines and depthcueing are not compatible on the VGX. That is,
|> on a GTX or PI one can intermix "v3f" and "lRGBcolor" freely, however
|> this does not work on the VGX. Apparently (according to the 3.3 man
|> page) one should not be doing this at all, and that it functions
|> on GTX and PI graphics is an "undocumented feature". Here's
|> the question:
|> 
|> If one desires to recolor each vertex of a tmesh, poly-line or
|> poly-point using depthcueing, can this be done on the VGX short
|> or digressing to simple triangles, two-point lines, and single
|> points?? While the alternative of using lighted lines has been
|> tried, sometimes depthcueing is preferred.

Yes!  But the technique is not obvious.  The problem is that depthcueing
replaces, rather than modifies, vertex colors.  Thus calling cpack()
while depthcueing has no effect.  Fog, however , is a color modifier.
If you enable fog with black as the background color, you will be able
to depthcue to a black background while changing colors on a per-vertex
basis.  Set shademodel to FLAT if connected line segments are to be
constant colored.  The coloring will then be constant, but the depthcue
effect will blend smoothly.

Using fog for depthcueing is the preferred method for VGX machines.
Currently only the exponential model of fog is supported, so you depthcue
effect must be exponential.  Future software releases will support fog
that is linear in eye-coordinates.

|> VGX observation two. It would seem that drawing tmeshes with arbitrarily
|> colored vertices (using two infinite light sources and three "lmcolor"
|> calls to alter vertex color characteristics) is actually FASTER on the
|> GTX rather than the VGX. Is this a generalization or can something
|> (no quad-mesh suggestions please!) be tuned on the VGX to enhance its
|> performance.

The current VGX microcode release has poor performance for lmcolor.  This
will be corrected.  The performance will NEVER be good, however, if you're
actually calling lmcolor between vertex calls.  The intention of the lmcolor
command is to support rapid changing of one lighting parameter, typically
diffuse color.  Used in this manner, lmcolor is called just once, to specifiy
which paramter is to be changed.  Then c() or cpack() is called for each
vertex.  High-performance applications NEVER call lmcolor between bgn/end
pairs.

-- kurt