Scripted Animation/Automation in A:M

[Rodney]

Disclaimer: The title of this topic may change as the subject matter is refined.

 

This is a spin-off topic from Robert Holmen's 'It can't be done' topic.

 

The target appears to have moved a little but here's a beginning:

 

Paul Harris:

Something I've been batting around in the dusty corners of my brain:

 

Be able to apply a "script" that describes the actions of a character (enter stage left, walk quickly to point "A", turn towards camera, sneak to point "B", etc.

 

Sort of like instructing an actor on how, when, where to hit their mark.

[pixelplucker]

So a bunch of us have a little A D D.

[Rodney]

Let's break this one down before we move on.

 

 

Apply a "script" describing the (desired) actions of a character

 

Example script:

1. Enter stage left

2. Walk quickly to point "A"

3. Turn toward camera

4. Sneak to point "B"

5. Wait for next command

 

Desire: Via the application of a script, instruct an actor how, when and where to hit their mark.

[Rodney]

Within this generalized script a few things stand out as variables that will need to be defined:

 

Example script:

1. Enter stage left

This appears straightforward enough.

Assumption: The command "Enter" means to move within the renderable view of the camera.

Assumption: The stage is the scene in front of the camera which may or may not extend beyond the view of the camera.

Assumption: The direction "left" is to be from the view of the camera.

 

2. Walk quickly to point "A"

The command "Walk" is a general term which needs to be further defined. If not defined it will default to a preassigned sequence of walking.

The variable quickly is an attribute that must be user defined. If not defined it will default to a general fuzzy logic value of 66% or more on ease channel (as required).

The position of "Point A" must be defined by the user. If not defined the object or character is assumed to be at Point A.

 

3. Turn toward camera

The command "Turn" is assumed to mean rotate with no movement in lateral position, elevation or inclination. It requires an attribute to further specify direction. If not defined a default turn of 360 degrees will be initiated with the character returning to the original position.

The attribute "toward" specifies a target which must be user defined. If not defined a default target is supplied. Recommend default target be a immovable Null placed at or neat 0,0,0 axis directly in front of camera in center of viewable screen. In this way the object or character can return to original orientation and location based upon this (non rendering) object.

The camera is assumed to be in the scene but a check should be performed to ensure a camera exists. If no target (camera) exists the command is ignored.

Enhanced scripting could supply a means whereby objects not in view at the origin are ignored because they cannot be directly seen.

 

4. Sneak to point "B"

The command 'Sneak' is assumed to mean the Preston Blair sneak unless otherwise specified.

The command "to" implies a relationship with another object or character.

"Point B" is assumed to be a position other than that of the origin (default Point A). If not defined a default may be supplied (example: Nearest object to origin)

 

5. Wait for next command

It is assumed that any object or character is always waiting to execute the next command.

[Rodney]

Attached is a rendering of a sequence created without changing anything in the animation*.

All movement was created by dragging and dropping commands onto the character on various frames of the Timeline.

All script commands where dragged from the Library window into the Choreography.

 

*Minor adjustment to action lengths, repetitions was performed (example: A gap between Moving Forward and Turning Right was created by moving the Turn Right Action slightly to the right in the timeline. This allowed A:M to blend the two actions rather than create an abrupt turn. Repetition of the walk cycle was increased from the default setting to meet the general requirement of 'quickly' walking.

 

Icon's were created for Turn Right, Turn Left (not used) and other movement for easier identification in the script library.

These apparently were not saved because they are no longer in the script library.

Other script elements such as "Dim Light" were tested and worked but not used in this example.

EnterStageLeftMoveForwardTurnToRightTipToeForward.mov

[robcat2075]

Go for it! Eager to see what you come up with.

[Rodney]

Go for it! Eager to see what you come up with.

 

Me too!

 

Here's a view of the script elements used to drive the previous animation.

They were each dragged and dropped into A:M while scrolling through the Timeline.

 

Note: Cheezy arrows were also created in A:M.

In hindsight I should have used the Font Wiz!

[Rodney]

Here's an example script that can be easily interpreted/automated through A:M's Dopesheet:

(Scroll down via mouse or scroll bar on the right of post to see remainder of the script)

 

[script]

 

Name=Dope Sheet Test 1

 

Name=1 Jump

StartFrame=1

EndFrame=16

HasTranslated=FALSE

ChorStartFrame=1

ChorFrames=16

 

Name=2 TurnToRight

StartFrame=15

EndFrame=1:26.14

ChorStartFrame=15

ChorFrames=1:26

 

Name=3 TipToe

StartFrame=1

EndFrame=2

ChorStartFrame=1

ChorFrames=2

 

[/script]

 

 

P.S. Is it not fitting that my signature has the following line in it at this exact moment:

"But what I was seeing at PIXAR was that there was no script. It was like an improv show with cartoons. " Matthew Luhn (Story Artist)

[Rodney]

I ran into an interesting problem when scripting Cameras and Lights.

 

In my current approach, I don't see any direct way to script Cameras and Lights because they are not exposed in the same way that Models, Actions, Materials and such are inside A:M (I'll have to investigate this because I'm sure to learn something!)

 

The solution is rather simple (and provides solutions to many other things unrelated to scripting): Create a Model that contains Camera(s) and/or Light(s).

(Newbie Tip: Camera's and Lights in a Model are treated as Bones, so after creating them go into Bones mode to modify their position or alternatively adjust those settings in the Project Workspace manually)

 

This leads back to an earlier thought with regard to scripting.

Within any given scripting environment it is good to start from something known and then move into the unknown.

What this means is that a script would be best optimized if it refers to a known environment.

One thing this might suggest is that a common scene would be used for all automated scripting (although the scene could be easily modified (i.e. via scripts).

 

We might think that the default Chor might supply this environment however, consider the issue with Cameras and Lights.

In order to use the Dopesheet methodoloy my current approach might have to replace the default Camera and Lights with a (single) Model that replicates (and theoretically enhances) the current default Chor Camera and Lights.

This seems an appropriate move because the Model can be easily changed in the Project Workspace (under Choreography) to a different setup by changing the shortcut to point to a different setup/model.

This would have the added benefit of allowing a user to remove/replace all the Cameras or Lights in a Scene with one change versus iterating through all assets (equating to saved production time).

All officially approved Sets for use with scripting would then simply have to have the minimum elements required by the scripting environment.

 

Please recall to memory as often as possible (ToaA:M page 49) where the paragraph begins: " Reusability is the foundation of Animation:Master."

You aren't required to believe this but it will help tremendously in understanding and leveraging A:M's scripting environment.