3D Animation Workshop: Lesson 78: Web 3D Gaming | 2
  |
Lesson 78 - Web 3D Gaming - Part 3
The simulation step requires some constraints, however. The arm must not rotate past its maximum windup angle, regardless of how long the mouse is pressed. More interestingly, the position and velocity of the plunger is constrained by the floor and walls. For example, if the simulated trajectory would place the plunger beyond the back wall in the current frame, the plunger's position must be constrained not to pass that barrier. Also, the velocity of the plunger must be reversed in direction and reduced in speed. This produces the rebound and the dampening effect of the impact. Especially clever coding is provided to rotate the plunger to be at rest horizontally after it hits the floor, losing speed with each successive frame.
The performSimulation() function computes all of the current information about the physical state of the throwing arm and the plunger and stores it in appropriate variables in memory. However, we still need to use these values to translate and rotate the 3D models in the scene. This is accomplished in the next few functions in the updateGame() function. First, the rotation of the throwing arm is set using the setThrowingArmRotation() function. This is simple because the only thing changing is a single angle. The next step is to animate the character's non-throwing arm using the function called animateFollowerArm(). The follower arm has a range of rotation, and is rotated through a fraction of this range, depending on how much of the throwing arm's range was used. To test this, pull the throwing arm back all the way and watch the follower arm rotate up to its extreme. After releasing the throwing arm, the follower arm rotates back and forth over less and less of its range, just as the throwing arm's rotations slow down and settle into the default angle. Try throwing using only a small portion of the throwing arm rotation, and watch the follower arm rotate accordingly.
At this point, the rotations of the two arms are set for the current frame. Now it's time to place the plunger correctly in the scene. This requires a decision based on the current throwing state. If the state is not yet AIRBORN, the plunger should be aligned to a nonrendering object placed at the end of the character's throwing arm. In this case, the function makePlungerHeldByWarhol() is called. This not only places the plunger properly in the character's hand, but also determines the current positional and rotational velocity of the plunger. The plunger's physical state is changing as it moves with the accelerating arm, and the program has to keep track of these changes because they will determine the trajectory of plunger when it is released.
If the Plunger is AIRBORN, the makePlungerFollowTrajectory() function is called. This does nothing more that plug the positional and rotational values produced by the simulation into the object in the scene.
The next step in the big picture is to determine if this is the right time to switch from the THROWING state to the AIRBORN state. The program tests whether enough time has passed since the mouse button was released, and if so, calls the releasePlunger() function which changes the throwing state. The effect of this change will be felt in the next render cycle.
The final portion of the updateGame() function is to determine whether the player has won. The didPlungerHitTarget() function is called, which compares the current position of the plunger in the scene with the current position of the center of the target. If they are close enough, the result is considered a hit, and a sequence of events occurs. The plunger is not permitted to pass through the target and is made to rebound by reversing its positional and angular velocity. If the target wasn't moving before, it is made to start moving. The startDunk() function is called, which changes the dunking state to "true." This, in turn, causes the animateDunk() function to be called. This final function, steps through a keyframed animation of the dunking girl that was created in 3D Studio MAX.
The scene and all of its geometry were create in 3D Studio MAX and exported in VRML format for use with Shout3D. The sequence of events in the dunking action were keyframe animated in MAX. Most of the other animated elements in the game are created by the programming code.
Most 3D artists and animators have little or no programming background, and very few programmers have artistic skills with today's standard 3D modeling and animation packages. Yet the success of 3D on the Web will depend on people who develop overlapping skills in both 3D arts and programming. Shout 3D is a fabulous invitation to people on both sides of the fence to reach across and develop the total skills package necessary to exploit the enormous opportunities now emerging in interactive Web 3D.
| To Return to Parts 1 and 2, Use Arrow Buttons |
|
Created: Oct. 26, 1999
Revised: Oct. 26, 1999
URL: https://webreference.com/3d/lesson78/part3.html
Find a programming school near you