Subject: Re: checking for next release

From: [email-masked] (Joseph D. Gradecki)
Date: Tue, 11 Aug 92 21:59:52 -0600

Dave,

  In my opinion, if things come out a little different than the industry,
this is ok.  We need the graphics system as fast as possible.  This 
becomes clearly evident when running the demo4 program in stereo.  Even on
my 486/50, we are no where near the speed we need.  If this is cut by
20%, it will certainly affect.

joe

---

From: Dave Stampe-Psy+Eng <dstamp@watserv1>
Date: Wed, 12 Aug 92 09:26:35 -0400

> From [email-masked] Wed Aug 12 00:00:08 1992
> From: [email-masked] (Joseph D. Gradecki)
> To: dstamp@watserv1, rend386@sunee
> Subject: Re:  checking for next release
> 
> Dave,
> 

I managed to get a 20% increase in stereo speed in the demo by adding
some blitter code to use 16-bit accesses if possible.  So on my machine
I get a worst-case (near the robot, looking at the window) of 8.5 fps
now (it used to be 6).  The reason is poly overlap of the walls.  Some
extra speed may be gotten by decreasing the zoom (wide-angle display
or Sega glasses with "miniaturized" world).  The demo will be updated
when the source is released.

- Dave Stampe

---

From: Dave Stampe-Psy+Eng <dstamp@watserv1>
Date: Wed, 12 Aug 92 09:48:17 -0400

> From [email-masked] Wed Aug 12 04:55:44 1992
> From: [email-masked] (Christopher Phillips)
> To: dstamp@watserv1 (Dave Stampe-Psy+Eng)
> Cc: rend386@sunee
> 
> > 
> > A final structural note.  REND386 places objects directly in the world,
> > keeping object coordinates for use in segment repositioning.  As you
> > know, most other systems only keep object coordinates, then combine
> > the object position and view matrix to render the object.
> > Now, to do this in REND386 would slow the system by about 20%, and
> > would not decrease memory requirements to speak of.  It might allow
> > the reuse of object representations, but probably not their recoloring.
> > 
>  20% seems like a very high figure. Would an extra 9 multiplyaccumulates
> per vertex per frame really take that much time?  How are viewpoints 
> currently managed?
> 
> 
> Christopher Jam	__________________________________________________
> 'Another day, another try.  But remember, SHOOT OR DIE!' -turrican
> [email-masked]		c64 forever!!!!
> ------------------------------------------------------------------
> 

Actually, this is what needs to be done:

- Precompute object center position (for fast object clip) and update
object position matrix when object moves

In the renderer:
- Convert object center to camera coordinates, check against clipping
planes (done now, no extra cost)
- Compute an object comversion matrix: inverse(VIEW)*(OBJECT) -- 36 
multiplies, 36 shifts, probably 5 cache misses
- Convert the viewpoint to object coordinates for the normal backside
test: inverse(OBJECT)*v  : 12 multiplies, 6 shifts, 2 cache misses
- Proceed normally after this.

The added time for the extra matrix steps is about 85 uS on a 486/50
per object.  For 50 objects displayed, this is about 5mS, which is about
a 20% slowdown  for a scene displayed at 30 fps.  If the objects are 
fairly complex, the speed decrement will be less.

One of the main reason matrices are used are representation sharing 
and saving time on motion.  Because most REND386 objects are simple
(for speed reasons) and only a few objects per frame move (average 2
probably) there isn't an advantage for motion.  If objects were complex
or everything moved, there'd be a BIG advantage.

Representation sharing has 2 problems: colors and scaling.  Colors could
differ between representation uses (seperate objects) but you might use a color list for each object (one entry for each poly).  Scaling affects the
normals of the polys if you don't make the X,Y,and Z scaling identical.
So to re-use a representation with scaling you either have to give up
"height control", or also have a "normal list" for each object.
You could multiply normals by the scaling, but then they're no
longer unit length and can't be used for lighting.

That's a quick analysis of the how and why of matrix-based objects.
You can see it's a fundamental change in the REND386 internals.
So unless there's a REALLY good reason...

- Dave Stampe