Subject: Hidden surface?

From: [email-masked] (Tng Tai Hou)
Date: Sat, 25 Jul 92 10:32:27 SST

Hi. Can someone discuss at length on the techniques used
in Rend386 for hidden surface removal and rendering and clipping?

Thanks.

Tai Hou
Singapore

---

From: Dave Stampe-Psy+Eng <dstamp@watserv1>
Date: Sat, 25 Jul 92 01:50:58 -0400

> From [email-masked] Fri Jul 24 22:36:39 1992
> From: [email-masked] (Tng Tai Hou)
> To: rend386@sunee
> Subject: Hidden surface?
> 
> 

Hidden surface removal: with release3, RND386 simply sorts polys by 
farthest vertex, then draws from farthest to nearest.  Usually
works OK.  Release 4 introduces sorting by object, then by polys
within objects (tweeking this can cut visibility errors way down,
but doesn't fix them all.  It also introduces "splits", which are like
BSP trees but don't divide objects or polys.  

Basically, a split is a plane which divides space in two.  By specifying
the order in which splits are created and by giving a sample point on
the split, you can create a tree of splits.  These divide the world into 
areas.  By hanging objects (i.e. walls) from the splits, you can fix
big visibility errors.  For example, by defining a split as part of a wall, the renderer willdraw all objects further from the viewpoint than the
wall, then the wall, then all objects nearer.  Thus you'll never see anything
through a wall, unless thr wall has a hole in it.

There are some problems with splits, but we're working on them.

Rendering:
REND386 basically draws polys (specified by a CCW-ordered list of
vertices) directly to the screen buffer.  You can preclear the 
screen buffer (or not, if you're inside a room with no windows) and
with release 4, you'll be able to draw a horizon with ground and sky clear.
You can also draw polys with metal (brightness cycling) and glass 
(halftones for transparent polys).

The color of a poly can be calculated in user_poly_color() so you're
free to modify lighting, colorsets, etc. as you see fit.  Release 4
MAY include multiple light sources or something-- not sure yet.  But
it will support ambient lighting as well as cosine lighting.  Point
sources as well as directional light sources too.

Clipping:
REND386's calcultion pipeline clips in several stages, trying to decimate
the number of polys to draw as early as possible.  Does it really help?
Who knows.

The first step is to check if the bounding sphere of an object is entirely
outside of the 6 planes bounding the view pyramid.  The slope of the side
planes is computed using screen dimansions, zoom, and offsets, and
the calculations are pretty fast.

Next, the object is processed poly by poly (if it passed the object
clip test).  Each poly is checked to see if it's backfacing by doing
a dot product between the poly normal and the line from one of the vertices to
the viewpoint.  The sign of the d.p. determines if its backfacing.

Now a pass thru all the vertices of the poly converts the Z coordinate
to viewport coords, and computes an outcode.  Lots of polys lost here.
Then the poly is z-clipped (if the outcode says it needs it).  After
this, the x and y coords are converted to viewport coords.

The x and y are divided by Z to get perspective, and the x and y outcodes
are generated.  If required, the poly is XY clipped in screen coordinates.
The clipper is a reentrant Sutherland-Hodgeman clipper which passes each vertex
thru a pipeline of top, left, bottom, and right clippers, then flushes any
pending data at the end of each poly.

The polys are then colored and lit, and the vertices unpacked for
after the polys are sorted.  The unpacked vertices, along with color info,
are then rendered.

Things can get more complex than this, of course.  This is an overview 
of essentials

- Dave Stampe