Efficient use of lighting models

Rob Mace mace at lum.asd.sgi.com
Tue Oct 30 13:28:30 AEST 1990


In article <9010250912.aa15161 at VGR.BRL.MIL>, XBR2D96D at DDATHD21.BITNET (Knobi der Rechnerschrat) writes:
>  The question arises wether it is faster to use just one material and
> change its properties using lmcolor/cpack like this:
> 
>   lmcolor(LMC_DIFFUSE);
>   lmbind(MATERIAL,template);
>   bgntmesh;
>   for all vertices {
>     if(newcol != oldcol) { cpack(newcol);oldcol=newcol;}
>     /* the oldcol/newcol stuff is just to avoid unneccessary cpack's */
>     n3f(normals);
>     v3f(coordinates);
>     }
>   endtmesh;
>   lmcolor(LMC_COLOR);

Using lmcolor as you describe is the prefered way.  The VGX lmcolor speed
problem will be fixed.

>  A second question arises for the LMC_AD mode. How does it work? Does
> it set AMBIENT and DIFFUSE to the same RGB-values?

Yes, it sets AMBIENT and DIFFUSE to the same RGB-values.  To vary the
contribution of AMBIENT and DIFFUSE just adjust the amount of AMBIENT
light in your scene.

>  Finally I've got a question concerning the memory alignment of normal
> and coordinate data. From the release notes I know that for the GTX
> this kind of data has to be quadword aligned to get best performance.
> We are currently allocating normals and coordinates in onedimensional
> arrays (float) of this form:
> 
>    x0,y0,z0,x1,y1,z1,....
> 
> and pass the adress of the xn-element to n3f/v3f. Should we better
> allocate additional (dummy)-space for the w-elements to get the
> best performance on the gtx? As this would mean 33% more memory usage
> for vertices and normals, we like to avoid it if possible. How large
> is the performance loss if one does not use quadword aligned data.
> What are the effects on other machines (esp. VGX)?

It is important to quad word align data on both the GTX and VGX.  Given
your example you would want your data to look like the following.

   x0,y0,z0,dummy,nx0,ny0,nz0,dummy,x1,y1,z1,dummy,nx1,ny1,nz1,dummy,...

The preformance loss if you do not do this depends completely on how
complex your current drawing algorithm is (i.e. It will effect things
more if you are doing infinite as opposed to local lighting).

If you are coloring your data also the cpacks can fit in place of a dummy
and you will not be wasteing as much memory.

Rob Mace



More information about the Comp.sys.sgi mailing list