
\documentstyle[12pt,lslide]{article}

\input{psfig}

% Page orientation
\landscape  % or portrait

% Tune page lengths
\addtolength{\topmargin}{0.3in}
% \addtolength{\textwidth}{1in}
\verttop

% Subsection headings
\underlinesecframe

% \smallerfonts

% Tune the paragraph and list parameters
\parskip=10pt
\parsep=0pt
\topsep=0pt
\partopsep=0pt
\itemsep=0pt
\listparindent=0pt

% Change default footer parameters
\lfoot{Paul Coddington, NPAC, paulc@npac.syr.edu}
\rfoot{Oct 94, CPS-PR-\thepage}

\begin{document}

\title[CPS 713 Parallel Rendering]%
      {CPS 713 \\ 
       \vspace{1cm}
       Parallel Rendering}

\author{Paul Coddington and Alvin Leung}
\organization{Northeast Parallel Architectures Center}
\date{October 1994}

\titlepage

\section{Overview of Computer Graphics}


\begin{slide}
\subsection{\bf Computer Graphics}

  The goal of computer graphics is to show a virtual world.
  This virtual world is composed of many different objects.
  A rendering program takes the computer models of the objects and 
  converts them into an array of pixels that are rendered on the 
  computer screen to give an image of the virtual world.
  The virtual world in this talk consists of two milk cartons.
  
  \vspace{1em}

\begin{figure}[h]
\centerline{\psfig{figure=object.eps,width=3.2in}}
\end{figure}

\end{slide}


\begin{slide}
\subsection{\bf Object Representation}

  How the objects are
  represented in the object database has a major impact on the rendering
  performance, the quality of the generated image and the time needed to
  construct the virtual world database.

  The milk cartons can be represented in two ways. In the first method,
  the milk cartons are represented as a milk carton object.
  The scene designer need only specify the dimension,
  the texture map and the color.  Each object in turn is composed of
  number of rectangular and triangular 3D sub-objects.  
  The sub-object is positioned relative to an anchor point of the object.

  These objects are analytically defined, so there is no limit on resolving
  the details of the object.  The resolution of the object is bounded 
  instead by the surface texture map.

\end{slide}

\begin{slide}
\subsection{\bf Polygon Representation}

  The second method of modeling an object is by polygons.
  Generally, 3 or 4 vertex polygons are used.  Triangles are more often used
  because all vertices of a triangle are coplanar,  so the polygon will
  have only one normal, which greatly simplifies some rendering computations
  such as shading. 
  The scene designer will construct
  an object one polygon at a time, and then define the surface texture
  and the color for each of the polygons. 
  
  The motivation for defining an object by polygons is flexibility of
  the object representation. 
  Each polygon is represented by a fixed set of points and edges joining
  the points.
  These points can be arbitrary positions in 3D space, so
  deforming an object is a relative simple task  
  (e.g. a filled milk carton's side can be slightly warped).

\end{slide}


\begin{slide}
\subsection{\bf The Rendering Process}

Rendering a 3D image requires the following computational procedures:

\begin{enumerate}
\item Transformation
\item Hidden surface removal 
\item Clipping 
\item Rasterization 
\end{enumerate}

\end{slide}


\subsection{\bf Transformation}

\begin{slide}
  The positional placement of the objects relative to the viewer
  is done by transformations. 
  The transformation process includes translation, rotation and scaling.  
  Each individual transformation can be represented as a 4x4 matrix
  (one extra dimension for non-linear perspective scaling).
  These matrices can be multiplied together to form one final 
  transformation matrix, which is used to transform the objects.
  Transformation is used to place the virtual world in the viewer's
  perspective.

  An analytically defined object is moved by
  transforming the anchor point of the object.  
  The transformation can therefore be done to the object as a whole,
  and thus takes time O(\#objects).
  Transformation of a polygon-based object requires computation at
  each vertex, and thus takes time O(\#vertices).

  % Finally, window to viewport transformation is used to correctly scale and
  % place the generated image on screen.  %??
\end{slide}

  
\begin{slide}
\begin{figure}[h]
\centerline{\psfig{figure=transform.eps,width=6in}}
\end{figure}
\end{slide}


\begin{slide}
\subsection{\bf Hidden Surface Removal}

  Even when an object is within the field of view, it may still
  not be visible to the viewer -- for example, an object located behind a 
  closed door. These have to be eliminated from the object rendering list. 
  
  Hidden surface removal could also be done later in the rendering process
  (during rasterization), by just having objects closer to the viewer
  overwrite objects further away.
  However, this wastes considerable computation in unnecessary rendering of
  these hidden objects. It is cheaper to identify and remove them 
  earlier in the rendering procedure, when the work is proportional to 
  the number of objects rather than the number of pixels.

  For polygon-based rendering, hidden surface removal can be
  done very fast by just culling the back-facing polygons.

\end{slide}
 

\begin{slide}
\begin{figure}[h]
\centerline{\psfig{figure=culled.eps,width=6in}}
\end{figure}

\end{slide}


\begin{slide}
\subsection{\bf Clipping}

  Clipping is done to eliminate objects (or parts of objects)
  that are outside the field of view, for example, objects behind the viewer.
  Clipping also speeds up the rendering process since the eliminated objects
  do not need any further processing.
   
  Clipping can also be used to eliminate unwanted objects, for example
  those that are too far away to have enough effect on the scene to warrant
  the amount of computation required to include them.

\end{slide}
  
\begin{slide}
\begin{figure}[h]
\centerline{\psfig{figure=clipped.eps,width=6in}}
\end{figure}
\end{slide}


\begin{slide}
\subsection{\bf Rasterization}

  Rasterization is done to transform the data represented by the object
  database into a pixel-based image.  Texture mapping, color computation,
  shading and anti-aliasing are done at this stage.  
  
  For a polygon based object, a {\it scanline} algorithm is commonly used 
  to render the final image.   
  The pixels are scanned a line at a time and their color is determined
  from the polygons that contribute to that part of the screen.

  The colors of the polygons are specified either at the vertices, in
  which case interpolation is used to find the pixel color, or by a
  texture map, which can be transformed into the appropriate pixels.

  A {\it Z-buffering} algorithm is used to ensure that objects closer to the 
  image (along the $z$ direction) are rendered last, so that partially 
  obscured polygons are overwritten (as they should be).
  
\end{slide}
  

\begin{slide}
\begin{figure}[h]
\centerline{\psfig{figure=scan.eps,width=6in}}
\end{figure}
\end{slide}


\begin{slide}
\begin{figure}[h]
\centerline{\psfig{figure=raster.eps,width=6in}}
\end{figure}
\end{slide}


\section{Terrain Rendering}


\begin{slide}
\subsection{\bf Terrain Object Representation}

A terrain object is defined by an elevation (height) field and an image.
The elevation field encodes information as elevation $y$ for a
specific $(x,z)$ coordinate. The image gives the color associated with 
the coordinate. This information can be obtained from a digital elevation 
model (DEM) and a satellite image of the terrain. 

A terrain is a simply connected surface so (i.e. no disjoint sections),
so terrain rendering is a special case of volume rendering, sometimes 
described as 2.5D rather than 3D. This allows a number of optimizations
to be used in the rendering process.

The terrain data set is stored as a number of two dimensional grids. 
Each grid contains a subsection of the terrain data set. 
The data is stored as triangular polygons made by triangulating the 
square mesh used as the basis of the DEM.

\end{slide}


\begin{slide}
\subsection{\bf Polygon Representation}

The terrain data can be stored at different levels of resolution.
Coarser resolution polygons can be used for terrain further from the 
viewer. This will greatly reduce the computational requirement. 
%
Can do this very simply by just using a coarser mesh, but may be 
more effective to use an adaptive scheme with a very coarse 
mesh for flat regions (lakes, plains) and a less coarse 
mesh for mountains.

\begin{minipage}{4in}
% \begin{picture}(288,288)
\centerline{\psfig{figure=grid1.eps,width=3in}}
% \end{picture}
\end{minipage}
\ \
\begin{minipage}{4in}
% \begin{picture}(288,288)
\centerline{\psfig{figure=grid2.eps,width=3in}}
% \end{picture}
\end{minipage}

\end{slide}


\section{Parallel Rendering}

\begin{slide}
\subsection{\bf Parallel Rendering Algorithms}

The rendering pipeline remains the same as the sequential algorithm,
with polygon calculations (transformation, clipping, hidden surface
removal) and pixel calculations (rasterization).

Both types of calculation are completely independent, so can trivially
parallelize over polygons or pixels. However there are the usual 
problems that need to be overcome to get good performance, which is
particularly crucial for real-time animation.

There are also parallel algorithms using raytracing and raycasting,
which are inherently parallel. These methods produce hihg-quality results
but are more computationally intensive, so are usually used for making
movies rather than interactive simulations. 
JPL has a parallel raycasting program that is used to make movies of 
simulated flights over Venus, Mars, and the Earth.

\end{slide}


\begin{slide}
\subsection{\bf Problems with Parallel Rendering}

{\bf Load balance} is needed for the polygon calculation. A scattered
or cyclic distribution may work well, or else do dynamic load balancing
by using data on work distribution for previous frame to load balance 
the next frame.

{\bf Parallel overhead} is incurred due to the two different data 
decompositions used (polygon domain and pixel domain). Since polygons
are irregular they will overlap pixel regions on different processors.
Polygons can be cut at processor boundaries. 

{\bf Communications overhead} must be minimized since a frame has
to be rendered and displayed every 40 msec for real-time animation. 
Cannot afford too much communication if latencies and communications 
times are in the msec range. Overlap calculation and communication?

\end{slide}


\end{document}

