Crimild v4.10.0 is out

This is it.

Crimild v4.10.0 is out and this will be the last of the 4.x versions. From now on I’ll be focused on the next major release for Crimild which will bring a lot of changes. 

But first let’s talk about what’s included in v4.10.0:

Render Graphs

I talked about them in the last couple of posts. Render graphs are great for creating highly modular render pipelines by combining different nodes representing render passes and attachments.

There are many nodes included in this release and many more will come in future versions.

Shader Graphs

Although shader graphs were actually introduced in v4.9, I ended up refactoring them to work in a similar way as render graphs do, simplifying both the internal implementation as well as the API.

Now, each node in the graph represents either a variable or an expression, and there’s also a way to discard nodes that are not relevant to the end result. 

The translation to GLSL mechanism has also being simplified, but I guess it could received a little more love in the future.

Most importantly, this newer API allowed me to create… 

Crimild Shading Language

Well, it’s not an actual programming language, but more of a set of functions providing us a way to write shaders in plain C++, disregarding the actual graphics API using for rendering. 

Of all the new features includes in v4.10.0, this is the one that got me more excited and I’m really looking forward to start creating shaders this way.

UI Canvas & Layout

Last but not least, I started working on several tools for creating UI elements, either in screen or world space. As it is right now, only basic UI elements can be created but there’s support for a very expressive set of layout constraints to arrange them in a canvas, with a size defined independently of the actual screen resolution and aspect ratio.

Minor fixes and updates

As usual, new releases come with a bunch of fixes and minor updates to existing features and v4.10.0 is not the exception.

There are a couple of new containers: Digraph and Set.

In addition, many changes have been made to how render resources are internally handled.

And I finally fixed some math bugs that have been causing issues for quite some time.

Please refer to the complete release notes on Github.

What’s next?

Crimild v4.10.0 includes a lot of (experimental) features that are going to became critical players in v5, Crimild’s next major release. 

The biggest goal for next year will be to refactor the entire rendering system, which has become quite limited and it’s time for it to level up. I’ll be focusing first on improving the existing OpenGL renderer before moving to Vulkan. Not sure what will happen with Metal support, though. 

Indeed, next year is going to be very exciting…

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!

Crimild v4.8.0 is out!

Crimild v4.8.0 is already available for download here!!

This new version, which is the first one of 2018, includes many new features and improvements, paving the road for the next major release for Crimild (hopefully later this year).

Key Changes


Introduced in this new version is the new Coding system. By implementing the Codable interface, objects can be encoded to and decoded from many different formats, including binary (particularly useful for production builds), Lua scenes (that can be used for data-driven scene creation) and any other custom format you need.

Here’s how the Node class implements the Coding interface:

void Node::encode( coding::Encoder &encoder )
   Codable::encode( encoder );
   encoder.encode( "name", getName() );
   encoder.encode( "transformation", getLocal() );
   encoder.encode( "worldTransformation", getWorld() );
   encoder.encode( "worldIsCurrent", worldIsCurrent() );
   containers::Array< SharedPointer< NodeComponent >> cmps;
   for ( auto &it : _components ) {
     if ( it.second != nullptr ) {
       cmps.add( it.second );
   encoder.encode( "components", cmps );

void Node::decode( coding::Decoder &decoder )
   Codable::decode( decoder );
   std::string name;
   decoder.decode( "name", name );
   setName( name );
   decoder.decode( "transformation", local() );
   decoder.decode( "worldTransformation", world() );
   crimild::Bool worldIsCurrent = false;
   decoder.decode( "worldIsCurrent", worldIsCurrent );
   setWorldIsCurrent( worldIsCurrent );
   containers::Array< SharedPointer< NodeComponent >> cmps;
   decoder.decode( "components", cmps );
   cmps.each( [ this ]( SharedPointer< NodeComponent > &c, crimild::Size ) {
     attachComponent( c );

The Coding system is an evolution of both the Stream system and the SceneBuilder pattern. Up until now, supporting loading a scene from a binary file or a Lua script required a lot of redundant code. The above code handles both formats (an any other Encoder/Decoder implementation) in a common interface.

Please note that the Stream, SceneBuilder, LuaSceneBuilder and all their related classes have been marked as “deprecated” and will be removed in later versions. 


The implementation of custom containers using the latest C++ features was long overdue. I’m happy to announce that included in this new version are working implementations for:

  • Array
  • List
  • Stack
  • Priority Queue
  • Map

The new containers support move semantics and traversing items by using lambda functions. In addition, they make use of the new ThreadModel policy to define how to handle concurrency.

Many new and existing systems already make use of these new containers. It is expected that the rest of the classes will be modified to work with these containers in later releases.

Please note that existing collections have been deprecated and will be removed in future versions.


Recently added to Crimild, behaviors are already a hot feature and are continuously being improved in each iteration. In this new version, all of the existing behaviors have been enhanced by supporting the new Coding system. No more individual builders and redundant code.


With the introduction of the Coding system, most of the classes available in the crimild::scripting module have been rendered obsolete. The new version includes implementations for supporting both encoding and decoding scenes from Lua scripts and there is no need to maintain separated builders for the Core classes.

An much more…

Check out the complete Release Notes for this new version in Github!

Feel free to contact me if you have any issues or comments. Feedback is always welcomed!