Crimild v4.9.0 is here!

I’m proud to announce that Crimild v4.9.0 is available now, including many new features and improvements:

New Animation System

I admit it. Crimild’s previous animation system was awful and pretty much useless. The new one allows for a lot of modern features like interpolation and blending (including support for additive blending). And, most importantly, it works with several animatable types, like single values, vectors, rotations, joints and so on.


If you want to know more, I wrote a post about the new animation system some time ago that is worth checking out.

New Shader Graph

Modern shader development requires a way to write shader code without having to worry about wether we’re working with OpenGL, OpenGL ES or even new APIs like Metal or Vulkan.

Crimild now supports a builder abstraction in the form of a Shader Graph, where you chain operations and values together which can be later translated into, for example, GLSL code.

If you want to know more about shader graphs… you’ll have to wait because I didn’t write anything yet.

SDL is back!

The SDLSimulation comes back to life from the ashes!

Well, not exactly. The SDL-based simulation is now making use of the SDL2 libraries, which are a big step forward form the classic ones that were use by Crimild in the past (in the SourceForge/SVN era).

Why am I using SDL again? Because it made sense. I was using GLFW for window and input management and SFML for audio, which was overkill and not really helpful beyond PC and Mac. SDL has support for iOS, Android and works well with Emscripten too. So, having only one library for multiple platforms made sense and greatly simplifies things.

As a side effect, I’m deprecating GLFW and SFML support and they will be removed in the next major version (some point next year).

Emscripten Support

What? Emscripten too? Yes! Emscripten is now officially supported by Crimild using CMake. Assets can be automagically bundled into the resulting web package and there’s even audio support thanks to SDLMixer2.

Here’s a live demo. Check it out!

Bare in mind that Emscripten support is still experimental, but I’m planning on keep improving it in future releases, of course.

And many more!

There are a lot of other features, minor updates and modifications. Check out the full Release Notes for the Crimild v4.9.0 at Github to know more.  And all demo projects have been updated as well to use the latest version.

As usual, feel free to check the code and make comments.

Have fun!


New Animation System!!

Look at the title of this post.

Now look at it again.

Read it out loud!


There’s a new animation system in Crimild. And, most importantly, it actually works!

I’m really, really happy with what I managed to achieve over the course of the last weeks for the new animation system. Not only it provides a clean and simple to use interface, but it’s also powerful enough to achieve different blending and post-processing operations.

Just take a look at the new animation system in all its glory:

Low-Level API

The new animation system has been designed to work as a low level API for animations, not only for skeletal meshes, but for any quantity that you want to animate over time. The rationale behind this design is to be able to integrate the animation system with other systems like controllers, behavior trees or shader graphs (spoiler!).

The core classes related with the new animation system are:

Channel: Contains keyframe data and times for each key. For example, it may hold positions or rotations data over time. It is also responsible for evaluating such data at any given time and performing interpolations if needed.

Clip: Contains one or more clip for a given animation. For example, a clip that represents a walking animation for a skinned mesh should contain the position and rotation channels for each bone in the skeleton.

Animation: Computes an animation based on a clip and other params, like duration or frame rate. It also contains all accumulated values for a given point in time. Two or more animations can be chained to achieve different results like blending or masking.

Accumulator: Holds the result for a single accumulated value after computing an animation. For a given skeleton, for example, each accumulator will be associated with a bone.

Skeleton: Contains a set of bones and the animations associated with them. A skeleton may contain multiple animations, like walking, running and jumping.

An example

Let’s consider a simple animation, like rotating a triangle around the Y axis:


The pseudo-code for achieving such animation will look like this:

/* Scene Setup */
crimild::Quaternion4 keys[] = { /* Rotations over time */ };
crimild::Real32 times[] = { /* Time for each rotation */ };
Channel *rotations = new Quaternion4fChannel( "rotation", times, keys );
Clip *clip = new Clip();
clip->addChannel( rotations );
Animation *animation = new Animation( clip );
Geometry *triangle = ...

/* Update Loop */
Clock c = /* get current frame's clock */
animation->update( c )->getValue( "rotation", triangle->local().rotate() );

Notice the update step: First we update the animation by passing the clock for the current frame. Then, we get the computed value for the rotation channel and apply it to the transformation for the triangle.

Chaining Animations

As I mentioned before, the new animation system allows animations to be chained together if needed. This allows to compute new animations procedurally by combining existing ones.

For example, the following chain:

Animation *walk = ...
Animation *run = ...
crimild::Real32 speed = 0.5f;
Animation *result = walk->update( clock )->lerp( run, speed );

Will result in an animation that’s half way between walking and running. First, we need to update the base animation (walking) for a specific point in time. Then, we interpolate it with the second animation (running) using the value of speed. The function lerp automatically synchronizes the two animations together before computing the interpolation.

You can keep chaining animations, adding or interpolating them to achieve different effects as show below.


The demo shown at the beginning of this post was implemented by using additive blending to perform head tracking for the character. Additive blending is an animation technique that combines animations by computing a “difference clip”, the result of subtracting a known pose from an exiting animation data, and adding that to a third animation.

In other words, the walking animation above is combined with the one that results from subtracting the idle pose to the head turning animation, which is nothing more than just a bunch of rotations for the neck.

The head tracking animation itself is computed by interpolating from five other animations (look up, down, left right and center) using the mouse position as the interpolation factor.

But wait! There’s more:

This is a classical animation blending demo that computes transitions between different clips.

Each wolf has four animations pre-defined: idle, stalk, walk and run. Based on the value of a variable “speed” (itself controlled by user’s input), two or more of those animations are linearly interpolated, resulting in smoother transitions.

For reference purposes, the wolf on the right does not perform any interpolation at all. Notice how it just “jumps” from one state to the next, making the changes in animations to be quite visible.

This is only the beginning

What I achieved so far is just the barebones for a true animation system. There are still many enhancements that will be implemented over time, like inverse kinematics, locomotion controller, custom interpolators, integration with behavior trees…

The road ahead will be a lot of fun.



Oh, Behave (III) – Decorators

As we’ve seen before, composites let us build complex behavior trees by combining smaller ones and executing them in several different ways. Still, we’re in need of a way to add new features to existing behaviors, like inverting its result or execute it multiple times or until a given condition is met.

Modularity and reusability are key when working with behavior trees (actually, that applies to pretty much all in software engineer). Therefore, we should avoid reimplementing a behavior whenever possible. So the question is: how can we add these new features and maximize reusability at the same time?

That’s when decorators are added to the mix.



In contrast to composites, decorator behaviors have one and only one child behavior. Although technically doable, there is no gain in adding a decorator as leaf node to our tree, since their strength lies in modifying existing behaviors.

Decorator behaviors add new functionalities to their child behavior without necessarily knowing its internal execution. A decorator behavior may transform the result provided by their child behavior and/or change the way it’s executed in some other way.

For example, a common use for decorators is to repeat the execution of its child behavior until a given condition is satisfied, independently of what the child behavior actually does.

Available Decorators

At the time of this writing, the following decorators are already available in Crimild:


A Repeat behavior will execute its child behavior multiple times. There are several variations of the Repeat behavior, implementing different looping conditions. For example, we might need to loop only a limited number of times or do so until the child behavior fails or succeeds.

If, for example, you need a character that should run from one location to another, you’ll probably be using a Repeat behavior along with a Sequence or Selector that moves the character and check if the destination has been reached in every loop. Such a behavior tree should like this:

  |-> Sequence
        |-> AwayFromTarget
        |-> Move

The behavior tree above will move a character (or any Node) until AwayFromTarget fails. When that happens, the Sequence behavior will fail too and RepeatUntilFail itself will terminate (you might be surprised to know that RepeatUntilFail will return a SUCCESS result even when the inner behaviors failed. That’s because the loop itself did succeeded).

Another use of a Repeat behavior is to just execute the same behavior over and over again, like and idle behavior.


As the name suggests, an Inverter behavior will change the result of its child behavior once it has been executed. Then, if the child returns SUCCESS, the Inverter will return FAILURE, and vice versa.

Inverter behaviors are commonly used to check conditions inside a loop. The behavior tree shown earlier could be rewritten as follows:

  |-> Sequence
      |-> Inverter
            |-> ArrivedAtTarget
      |-> Move

Basically, move the character as long as we’re not at the target location. In this case, the Inverter behavior allows to reuse other behaviors. Otherwise, we might need to implement behaviors for all cases.


A Succeeder behavior always returns SUCCESS, disregarding of whether its child behavior returned SUCCESS or FAILURE. This behavior is useful when we need to branch the executing of a tree.

Please not that there is not “Failer” behavior since that can be accomplished by using an Inverter behavior on a Succeeder.

Other uses

Decorators are quite powerful and could radically change the execution of a branch in order behavior tree. Here are some other uses for Decorators:

  • Avoid executing the child node based on a predefined condition
  • Avoid executing a branch in our tree based on a timer
  • Deal with error status
  • Pause execution of a tree (like a breakpoint)

By combining Sequence and Decorator behaviors in our tree we can create really complex logics for virtually any logic we would like to achieve.

It’s show time!

Enough theory. The time has come for us to see behavior trees in action.

So, in the next episode, we’re going to create at a live demo to better understand how behavior trees work in practice, their strengths and limitations.

Stay tuned.