kahn@uxh.cso.uiuc.edu (Scott Kahn) (10/22/90)
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. 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. I will post whatever words of wisdom I receive... Thanks, Scott Kahn Department of Chemistry University of Illinois at Urbana-Champaign
kurt@cashew.asd.sgi.com (Kurt Akeley) (10/23/90)
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