Crimild 2 and Github

Several months ago I made the call to move all of Crimild’s source code to Git and Github. The original goal was to export all the code to Git and start adding new features from there. But considering that existing code base is quite big and there is a lot of dead code and underused features, I decided to extract only the most interesting functionalities in order to make everything simpler.

And so Crimild 2 was born.

There are a lot of new features, like an enhanced shader-based rendering pipeline, post processing effects or improved components. And yes, I’m finally using quaternions for rotations :). And although there are some useful mechanisms that are still missing, like collision detection, scripting and streaming, all of them will be added in the future. For the moment I wanted to focus mostly on the rendering pipeline than in object interaction. Who knows, maybe I can bring the Sandbox back from the dead too…

Concerning how the code is organised, I’ve distributed it into two repositories:

This is the engine itself and contains all of the reusable code and tools. It also includes a good amount of unit tests for the most critical features (sadly, there are no rendering tests yet). Android (spoiler alert!) and iOS specific code will also live here, although of course they won’t make use of CMake for the building process.

As the name implies, this repository contains all of the demos. This is the good old examples directory in the SVN repository. The rationale for moving these projects to a separated repository has to do with how Crimild is integrated into other people’s projects. I’ve always recommended not to use a binary distribution and to include the source code directly, but having to download hundreds of MBs just to get the core features was a PITA. You’re welcome.

Finally, it’s worth mentioning that the SourceForge repositories are not going anywhere. At least not in the near future. I’ll keep them alive as much as possible, but probably no new code will be push there.

That’s it for the moment. Hopefully it won’t take me another year to write a new post, so I’ll see you around.


Forcing i386 architecture in Xcode 4.0.2 SDK

So I decided to upgrade to the new Xcode SDK on my Mac. And I did it during the weekend just in case something go wrong. And of course, something went wrong [Note: I’m not going to rant about the new Xcode interface. I just don’t like it. That’s it.]

Anyways, it seems the new SDK (Xcode 4.0.2) does not include the old gcc 4.0 compiler anymore. Instead, we’re left with gcc 4.2 which is optimized for 64bits compiling. The problem is that Crimild and some of the third-party libraries that I’m using do not yet support 64bits. I knew about this beforehand and my mistake was to trust that there will be no side-effect after the upgrade.

It turns out that after installing the new SDK, all sources files were built for the x86_64  architecture instead of i386, even when my CMake configuration was forcing a specific configuration:

SET ( CMAKE_CXX_COMPILER /usr/bin/g++-4.2 )
SET ( CMAKE_C_COMPILER /usr/bin/gcc-4.2 )

After a lot of try and error (and a little bit of reading), a verbose make all process indicated that the -arch i386 compiler flag was correctly set at compile time, but there was no sign of it in the link phase. Then, I changed CMake to look like this:

SET ( CMAKE_CXX_COMPILER /usr/bin/g++-4.2 )
SET ( CMAKE_CXX_FLAGS “-arch i386” )
SET ( LINK_FLAGS “-arch i386” )
SET ( CMAKE_C_COMPILER /usr/bin/gcc-4.2 )

It seems a little bit redundant to me, but then again, this is the configuration that worked on both Eclipse and the Terminal. So I changed the CMakeLists.txt file with the new flags, cleaned up the CMake cache and regenerate the Makefiles. And everything worked again and all developers lived happily ever after (or at least until July, when the next SDK comes out).

I’m not sure if other people had the same issue (I couldn’t find anything relevant out there), so I’m leaving this here just in case someone needs it. Guys at Google, I know you’re reading this 🙂

Skeletal Animation Part 2: Animating Joints

COLLADA is a great standard for storing 3D scenes, but its flexibility may become a nightmare in some situations. While allowing multiple representations of the same data is a huge benefit for modelers since they can create a great variety of scenes, having to read and handle all of that data might become overwhelming for developers.

While I was importing joint animations, I realized that COLLADA files may specify samplers in several different ways. Is the file using baked matrices? Are samplers modifying only one transformation value per frame? What kind of interpolation is supposed to be used during the animation?

I ended up simplifying the process by constraining the importing process. For example, baked matrices must be used to indicate animations and only linear interpolation is supported. In the first case, input files may be slower to read, but the code to parse an animation is a lot simpler. In the later case, animations might not be displayed as the artist has defined, but that’s not an issue for moment since I’m not supporting skinning yet. Anyways, these constrains can be removed in the future as needed. The code for the COLLADA importer is now more extensible than before, although it still needs reworking in some sections.

So, after some time of coding I managed to read and store all animations for each joint in the skeleton. The next images show the skeleton in different positions:

Up to this point, I still need to define a way to handle animations once they are loaded since the current demo is only playing all animations one after the other in a loop. But before that, I’m going to finish this feature by implementing skinning support. I’m considering GPU skinning only since most platforms are able to do so. As usual, I’m going to leave the implementation open just in case that custom skinning if needed. Stay tunned.