From: Dave Stampe-Psy+Eng <dstamp@watserv1>
Date: Wed, 29 Apr 92 18:51:45 -0400

As REND386 evolves, it is becoming apparant that it will be quite 
different in some ways from the design originally planned.  The 
main reason for this is time limitations and a better understanding
of hardware and processor constraints of the 386 PC and VGA card.

SPEED
First, drawing polys has not turned out to be the paramount speed
limiter, as originally thought.  Indeed, processor and cache-miss
penalty factors seem to be equally as important.  The real limit in
drawing is appearing to be the clearing of the screen-- hundreds of
polys can be drawn in the time it takes to clear the video buffer.
The layering of polys is not the concern it was thought to be, due
to the relativly sparse scenes typical of the VR applications and
the early elimination of backfacing polygons.

The speed of the code written so far is about 30%-50% slower than
initially calculated.  The reason seems to be cumulative cache miss
penalties, and some other processor penalties.  It is very hard to
locate or fix these problems in software.  There are some further 
speedups possible in the renderer code by switching from far to
near pointers at certain points, but the overall speedup from this
is less than 10%.  This change would make the code difficult to 
modify, so is probably not worth the effort.

DEPTH SORTING, VISIBILITY ERRORS AND WORLD DIVISION
The present version of REND386 uses simple depth sorting by farthest
polygon vertex to determine the order in which polys are drawn.  This
results in visibility errors on some non-convex objects.  We have 
recently been sent some .plg files which show serious visibility
errors, so can proceed to look for solutions.

The original plan was to implement a scanline renderer.  However, 
due to the slower-than-expected processor rates and better video 
speed, it is clear that the initial reasons for using this method
(apart from lack of visibility errors) are no longer valid.  The
current estimates are that scanline rendering would almost double the
rendering time.  (The C code for the scanline renderer is tested and
debugged, but would take about 2 weeks to integerize and code).

Instead, some simple ways of reducing visibility errors will be 
pursued.  This will not help with complex objects, but will result in
a usable, fast VR renderer.  The results will be similar to the 
SuperScape demo, without its movement limitations.

The first method is to keep objects together when drawn.  The method 
will allow object polys to be kept together or sorted into the world
poly list.  Objects and polys are sorted together, then objects are
expanded into polys and sorted locally.  The sorted list is then
rendered.  The point in an object used for the depth sort may be
shifted in order to reduce visibility errors if desired.

Secondly, the world may be "split" into areas by BSP-like planes.
These may be associated with a wall or object, so that all objects on
the far side are drawn, then the wall or object, then the objects
on the near side.  Optionally, objects on the far side may be ignored.
A tree structure of "splits" can be used to keep the number of polys
and objects to be drawn at any time quite small.  For example, rooms
can be designed with or without windows and doors, etc.  This is 
equivalent to object-based BSP trees without the need to split polys.

The REND386 world then consists of a "splits" tree, a number of
movable (segmented) figures, and a number of fixed or movable
objects.  If objects are moved, they must be checked and possibly 
relocated in the "splits" tree.  Since in most cases the glove figure
and possibly one or two objects are moving at once, this is cheap.

These modifications will produce better results than pure depth sorting, 
especially if objects are designed to eliminate visibility errors, such 
as by splitting complex objects into several objects.  Of course, this 
is not as good as if real depth sorting with overlap detection was used.
This last method is even slower than scanline rendering or BSP trees.

These new features will result in a REND386 that has almost the same
speed as the present version, but is usable for VR work.  It will not
be a complete general-purpose renderer because of the visibility errors.
These errors can only be reduced by careful world and object design,
or by the investment of more time on REND386 and reducing the drawing 
speed by half.

--------------------------------------------------------------------------
| My life is Hardware,                    |                              | 
| my destiny is Software,                 |         Dave Stampe          |
| my CPU is Wetware...                    |                              | 
| Anybody got a SDB I can borrow?         | [email-masked] |
__________________________________________________________________________