# About StarScreen3D v1.0

StarScreen3D is a Java Applet 3D project where hundreds of 3D boxes bounce around inside of a larger 3D box. The camera flies through the space, and you can rotate the direction by dragging the mouse with either the left or right buttons.The program implements the following 3D rasterization techniques:

# Perspective Viewing Projection

Every object that is to be rendered in 3D will have a set of points associated with it. The boxes in StarScreen3D are stored as objects that each contain 6 square faces. The faces consist of 4 points in*(x, y, z)*global coordinates. The boxes are first sorted via Depth Sorting using the Painter's Algorithm. Once the boxes are sorted, each face of each box is tested in descending z-depth order via Back-face Culling to see whether or not the face should be rendered. If the face passes the test, then each

*(x, y, z)*point of that face is first translated into camera coordinates and then projected onto the camera's view screen. The camera is defined by an

*(x, y, z)*position,

*C*, with subscript

*G*to indicate the global coordinate system is used:

(1) |

A point in global coordinates is defined as:

(2) |

with subscript

*G*indicating the point is relative to the global coordinate system. In order to convert the point into the camera coordinate system, its origin reference must be translated to the camera and then projected onto the camera axes. Translation is accomplished by subtracting the camera position from the point, effectively making the camera the new origin for the point (this yields a vector from the camera to the point with subscript

*CT*indicating that the vector is relative to the camera via translation):

(3) |

The translated point can be written in matrix form:

(4) |

The rotation of the camera is defined by three unit vectors that are referenced to the camera as the origin. The z-component of the camera coordinate system points into the view screen, the x-component points to the right, and the y-component points downwards for convenience in projection to the view screen. They make up a local coordinate system

*Cam*that is relative to the camera translated coordinate system via a rotation:

(5) |

The unit vectors can also be written in matrix form:

(6) |

The projection of this point onto the camera axes is accomplished by multiplying matrix

*M*by the vector

_{cam}*P*, which is the same as dotting the point with each camera unit vector:

_{CT}(7) |

Now that the point has been converted into the camera coordinate system, a projection can be made onto the camera's view screen. The view screen is stored to be a distance

*V*in front of the focal point of the camera. If the point in camera coordinates is behind the physical size of the viewer, then the point is not within the Viewable camera space and should be handled accordingly. A point may be translated from camera coordinates to the view screen as follows:

_{Z}(8) |

The remaining set of points that make up the surface is translated in the same manner, and an orange covered polyline is then drawn on the screen with a blue outline around it to represent the surface.

# Depth Sorting using the Painter's Algorithm

In the rendering process, it is necessary to take into consideration the order in which the boxes are drawn. Notice how the boxes that are closer to the screen hide the boxes behind them. This is accomplished by calculating the z-depth (the distance from the viewer to the object) of each box and sorting them in descending order. This way, the boxes farthest from the screen can be drawn first and the boxes closest to the screen can be drawn last. A simple bubble-sort algorithm is used in StarScreen3D v1.0. Bubble-sort works well in situations where the list of items is nearly sorted. This is the case most of the time in this application because the change in position of each box from frame to frame is relatively slow. The bubble-sort algorithm is also very simple to code.# Back-face Culling

Notice how in the above screenshot only the surfaces of each box that face the screen are drawn. The surfaces on the back sides of the boxes relative to the screen are not drawn. This technique is called "Back-face Culling," and it requires storing the normal vectors for each surface. If the normal of a surface points away from the screen, i.e. if the dot product of the surface normal and the camera vector is greater than zero, then the surface is not drawn. The only time it is necessary to draw a surface is when it points towards the screen and when the projection of that surface lies on the screen. For mathematicians, if(9) |

where

*n*is the vector surface normal and

*c*is the camera unit vector in the z-direction (i.e. into the screen), then the surface faces the camera, and that surface will be drawn if its projection lies on the screen.

_{z}