3D and Dreamatron VR Imaging Maths

These are generally useful for several 3D display technologies.
Check for errors before using.

ZYX to bytenumber address:
In the case of a volumetric display it is mathematically efficient to
have a voxelspace with dimensions that are powers of 2, and therefore
arithmetic processing is not needed in many cases. In the case of a
voxelspace of 16x16x16+, each coordinate is hexadecimal digit from
0 to F, therefore, a near central point would be addressed as 987,
representing X=7,Y=8,Z=9. I do not expect any 3D displays
to have discrete dimensions greater than 65536 cubed, and a central voxel
would be addressed as 800080008000 in this case. 8000 is an unsigned
origin that is simple to work with in a computationally efficient 3D environment.
These bytenumbers address memory in the display buffer directly in bitmap
format. A holodeck room of such quality to have a discrete dimension of
65536 (2^16) may have one or more buffers of 256 terabytes of RAM!
(If it was truly holographic, this could be reduced to 2 gigabytes or less
per wall, but for practical experimental purposes, none of these displays
will need to exceed megabytes in order of magnitude of storage.
A solution to the problem of very high resolution voxelspaces is that
they will very likely be sparse matrixes (contain mostly zero)
and compression will happen naturally if coordinates are stored in order
with inactive (zero) voxels not being stored.
A "megapixel" is a reasonable quality expectation in today's technology.)

Rotation:
To cgi a rotating object, it is converted to polar coordinates,
the angular coordinate is incremented, and it is converted back
to ZYX. The initial conversion need be done only once. This
works easily along any of the 3 axis because one of the coordinates
of each voxel remains unchanged in the conversion.
Conversion to polar coordinates involves computing the distance of
each voxel from the axis of rotation (R), and computing the original angle
of rotation relative to one of the other axis (T).
R=square root of(X^2+Y^2):T=arctangent(Y/X)
This assumes rotation at origin, so the offset must be removed.
Also attention to the signs of X and Y is necessary to correct T
when it exceeds a half-rotation.
[1]Converting voxel back to ZYX (assuming rotation on the Z axis at origin) is:
X=R*COS(T):Y=R*SIN(T)
The display devices do not do this math at all, it is only necessary to
create cgi objects which are then fed to the display device, or an independent
"rotate" control module added to the device will do this.

Plotting a voxel at ZYX:
For volumetric projection, the color of the voxel is stored in the
memory address numbered ZZYYXX. Assuming 256 cubed to
be a reasonable voxelspace for projection,
030201 would be the address of voxel X=1 Y=2 Z=3.
In this example, the numbers are hexadecimal AND decimal.
Polar Coordinates to ZYX:
See note [1] under Rotation
Vector Graphics to Voxels (draw a line):
All integer math. The longest dimension of the line is
counted (such as from X1 to X2). Using a shorter dimension
could cause dotted lines or divisions by zero. The other
dimensions are calculated by the equal proportion of the
distance between points in between over the total distance:
For all points from X1 to X2 when X is the longest dimension of the line,
Y=Y1+(Y2-Y1)x(X-X1)/(X2-X1)
Z=Z1+(Z2-Z1)x(X-X1)/(X2-X1)
Draw a solid sphere:
Offset from origin is removed, then:
if square root of (X^2+Y^2+Z^2)<radius then set voxel.
All points within radius of origin and axis may be tested.
Draw a hollow sphere:
Draw a rectangle or window frame:
Lines: X1Y1Z1-X2Y2Z1-X2Y2Z2-X1Y1Z2-X1Y1Z1;
"1" coordinates are upper "left" corner , and
"2" coordinates are height and width added to "1" coordinates.
Detect being inside a window or icon (gui):
If X is greater than WindowX and Less than WindowX+WindowWidth
then X is inside of the window if this is also true for Y and Z.
Draw a filled rectangle:
For All Z from Z1 to Z2:
Lines X1Y1ZZ-X2Y2ZZ
Draw a filled trapezium/trapezoid/polygon:
Not worked out but based on "multiple instances of vectorgraphic lines"
Fill an arbitrary shape (large shapes cause stack overflows)
Put all adjacent empty voxels on the stack. Fill the addressed pixel.
Pop a voxel off the stack if the stack is not empty, otherwise stop.
This must be improved by cleanup and checking the stack for redundancy
and recently filled voxels. Leaky shapes are a serious problem.
Texture map a quadrangle:
similar to filling quadrangles but also using additional vectorgraphic line
proportion calculations to copy texture map pixels to their corresponding
place on the shape.
Parallax info:
(Eyes are 5 to 7 cm apart, but it may be necessary to assume more)
Fonts:
Bitmaps only, of 256 character alphabets in sequence, handdrawn.
Raytracing and Raycasting:
We never used these techniques.
Drawing a circle in a plane using sine and cosine:
t=Within range of 0 to 2pi, incremented by units of 2/rpi:
x=rcos(t):y=rsin(t) assuming circle is in plane of Z at origin
Drawing (a circle, etc.) in a sloped plane
This problem appears to me to involve the vectorgraphic line functions.
Drawing a circle in a plane using square root:
r^2=x^2+y^2 assuming circle is in plane of Z at origin
and all variables must range from -r to r,
and for practical purposes, 1/8 of the circle must be calculated and
then replicated 8 times using 8 variations of:
y=sqr((R^2)-(X^2)):x=-sqr((R^2)-(X^2)), etc.
Drawing a disk using square root:
For all X and Y, if sqr((X^2)+(Y^2))<r then set voxel x,y assuming at origin in plane Z
Integer Square Root (used to avoid sine and cosine):
Simple! The highest number of odd numbers that add together
to be less than or equal to a number is it's integer square root:
1+3+5+7+9=25; there are 5 odd numbers in it.
Sine Cosine Arctangent cheating
in some previous applications excellent results were achieved
by dividing a quadrant or circle into 256 "degrees" and calculating
the most useful integers from trigonometric functions and putting them
in a lookup table. Like(?)
Degrees256sin(X)=int(128+127*sin(x*pi/128))
Relationship between Left and Right eyes and an object:
As an object moves toward you it moves right in the left eye's view
and left in the right eye's view.
Apparent size of an object, changing with distance:
as with Parallax, I think that this should be adjustable.
Plotting a ZYX voxel on a holographic panel:
See "HAND DRAWN HOLOGRAMS"
Playing sounds:
Selected audio signal type is pulse width modulation.
Compressing sounds:
googolodeon (linear shift register) code.
Fast Fourier Transforms:
The most complex math to be occasionally used,
for coding certain objects and people.


Sensor Decoding:
Currently primitive and weird, involving sonar, infrared, radio,
"light pen" type interface, "polar local positioning system", and
other experimental methods. "People images" present a unique
problem currently considered solvable by sonography and
texturemapping... a "people generating module" currently
seems necessary because of the yet unminimalized complexity.

As mentioned elsewhere, the 3D displays themselves
do not use very much of this math, but the cgi's are
generated this way externally. Currently none of our
3D displays use any noninteger functions internally.

3D projectors do not need to calculate perspective at all,
but 3D goggles do.

Buckminster Fuller created a mapping format based on
triangles and the icosahedron which is more natural than
ZYX but I have not worked out translations or coordinate
systems for it. I did once dream asleep of creating a VR
system based on icosahedrally mapped worlds. All I can
say is that they can be rearranged into a rectangular map,
and each triangle may inherently point north or south. It
is at this point more obvious to me to map worlds as cubes,
but my intuition says that Fuller's "alien technology"
based on triangles is superior.

go to Build a Holodeck, page 1