Browse Prior Art Database

Improved Transformation/ Rendering Pipeline for Lighting

IP.com Disclosure Number: IPCOM000108981D
Original Publication Date: 1992-Jul-01
Included in the Prior Art Database: 2005-Mar-23

Publishing Venue

IBM

Related People

Chang, FC: AUTHOR [+4]

Abstract

This article discloses a transformation/ shading/ rendering pipeline which eliminates the need to do the lighting calculation before the clipping operation.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 27% of the total text.

Improved Transformation/ Rendering Pipeline for Lighting

       This article discloses a transformation/ shading/
rendering pipeline which eliminates the need to do the lighting
calculation before the clipping operation.

      For handling geometric primitives in a lighting/shading
environment, the following pipeline is well-known (e.g., PHIGS and
graPHIGS; see Fig. 1).
1.   Geometry generation (in modelling coordinates - MC)
2.   Modelling transformation (from modelling coordinates to world
coordinates - WC)
3.   Lighting calculation

      The lighting equations are also well-known; see, for example,
(1).
4.   Viewing transformation (from world coordinates to view reference
coordinates - VC)

      The viewing transformation is denoted by V.
5.   Shearing transformation for oblique projections (done in view
reference coordinates)

      The shearing transformation converts an oblique projection to
an orthogonal one in order to facilitate clipping.
6.   View mapping and clipping (from view reference coordinates to
normalized projection coordinates - NPC)
7.   Hidden line and hidden surface removal (HLHSR) and depth cueing
8.   Workstation transformation (from normalized projection
coordinates to device coordinates - DC)
9.   Color quantization and rasterization

      The drawback of the above transformation pipeline is the
negative performance impact caused by the order of processing.  For
example, the lighting calculation is computationally very expensive;
in the above pipeline, panning/zooming of an entire scene will
necessitate recalculation of the lighting of many geometry primitives
that will be rejected (clipped away) later in the pipeline.

      In the case of scenes generated from surface primitives, this
"wasted work" effect can be very great.  From the mathematical
definition of a surface, the graphics system generates large numbers
of polygons for processing.  To improve efficiency, a clipping
boundary check is usually applied to determine whether generation of
polygons is necessary; if the clipping is performed after the
lighting calculation, and if the surface is entirely outside the
viewing window boundary, then the lighting calculation work for each
polygon will be completely wasted.
Problems Encountered When Lighting is Done After Mapping/Clipping

      If we simply reverse the order of the lighting calculation and
the view transformation/view mapping-clipping states in the pipeline
described in the previous section, several problems arise:
1.   If the sequence is changed to the order - view transformation/
shearing/view clipping/view mapping/lighting, then objects outside of
the clipping boundaries will be rejected, but the view mapping to NPC
space (normalized to a cube of unit length) will distort the geometry
of the object, and therefore the lighting calculation as well.
2.   If the sequence is changed to the order 0 - view
transformation/view clipping/lightin...