🚀 go-pugleaf

ressler@CS.Cornell.EDU (Gene Ressler) writes:

>easy to program from.  S/H is in Foley and Van Dam, Fundamentals
>of interactive computer graphics (and many others).  They do a chapter
>on `the graphics pipeline' that is _very_ worthwhile study if you're doing
>3D imaging.  These guys virtually invented computer flight simulations; they
>know what they're talking about.

>Having said this, I gladly admit that programs like MS Flight simulator
>play all kinds of games to get around the expensive (read floating point)
>computation of the above algorithms.  But you can't understand the games
>until you've got the rules.

I actually have one of those pipelines described in Foley & Van Dam that
does pretty much any wireframe 3D modeling I could ever want, but it's
a bit slow for real animation... unless you have a quick 386 with fpu.
So, what i want to know is, where is a good place to start to learn those
integer math tricks MS et al use?  Also, if anybody is interested in
the pipeline, i can mail it to them - its kinda convoluted and there's no
documentation or comments (hey, i'm sorry - what do i look like; a CS major?)
but if you're willing to sit down and untangle it, it might be useful.

Two "front ends" are available - one is an interactive line-driven renderer
which will also read in data (got lots of sample stuff for it); cli.c
the other is a little animation front end that bounces and rotates red/blue
3d stuff on screen; danime.c

again, docs are sparse, so use at your own risk!
The syntax for the cli is pretty much what James Blinn wrote about in 
some random Computer Graphics treatises.. i have photocopies of those
lying around somewhere.

If you want to see 3D display math in all its most gruesome generality,
find

	Puk, Richard F., "General Clipping on an Oblique Viewing Frustrum",
	SIGGRAPH '77 Proceedings, Computer Graphics Volume 11, Number 2,
	Summer 1977, pages 229 - 235.

I implemented this into firmware in a graphics display workstation for
an employer in 1981, along with the general 4x4 homogeneous
transformation code ably covered in, e.g., the recently referenced Foley
& van Dam 2nd Edition.

The published math, I remember, had one rather obvious bug when
converted to software; it assumes infinite precision arithmetic, and
stops a loop based on equality between two real values computed from
different inputs. This is nonsense with limited precision arithmetic,
and I stopped the same loop with an ugly but fast set of flags to assure
I only clipped a line once at each clipping plane.

There have been several quite good responses to the original posted
request for help, but I feel that a couple of things haven't been
emphasized enough, so let me restate one point, and add a bit of
information of my own from my experience doing the above coding.

1) The complaint was that the rotations seemed absolute to the screen,
rather than relative to the object. That's correct; the homogeneous
rotation transform rotates about _the origin of the coordinate system_,
not about your modeled object's "design "axes. As posted, you need
logically to a) move the object to be centered with _its_ "design
origin" at the coordinate systems' origin, b) do the desired rotation,
and c) move the object's design origin back to its previous location in
the scene. I said logically, because it is normally _much_ faster to
take the three 4x4 matrices needed to accomplish these three operations,
multiply them together as several posters have mentioned, and use the
single product matrix to multiply times each point in the object's point
list to do the transformation "all at once".

2) Another possible source of "this doesn't look right" when doing a
screen rotation is to neglect the screen pixel shapes, or "aspect
ratio"; if the pixels are 4/3rds as tall as they are wide, an object
when rotated will appear to change shape with various orientations if
the drawing code treats the pixels as grid coordinates on a grid equal
in x and y dimensions.

3) Doing the "move, rotate, move back" transformations of 1) repeatedly
and storing only the new coordinates will eventually, if you are doing
real time rotation or at least lots of rotations of the same object,
"destroy" the object by the effects of accumulated round off errors
moving the points with respect to one another.  You want instead to keep
an original copy of the object description, and accumulate the rotations
about each "object design" axis, scaling along each "object design" axis,
and translation along each scene coordinate axis, and use these to build
the transformation matrices fresh before each use.  This way small errors
in the accumulated values may still occur, but the created transformation
matrix will transform the original data without inappropriate moves of
the object's points with respect to one another.

4) The _easy_ way to do smooth rotations through a series of positions
is to create transformation matrix for the original and final position,
do a linear interpolation between individual matrix elements for each
rotation step to be displayed, and use the interpolated matrix to do the
intermediate transformation. Do _not_ take the delta matrix for one
frame and repeatedly apply it; the same accumulated roundoff will get
you.  When using this technique, do a maximum rotation in one set of
interpolations of 90 degrees about any axis; this assures that you don't
accidently rotate the object backwards to your intended direction.

I really don't know if the interpolation is mathematically sound, but it
looks right, which is what counted for me. I suspect, since a sine curve
is being interpolated by a straight line, that the rotation speed is not
really constant, but the eye doesn't pick up on this kind of a problem,
and the start and end positions are correct. The less the maximum
rotation you allow for endpoint matrices between which you interpolate,
the better the straight line interpolates the sine curve, of course, and
the less the problem would show, but the extra math can hurt.

Of course, if you're doing sines and cosines by table lookup, either
interpolating or doing each frame's transformation matrix separately
works out about the same.

Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>

In article <1991Apr8.181450.15309@cs.cornell.edu>, ressler@CS.Cornell.EDU (Gene Ressler) writes:
> In article <41021@cup.portal.com> Bobster@cup.portal.com (Robert Jules Shaughnessy) writes:
> >
> >     I also have had this problem. I think you should fallow what is said
ect...
> >yyou view an object more clearly as you pass through them.
> 
> To beat a dead horse ;-), what is really wanted (at least in concept) is to
> _clip_ to the perspective view volume in _3D_, then draw.  (There is
> no `behind the observer' for orthogonal projections.) This volume is the
> (infinite) double pyramid formed by projecting lines through
> the observer point to the corners of the viewport (think `screen').
 ect...
> Check out the 3D version of the Liang Barsky clipping algorithm.
> It nicely truncates 3d lines to just the viewport lobe
> of the pyramid.  Hence when you fly through objects, they
> 
> Happy landings, Gene

   Another way to do it is to transform the perspective (ie pyramid) into 
a parallel orthogonal canonical space.. clipping is extremely easy then.  Check
in Foley "Computer Graphics: Principles and Practice"  chapters 5 and 6.  Every
thing you always wanted to know about 3D projections onto a 2D view-reference-
plane.

 ****************************************************************************
 *  \   |   /         "A 40 kW Full-Spec EMR in every satellite             *
 *    \ | /            by the year 1995!"                                   *
 *   ---*-----------------------------==============>>>>>>>>>>>>|||||||||   *
 *    / | \            Michael Hartley         (Yes, I did melt that)       *
 *  /   |   \          Purdue University                                    *
 *   hartley@maxwell.physics.purdue.edu       hartlemp@mentor.cc.purdue.edu *
 *   hartley@bard7.cs.purdue.edu              me@my.self.and.I              *
 ****************************************************************************