|3D Camera MovementClick & drag to arc camera
Ctrl-click & vertical drag to dolly
Ctrl-click & horizontal drag to zoom (field-of-view) 3D Camera Movement – 1000×700 – source movieCtrl-dragging upper-left to lower-right gives that “depth compression” effect used occasionally in cinema (Jaws, LOTR Fellowship, etc).
Moving the Camera
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
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:
camInverse = camNode.getWorldTransform().inverse()
camInvRot = camInverse.duplicate()
camInvRot.position = vector()
rendLightVec = camInvRot * lightVec
stepFrame() handler of script “3Drender”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
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.
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.
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
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:
repeat with j = 1 to spgVerts[i].count
vecDiff = verts[i] – spgVerts[i][j]
pCompress = 1 – (vecDiff.length() / spgLength[i][j])
vecSpring = vecDiff.getNormalized() * pCompress * stiffness
vecTotSpring = vecTotSpring + vecSpring
Calculating total spring force on one vertex, modelFrame() method of script “cubeBounce”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.
- These are all petrol based RC cars
- Working with experts who understand real estate law