As I started working on skeletal animation, there was a need for a couple of utility classes specifically designed for debugging purposes. So here they are:
The HierarchyRenderComponent class
One of these utility classes is the hierarchy render component, which I’m using in this example to render all bones in the model:
HierarchyRenderComponent class in action drawing bones on a rigged model
This render component implementation traverses a scene drawing lines from parents to each of its children. It requires a shader program to draw the lines, but it can be customized as much as needed. For example, I’m working on a version of the shader using different point size for the joints between bones that will be available soon.
The SceneDescriptor class
The other one is a visitor implementation that prints out all nodes in the hierarchy. That way I know if a scene is composed as I expected (and also if I’m adding more group nodes that needed). Here’s the console’s output after loading the scene in the image above:
Example output for a loaded scene
This class is particularly useful to find out which nodes are redundant and can be eliminated. For example, a GroupNode with only one child and no transformations applied it’s hardly useful and can be completely avoided.
Both of this classes are part of the new Crimild::Debug namespace. My intention is to create as many of this utility classes as needed in order to provide a reusable debugging library for any Crimild-based project.
After reading a lot about the subject, I finally started my crusade to add skeletal animation support on Crimild. It’s going to be a behemoth task, so this will be the first post of many about the subject.
But before performing skeletal animations we need to have something to animate, right? The COLLADA file format specification seems to be the best choice once again. It successfully manages to store animated models with all of their complexities in a standard file format regardless of the tool used to create them.
Although Crimild’s COLLADA support was able to read static scenes, it turns out that rigged models (that is, models containing skeletal information) are stored in a different way. Then, my first task was to upgrade it in order to read the data in the correct fashion. I had to refactor a couple of methods in the importer in order to load both the skin (that is, the actual mesh) and the skeleton and a couple of hours later, the result looked at this:
A rigged model and its skeleton
The model is one of the many example files in the COLLADA Test Model Bank. In the image you can see the skin as well as several white lines that indicates the presence of a skeleton. Of course, the skeleton is drawn just for debugging purposes.
Here’s another model downloaded from 3DRT:
Another rigged model
One thing that keeps bothering me is that the COLLADA importer is getting bigger and bigger in each iteration, making it difficult to maintain (even for me). So I guess I’m gonna have to do some major code review there in the near future.
Stay tuned to know more about skeletal animation support in Crimild.
Last week I was doing some testing with custom render components and I ended up creating a new demo that implements a reflections. You can see the results in the next image:
Long story short, I’m using a custom render component that creates a reflection of a given scene in four steps. The first step is to render the base plane (the one that will be used to reflect the scene) into the stencil buffer. Then, we render the reflected scene using the stencil buffer information to clip those portions of the reflection that lie outside of the base plane. The reflection illusion is created by rendering the scene upside-down.
Rendering the reflected scene
The third step is to render the actual scene. No special process is required here:
Rendering the scene on top of its reflection
The last step is to render the base plane again, this time enabling textures and lighting. In addition, we’re going to use forward-to-back blending, creating the illusion of a polished surface and producing the final effect.
The final result
The source code for this example can be found in the examples/Reflections directory. The custom render component used in this example is not as generic as I would like it to be, but it can be easily modified to suite any scene if required.