Crimild v4.2 is Live!

Finally! Crimild v4.2 has just being published

This marks the second release this year which means I earned some sort of achievement, right?

This new version includes a lot of new features and changes like Metal support in iOS/tvOS, skeletal animation, math improvements and streaming (yes, that’s back too), just to name a few. As usual, the API changed quite a bit to reflect these new features and some other ones have been deprecated or removed.

Download the new version here or clone the master branch.

Check out the full release notes here

  • Math
    • Return best match in intersection test
    • Implemented pow function in numeric
    • Implemented times function in Matrix and Vector to perform element-wise multipliciation
    • Added method in Ray class to compute interpolated point in ray
    • Fixed polynomial root solver bug
    • Added helper constants in Vector class for known vectors
    • Improved numerical methods
    • Fixed Quaternion SLERP interpolation
    • Allow transformations to be created form a 4×4 matrix
  • Core
    • Implemented NonCopyable classes (replacing CRIMILD_DISALLOW_COPY_AND_ASSIGN macro)
    • Implemented simple low-overhead RTTI facilities
    • Improved SkinnedMesh animation
    • Implemented streaming for objects in a scene
    • Fixed concurrency problems with render queues.
    • Fixed cloning for skinned mesh
    • Fixed FileSystem base directory bug
    • Check if message dispatcher instances are valid before invoking them
    • Implemented ArcPrimitive
    • Save skinned mesh (if any) when updating render state for a scene
    • Avoid discarding groups on culling pass.
    • New particle system
    • Implemented progress callback for animations. Fixed time for animation reset
  • Rendering
    • Implemented StandardRenderPass
    • Deprecated ForwardRenderPass
    • Deprecated BasicRenderPass
    • Implemented PostRenderPass for post-processing
    • Moved render passes to their own folder
    • Implemented ColorMaskState for occluders
    • Create and configure the screen buffer as early as possible
    • ForwardRenderPass will compute shadow maps in all platforms
    • Fixed shadow map shaders
    • Generate auxiliary FBOs on Renderer setup and store them in asset cache
    • Use GLEW from sources instead of as a submodule
    • Fixed directional lighting rendering issue
    • Improved debug render tools
    • (Experimental) Metal support on iOS/tvOS
  • Simulation
    • Clear AssetManager when stopping a simulation
    • Improved deinitialization for simulation and subsystems
    • Implemented axis state in input facilities
  • Scripting
    • Enable/Disable verbose logging for scripting from CMake
    • Improved light support on lua scene builder
    • Build new particle system from Lua script
    • Enhanced Lua builder to support physical entities
  • Audio
    • No changes
  • Physics
    • Fixed ground check for rigid bodies
    • Implemented function to detect ground collisions in rigid bodies
    • Implemented standard colliders for physical objects
    • Improved rigid body configuration for physical objects
    • Allowed to apply linear velocity to bodies during simulation
  • Testing
    • Fixed existing tests
    • Implement new tests for streaming
    • Modified CMake scripts to include GTest cases


Color masks and occluders

One of the newest features that will be included in the next major release for Crimild (coming soon) is the support for color masks and invisible occluders for our scenes.

Occluders are objects that block the visibility path, fully or partially hiding whatever is beyond them. An invisible occluder behaves in the same way, and while the object itself is not drawn it still prevents objects behind it to be rendered.

For example, in the following scene the teapot (in yellow) is an occluder. Other objects are orbiting around it and the scene is rendered normally.


Original scene with color mask enabled for all channels

By playing around with the color mask and turning it off for all channels we can avoid the teapot itself for being drawn, yet it still blocks the objects that are passing behind it. The green plane is not being affected by this behavior (that’s on purpose).

The effect is a pretty cool one and has a lot of applications in games and simulations. It’s specially useful in augmented reality to mix real-life objects with virtual ones.


I spent a weekend with a path tracer

This is definitely not how I was planning to spending my weekend (don’t get me wrong, I was going to work on some other things. What else would I do? Go outside and play with the other kids?)


It was Friday evening and I was doing a mandatory email check before leaving work when I saw it: one email from Amazon with some book recommendations, including the following one:


Go ahead, click the image and check out the book. I’ll wait

The goal of this book by Peter Shirley is to implement a basic path tracer in C++ in just a couple of days. I didn’t pay too much attention at the moment, other than it was quite cheap and got several goods reviews. But it stuck in my head for the rest of the night and I bought it as soon as I got home.

And that, kids, is how I meet you mother spent the weekend: in between math and a lot of waiting for low-resolution images to be rendered. I mean, A LOT of waiting. What an amazing weekend!

Honestly, it was an enlightening experience. The book is well written and a lot of fun to read. I’ve worked with ray tracers before, but a path tracer is a bit different. And, even when I follow most of the code examples from the book, implementing it on top of Crimild was a challenge on its own.

My implementation still needs a lot of work, but it produce pretty good images. Take a look:

As it is right now, the path tracer supports diffuse illumination for metallic, lambertian and dielectric materials. I ended up not implementing depth of field, since I’m not interested on that at the moment.

What’s next? Well, it does need some heavy optimizations, of course. The image at the top of this post took about 3.5 hours to render (no, that wasn’t a typo). The good news is that parallelizing the algorithm should’t require too much work. On the other hand, it would be great to render some actual triangles, not just spheres.

The other books in the series look promising and continue to improve the path tracer, so I’ll be giving them a look in the future. Check out Peter Shirley’s blog for more about his books.

As a side effect, being a math-based project, it allowed me to revisit Crimild’s math classes, making them even more robust. That’s pretty old code and somehow there’s always something to fix or improve.

Finally, if you need a good introduction to what a path tracer does, take a look at this excellent video from Disney’s labs

The code is in one of the examples projects. At the time of this writing I haven’t migrated the reusable code to the core library since I still need to do some review and cleanup, but that will have to do for now.