3D Camera Movement

Ctrl-dragging upper-left to lower-right gives that "depth compression" effect used occasionally in cinema (Jaws, LOTR Fellowship, etc).

Moving the Camera
The camera orientation is specified by a transform. The renderer gets the camera transform from the 3Dnode that its "camNode" property points to.

This 3Dnode may or may not be part of the 3D world hierarchy. If it is, the camera transform will be affected by movement in the 3D world. If it isn't, it moves independent of the 3D world.

In this demo the camera is not part of the 3D world tree, but it does have a few ancestor nodes used for arcing the camera.

Rendering from the Camera's Point of View
In order to use the perspective equation the 3D world is transformed in rendering so that the camera sits at the origin looking up the z axis:

The key to finding the right transform to use is that when it is multiplied by the camera transform it gives the identity transform (which positions the camera at the origin looking up the z axis).

Since multiplying a transform by its inverse gives the identity transform, the right transform to use is the inverse of the camera transform.

In this demo the 3D world is transformed in this way by passing the inverse of the camera's transform as the initial parent world transform:

So the camera adjustment is applied once at the start instead of calculating world transforms for each object then applying the camera.

Field of View
The "field of view" is related to the distance from the focal point to the projection plane:

In this demo the view height is the height of the stage. For Shockwave 3D the view height is the height of the sw3D sprite.

As the focal point gets closer to the projection plane, the field of view increases and more of the 3D world is seen through the projection plane, giving a wide-angle lens effect. When the focal point is further away the field of view is narrow which gives a telephoto lens effect.

Orthographic View
In orthographic view the projections from the 3D scene are orthogonal to the projection plane rather than converging on a focal point:

The word "orthogonal" means perpendicular in n dimensions, hence the name. In orthographic view the 2D mapping comes straight from the x and y coordinates of the 3D model. Just remove the perspective equation from the algorithm, or set persp equal to 1.

If you remove perspective to get an orthographic view you'll see that back-face culling causes some of the faces to disappear that should be visible, because it is programmed for the view from the focal point. How would you correct this for orthographic view? A hint: vCent is the vector from the focal point (at the origin) to the center of the face. Find a different vector to use when calculating dotCam.

Cube Bounce
The programming of the cube bounce is specialized for this demo so it's much simpler than a generalized version. Here is a brief description of what is going on in the code.

The model behind it is eight masses, one for each cube resource vertex, connected by springs (physics model). An independent model rate is used since the springs are very stiff. The vertices that exert spring force on verts[i] are stored in spgVerts[i][], with initial (resting) spring lengths stored in
spgLength[i][].

Each model frame the forces acting on each vertex combine to give total force on the vertex. The force spgVerts[i][j] exerts on verts[i] is given by a vector found like this:

The force vector is found as a percentage of the original spring length and scaled according to the stiffness setting.

When a vertex moves out of bounds, it is repositioned at the boundary edge. This compresses the springs it is "attached" to which exerts force on other vertices and causes the cube to bounce and spin.

The cube bounce algorithm can be made more efficient by only calculating the force between each pair of vertices once, rather than twice. The forces between the vertices in each pair are opposites, so if vecF is the force on one then -vecF is the force on the other.