Editing and The Basics of Animation


In this tute we'll animate three copies of the same mesh in the scene we've already created, and prepare it for the next tutorial, Input. It's going to involve closely following instructions, to get it right. Afterwards you'll save a reference file for study later. Animation in Nebula is easy, as long as you pay attention to the necessary details.

First of all we're going to be needing some new data, so download the following file into your
nebula/data directory:

room.n3d

Now for some editing. Windows users are advised to use a programming safe text editor. Jedit is an excellent free (Java Based) cross-platform programmer's editor with many features. Here's a screenshot.

Notepad is quite useless for what we are going to do, and will only break the *.tcl file. Linux users are advised to use Vim, Jedit or Emacs.

Here is a diagram of the scenegraph we have currently. The data nodes we created are in red. The nodes that provide light (from the source data/lights.tcl command) are in yellow.

Have a look at it to get a sense of the scenegraph's shape before reading on.

Editing:


In your text editor open up myscene.n and save it as another file, eg myscene2.n.

In this file we want to create three other n3dnodes as you see in the diagram above.

To do this, just copy everything you have in myscene.n and paste it three more times making sure that you paste after the last line, sel .. each time you paste.

The last sel command takes the interpreter back up to /usr/scene, which is from where all the scene data must be accessed at runtime.

Once you have done this, change the name of two of the new n3dnodes to disc2 and disc3, and the sel target name afterwards: eg

new n3dnode disc2
sel disc2

Then, change the name of the third node you created to room and change the mesh file name in the nmeshnode to room.n3d

Save the file.

If you were to launch startup.tcl now, and source this file into /usr/scene you would have three identical copies of the disc.n3d mesh laid one over the other. This we don't want, so we're going to reposition them using a command at the node level. Run the startup.tcl as you did in the prior tutorial and source the new scene file into /usr/scene.

Run dir and have a look at the contents of that node. You should now see four n3dnodes present at that level.

sel into disc2 and run the command:


gett


You should get the output 0.0 0.0 0.0

gett means “get the x,y,z position of this node.”

Now we'll reposition that node along the z axis a few units with:


txyz 0 0 1.5


Now sel into disc3 and move that node the same number of units in the opposite direction. When satisfied, sel up the /usr/scene and .saveas myscene3. By the end of it you should have something looking like this:





Animation


The nipol is the most basic animation class, but its structure is used in many other classes of nodes, like shader animations, mesh animations, and particle systems. Once we have a nipol in place we can control it's behaviour with an input device, as you'll see later. nipols always reside in the top level of the n3dnode you want to control.

sel into /usr/scene/disc1 and do the following:


new nipol anim1
sel anim1
beginkeys 2 1
connect rz
addkey1f 0 0
addkey1f 3 360
endkeys


You'll notice that the one of the discs is now rotating around the z axis a full 360 degrees every 3 seconds.

All nebula animations work to a familiar format of 'keyframes'. Keyframes have depth, time and a value.
The beginkeys argument defines the depth and number of keyframes.

beginkeys 2 1 gives us 2 keyframes with a depth of 1 value (and time). In our nipol we set the anim to rotate the node around the z axis with connect rz.

The structure of the nipol we created can be explained like this:

beginkeys <number of keys> <depth>
connect <type> <axis>
addkey1f <start time> <start value> (time and start value must each be 0 in the first key!)
addkey1f <target time> <target value>
endkeys (closes the keyframe sequence – not entirely necessary)

An example of a rotation animation with an uneven cycle could look like this:

new nipol anim1
sel anim1
beginkeys 4 1
connect rz
addkey1f 0 0
addkey1f 3.0 100
addkey1f 5.0 150
addkey1f 7.0 270
addkey1f 7.5 360
endkeys
sel ..


Keys can be of various depths, but keys of depths greater than one must affect a property that has as many values. For instance if we wanted to rotate the node evenly around several axes simultaneously we would have to:


new nipol anim1
sel anim1
beginkeys 2 3
connect rxyz
addkey3f 0 0 0 0
addkey3f 3 360 360 360
endkeys
sel ..


Other examples of properties that can be controlled by a nipol are:

sxyz (scale)
txyz
(position)

Of course the properties can be using to manipulate textures, the camera position and light values etc.

To close this stage of the tutes, look over the examples in data/tekdemos, particularly at staticmeshemitter.tcl, lightanim.tcl and meshanim.tcl. Try to get a sense of how the same structure you've just used in your nipols is used in these examples. The do the exercise below.

Excercise:


Here is a blob to play around with. Use sxyz, rxyz, txyz as much as possible to make it wriggle around in a highly uneven fashion.


NOTES:

From the Nebula Console the command getclass will show you the type of node you are working in.

Even though you see a '.' in front of many of the set value arguments in the script, it is not necessary.

Keys can be reset with the beginkeys argument and keys themselves can be set with a new value: using setkey1f (for example).

You can put several nipols into the same n3dnode as long as they have different names, eg anim1, anim2, anim3

You can concatenate paths and commands instead of setting commands inside the node itself. For instance:

/observer.setgrid false would turn the grid off.

The script documentation can be found here. It is also on your system if you compiled the documentation.

Appropriate indentation for the nipol examples may not be seen in your choice of browser. Follow the standard indentation practices in the scripts for the sake of readability.


Back to Part 2: Scripting and the Scenegraph Go on to Part 4: Input