在这个教程中作者制作了一个交互手机的DEMO。主要介绍了shockwave3D的基础交互的实现。本教程制作步骤：了解交互物体，项目概览，目标功能，开始制作，创建组,重设场景，按钮设置，按钮功能设置，电源按钮功能设置，总结。

Interactive Objects

The ability to present a view object from an infinite number of angles is one of the best things about realtime 3D - everything looks better from six degrees of freedom!  Add to this, the ability to alter the 3D object being viewed in response to user interaction and you’ve got some serious Wow!-factor on your hands.  Practically anything from product demos to educational software stand to benefit from this sort of interactive 3D treatment.  The best part is, it’s not really all that hard to get started doing it in Shockwave3D (SW3D).

Project Overview

We’ll be creating the functional shell of an interactive 3D product demo.  But, in a larger sense, the techniques that we’ll be covering are fundamental in creating any project with interactive objects that need to be manipulated in first-person, either as a group or as separate “sub-objects”.  To that end, we’ll cover several key concepts, including grouping strategies, picking, gesturing and interactive property manipulation, all through practical examples in SW3D. 

Please note that it is assumed that you are already familiar with the basics of using and programming SW3D.  Also, since this code in our finished example is somewhat lengthy, the approach in this article will be to accompany your own reading of the program code in each of several graduated revisions, rather than explain the code line-by-line.  Look to this text for explanation of the overall strategy and conceptual framework of the programming.

Functional Goals

In any interactive project, a good first step is to outline the functional goals that you need to accomplish.  We will outline those now.  First and foremost, the user should be able to grab and rotate the 3D phone by clicking on its body and then moving the mouse.  The user should also be able to “reset” the orientation of the phone by clicking a “reset” button – just in case they get disoriented while spinning it around.  And, several of the component parts of the phone should illicit their own functionality: (1) all buttons will press and unpress when clicked, (2) button presses should be accompanied by a sound, (3) pressing the power button should cause the phone’s antenna to extend and retract, and (4) pressing the A-B-C function buttons should change the display on the phone’s screen.

Getting Started

You will need to download the sample files for the project. Before beginning the exercise, examine and run finished.dir, a completed version of the exercise.

The final product demo exercise, brimming with interactive 3D.

To begin the exercise, load the step_01.dir file in Director.  This file is a Director movie consisting of template code for the exercise, including an imported 3D cast member. Using 3DPI, examine the 3D scene in our starter movie, paying particular attention to the naming conventions used for the various models that make up the mobile phone.  If you don’t already have the “3DPI” Xtra installed on your copy of Director, go to http://www.director-3dpi.com to get it before starting.  3DPI is truly the 3D property inspector that Macromedia forgot to include in Director 8.5, allowing you to literally look inside 3D cast members, manipulating their contents and properties visually and in realtime.

Looking inside the 3D world with the 3DPI Xtra.

The two-frame structure of the template movie is based on the need to ensure that the 3D cast member is fully initialized and ready, before executing any 3D Lingo.  Program flow will loop in the “init” frame until the 3D member is ready.  Once the 3D member is ready, a block of initialization code executes, and then the playback head advances to the “main” frame, where we loop for the remainder of the program.  This is a good, basic template for all SW3D projects.

We’ll build everything inside a basic, two-frame template movie.

Creating a Group

Load the file step_02.dir.

As you saw in 3DPI, our mobile phone model actually consists of some seventeen different models.  Our ultimate functional goals for this exercise will require that these seventeen model sometimes act independently (i.e. when individual buttons are pressed), and at other times as a whole (i.e. when the entire phone is rotated in space).  The former will be accommodated by the fact that each of the seventeen parts of the phone is indeed a separate model and the latter is accomplished by “grouping” all of the separate models together.  We do this in Lingo here, although you can do it in most modeling program as well.  Grouping allows us to create a new node in the 3D world that has no geometry of its own, but rather acts as a container for other geometry.  We have done this by adding a block of code to the enterFrame handler in the “Initialization” behavior which creates the group node “phone” and then adds all of the models, (i.e. the various phone parts) in the 3D world to it.  Grouping is a subtle but important aspect of interactive 3D.  By grouping all of the parts of the phone in this way, we now have two levels of control over them: we can manipulate them one at  a time, or as a group. 

Picking and Gesturing

Load the file step_03.dir.

Our first functional goal is to allow the user to click on, or “pick”, the body of the phone, and then rotate it on two axes by gesturing with their mouse.  This will allow the phone to be viewed from any perspective – a very useful thing in product demos.  This functionality rests in the “Tracker” behavior that we have now attached to the 3D world sprite instance in the “main” frame of the movie.  The structure of this behavior is fairly straightforward: the mouseDown and mouseUp handlers toggle the rotation functionality on and off and leave the actual processing of it to the exitFrame handler. 

Here’s how it all works.  Since the object should only rotate when it has been clicked on, the mouseDown handler initializes and initiates the rotating of the object.  It does this by using the modelUnderLoc function to determine if the user has just clicked on a model in the 3D world.  If the value returned by modelUnderLoc is void, there is no model under the cursor and our mouseDown processing is done.  If the modelUnderLoc value is not void, the user has picked a model in the scene.  When this happens, the flag variable pTracking is set to TRUE, toggling execution of the code in the exitFrame handler which transforms the entire “phone” group on two of its axes in response to the user’s mouse gestures, which are inherently on two axes.  Likewise, when the user releases the mouse, the mouseUp handler sets pTracking back to FALSE so that the code that transforms the “phone” group” cannot not execute. 

Notice that the behavior has been written so that the model picked and group gestured can be specified as properties.  This is to allow greater flexibility in formulating your user interactions.  For instance, while our interface utilizes a “first person” interaction wherein the user manipulates the phone itself to change its orientation, alternatively, the scene could feature geometry separate from the phone which serves as a navigation instrument, such as an sphere used as a virtual trackball.  This behavior could easily accommodate such configurations as well.

Resetting the Scene

Load the file step_04.dir.

Next, we add the “Reset” behavior to the reset button, which allows the user to return the phone to its initial orientation.  As you will recall, after creating the “phone” group in the “Initialization” behavior, we stored the group’s transform in the global variable gInitTransform.  Thus, here we need only set the group’s transform back to the value in gInitTransform to return all of the models that make up the phone back to their start position.  This kind of functionality is particularly important in interactive 3D.  Interacting with 3-dimensional content via 2-dimensional interface devices, such as the a computer screen and mouse, isn’t the most intuitive of tasks, and one that is still entirely new to many users.  The need to establish and allow easy access to reference points, such as the initial position of the phone in our demo, is crucial to minimizing their frustration as they become accustomed to this new kind of interaction.  Note that we have also provided a sound cue for the reset button in this behavior.

Pressing the Buttons

Load the file step_05.dir.

All of the remaining functionality that we will create in this exercise results from pressing buttons on the phone.  Since the power and function buttons are a little more involved, we’ll start by “wiring” the buttons that make up the keypad, which simply depress and make sound when clicked on.

In this latest revision of our program, we have added a new behavior, “Picker”, to the 3D world sprite instance in the “main” frame of the movie.  In this behavior, the mouseDown and mouseUp handlers translate any button model in the 3D world picked by the user on its Z-axis, and play a sound cue, thus creating the impression that the user is actually pressing the buttons.  The first few lines of code in the mouseDown handler should look somewhat familiar.  Just as in the “Tracking” behavior, we have used the modelUnderLoc function here to determine if the user has clicked on a model in the 3D world.  However, instead of using the mouseDown and mouseUp behaviors to toggle ongoing functionality (such as we did with the rotation of the phone via mouse gesturing in the Tracking behavior), here we simply translate the button picked in one direction on its Z-axis in the mouseDown handler and then back in the opposite direction in the mouseUp handler.  Note that the logic of this handler relies in part on the fact that all of the buttons in the phone have been strategically named with the string “button” to differentiate button clicks from clicks on other models.  Note also that the mouseUp handler is much leaner than in the “Tracking” behavior since it does not need to check for models picked or play any sounds.

The Function Buttons

Load the file step_06.dir.

Aside from acting like buttons, the three “function” buttons (those labeled “A”, “B”, and “C”) are to have the added functionality of making the phone’s screen change when pressed.  This could be used to simulate changing the phone’s mode of operation, say from calling mode to paging mode to phonebook book – you get the idea.  Since the screen is itself a separate model, complete with its own shader, this will be accomplished by changing the screen shader texture as each button is pressed.  The first step in making all of this happen is to create three custom textures from the bitmap cast members: “screen_a”, “screen_b” and “screen_c”, which is done with the first three lines of code added to the enterFrame handler in the “Initialization” behavior.  Once this is done, we then use one of the new textures to change the screen to its initial display state.  Run the movie to see the new screen displayed on the phone.  The advantage of using bitmap cast members for the screen textures is that they can be easily updated by importing new bitmaps.  In fact, feel free to substitute your own bitmaps for those supplied here.

The screen textures are derived conveniently from three bitmap cast members.

Load the file step_07.dir.

The next step in changing the screen when the function buttons are pressed requires enhancing the logic of the “Picker” behavior.  Specifically, the mouseDown handler now features a CASE statement block that differentiates between function buttons A, B, C, and the keypad buttons, executing a unique outcome for each.  In the case of the function buttons, this consists of switching the texture used by the screen model’s shader to the appropriate texture the function button picked and playing a function button sound.

The Power Button

Load the file final.dir.

The final step in our exercise is to make the phone’s antenna extend and retract in response to the power button being pressed.  Since we are adding yet another from of button functionality, this will require the addition of a yet another condition to the “Picker” behavior’s CASE block.  Now, when the model picked is named “button_on” (the power button), the CASE block executes a two-part IF-THEN-ELSE block which transforms the position of the antenna model, based on the value in the flag variable, pAntennaFlag.  As an added bit of realism, the power button’s own positional transformation is now handled by this same block of code, so that it will toggle up and down between keypresses, instead of with each keypress.  Note that the mouseUp handler had to be changed slightly to accommodate the fact that the power button’s transform is now being handled entirely within the mouseDown handler.

That’s it – we’re done!  The next step for you is to start flexing your programming muscles and use the foundational concepts covered here as a starting point for creating even richer and more complex interactions.  The techniques that we examined in this product demo exercise only hint at the power of interactive 3D to engage an audience with content that not only looks real, but that acts real as well.  Have fun!

源文件下载　

观看最后作品效果