Simple Transforms and Triggering
Basic Triggering
The behave3d library contains controllers that perform complex transformations onto their HTML elements, but since many complex movements and other transformations can be achieved by superposing and timing simple transformations, special effort was put into making the behave3d's basic controllers easily scriptable. You can define and create a controller (or even a few controllers) on a single line, and on this line you can set not only the controllers' parameters, but also initial messages (i.e. commands) and conditions for triggering other messages (like starting, stopping, reversing direction, pausing, etc.), avoiding the need for creating many callbacks that 'stitch' the animation together.
The example above describes two move() controllers. The second one, m2, will automatically start when m1 starts,
and will automatically start moving backwards 2 seconds after m1 finishes its movement.
Triggering by DOM events
For the common case when an animation must be triggered upon a DOM event (ex. a mouseover), bubbling (or capturing) through the DOM node,
every behave3d element has an automatically-generated actions(id: a) controller,
which, among other things, can listen to DOM events and, upon receiving such, fire behave3d events.
Adding of behave3d event listeners
behave3d's event system is by no means a complete solution, it's here only to save the code from being bloated too much by one-command callbacks. Let the behave3d engine make these callbacks for you. For all the cases when these simple message-on-event triggers are not enough, event listeners can be set.
Combining Basic Transforms
Here's an example that shows the importance of the order in which the controllers are defined, as it affects the order in which the CSS 3D transformations are applied onto the element. A translation after rotation is different than rotation after translation. This should be kept in mind when constructing complex transformations.
All examples above use tranformations that follow fixed trajectories and so have exactly-known end positions arrived-at on the exact frame. While these are convenient and easy to work with, fixed linear trajectories, even with a nice easing, make for stiff, rigid animations. Simply because it's unnatural to have bodies suddenly switching directions, as if they have no inertia. Even following Bézier paths does not look natural because the change in direction is not automatically linked to change in speed in any inertia-suggesting manner.
The behave3d library offers some functionality for creating movements (and changes in other properties) that resemble more closely the movements of real physical objects - each animated property, not only the position in 3D space, can have 'inertia'-like behavior.