Thanks Leo for pointing out this discussion in amiga/comp-amiga.

I did not have direct access to this discussion and didn't know it

even existed.

First, I'd like to mention that Haitex will be releasing 3-D

glasses for the Amiga within about a month. I like our glasses

better than the Sega glasses because they have bigger lenses, and the

lenses are on a visor rather than "glasses" (kinda like a welding visor)

which is more comfortable, especially if you already wear glasses.

This is one of the things I've been working on for the past few months.

The following is a letter I sent to the makers of a ray trace progam

which will directly support the glasses. I hope this helps those of

you working on 3-D projects.

Note for Leo: This entire methodology was developed by looking at

the point of a pencil held between myself and a window, and looking at

a branch outside the window. This methodology is totally intuitive, and

avoids the need to perform any rotions to acheive the parallax effect.

Furthermore, I have been able to bring object a significant distance

out of the screen with no terrible ugliness. I'd like to talk to you

about all this in more detail so why don't you send me your ph# or

call me [(619) 421-5602] and I'll call you right back so I pay for the

call.

FROM: Wade W. Bickel, Haitex Resources. DATE: 12-10-88

TO: XXXXXXXXXXXXXXXXXXXXXXXXXXXXX

SUBJECT: Parallax Rendering Algebra.

In this letter I will try to go through the mathematics involved in

creating a parallax stereo pair. I am not a mathematician so please

excuse me if my teminology is non standard.

For computational simplicity I perform the following rather convoluted

system for generating a stereo display. The idea is that there is

an imaginary 3-D grid which cannot be re-positioned, and points to

be translated onto a region (which represents the screen), both of

which can be freely re-positioned. If you picture the display as

a window we are electing to move the viewer's head, the window, and

the objects outside that window, rather than re-align the axes.

The logic can be decomposed into a system of moving axes if you wish,

but this system eliminates the need to compute the length of some

projections using the distance formulae and therefore is the one that

I utilize.

1) Points to be translated are represented in cartisian

(x-y-z) coordinates.

2) The viewpoint is assumed to be centered at the origin

and facing in the direction of positive z. To visualize

this, you the viewer, are at the origin, the direction

you're facing is positive z, and negative values of x lie

to your left.

3) A plane lies perpendicular to the z-axis (ie: parallel

to the x-y plane) at some distance in the positive z

direction. Within this plane is a rectangular region, not

quite centered about the z-axis, and aligned with the x and

y axes, which represents the screen. For our purposes we

will call this region either the "left-screen" or the

"right-screen", or just "screen" for the general case.

The screen is offset with respect to x depending on which

view (left or right) is being rendered. For the left eye

the screen is offset to the right. Thus if one were to

display the point [0,0,zP] (ie: where the z-axis intersects

the region) for the left-screen the point would appear to

the left of the center of the actual display bitmap. For

the right eye the region is offset to the left. These

offset's will be refered to as the "lefteye-offset" and

"righteye-offset" and are calculated to be one half the

distance between the viewer's eyes, in whatever units of

measure have meaning to the programmer/user.

4) Points to be translated are assumed to have a positive

z coordinate; in other words, you should clip with respect

to z before trying to translate a point. Clipping with

respect to x-y should probably be done after translation.

When translating a point for the left eye, that point

should be shifted right by twice the amount the screen

region was shifted to the right (ie: the total distance

between the eyes). Lets call this the "EyeSpacing". The

net effect of the shift of the screen and the point is

to properly create a perspective.

Given these conditions and relationships, to translate a point onto

the screen the following algebra is used:

The point to be translated (always positive z) and the view point

(always [0,0,0]) define a line. These two points also form a right

triangle, call it triangle "A", with the z-axis. The line also

passes through the plane in which the screen (as previously defined)

lies, and this intersection is the one we wish to find. Note that a

triangle is formed between this unknown point, the viewpoint, and

the z-axis, call it triangle "B".

Triangle A and B are similar right triangles. Since we know

the z components of both triangles, and everything about triangle

A, we can calculate the disired intersection as follows:

let

VP = the viewpoint, [0,0,0];

P = the point to be translated (+z);

S = the plane on which the screen lies (perp. to z);

Q = point on the line defined by VP and P, and on

plane S.

the following relationships are true

Qx/Qz = Px/Pz; --> Qx = (Px * Qz)/Pz;

Qy/Qz = Py/Pz; --> Qy = (Py * Qz)/Pz;

(note avoidance of distance fomulae

calculations because VP = [0,0,0])

Where Qx and Qy are the respective X and Y coordinates to

possibly be displayed. This two-d-point should be checked to

see if it is within the "screen" (as previously described) and

if so it should be displayed.

Implementation of this is not nearly as difficult as all this

implies. Simply do the following.

1) for each view add or subract the constant

"EyeSpacing" to the x-component of points

to be translated. Hopefully this can be done

at a very low level of the point's position

calculation. (Add for left eye view, subtract

for right eye view).

2) translate the point as described earlier. Qx and

Qy represent the actual translation to the

plane on which the screen lies. At this point

determine if this point lies in the appropriate

"screen". [Remember that the screen is a region

which is shifted left or right by half the

EyeSpacing (or: left/right-offset)]. If so then

the point should be rendered.

3) When rendering the points must be recentered to

account for the fact that [0,0] on the display

is the upper left corner, and we want it to

be the psuedo screen center. At this point,

adjust the x compensation by one half the

EyeSpaceing. (move the center left for the

left eye, right for the right eye). This should

be an integer operation.

Implementation of this is not nearly as difficult as all this

implies. Simply do the following.

I hope I've not gotten anything backwards. Sorry I've made it

seem overly complicated, but I tend to think of this in pictures,

not language.

--------------------------------------------------------

Now on to my question: Is it not worthwhile to think of objects

in polar coordinates? It seems to me than much of the math

required to do the real-time calculations necessary to provide

rotation of both the objects and the viewpoint(s) would be

allieviated by defining object this way as opposed to cartesian

coordinates. I am about to give up on this approach due to some

flaw in my calculations, which took me about a week to work out,

and translations in cartesian coords are well documented. Seems

a shame though as it should reduce the needed calculations to less

than half.

If anyone would care to discuss the topic I might give it one

more shot. Should I post here or keep this E-mail?

All (civil) comments are welcome.

Thanks,

Wade W. Bickel

Haitex Resources.

PS: In order to get to this news-group I have to utilize the

Unix side of the local node. Not knowing my way around in

here yet, would someone please mail me the Stereo-vision

topics found here for a while (and perhaps post letters for

me as well, which I would send via mail)?

PPS: Sandra (?? I think that was the name of the original poster),

If you'd like I could mail you some Modula-2 examples to perform

the translations. Of course, if you want controlled rotation,

that's what I'm working on now so you'd have to wait.