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.


Click Me

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.

Falling Leaf

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.



DOM Element
Scale myself

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.