I love CMake. It’s extremely powerful and adds a lot of flexibility to your build process. It’s also the most cross-platform and widely supported build system for C and C++. With CMake you can describe a project that will build anywhere. This article will show you how to use it to create a virtual python environment with custom requirements that you can then integrate into the rest of your build process.
Generating C++ code using Python and CMake
Using code generators is very common for C++ developers. It becomes necessary when there’s a known high-level logic that is too hard, tedious, or repetitive to write manually. In those cases using an external tool to generate C++ from a high-level description starts to make sense.
Another benefit is that it allows us to improve performance via optimizations that are otherwise hard to maintain. The developer doesn’t have to worry so much about the readability of the generated code, as they only have the generator or its input to deal with.
C++ already has some built-in code generating capabilities: Templates and Macros are meta-programming features that get used quite a lot, despite their individual shortcomings. Unfortunately they’re often not enough; writing a script to generate code for us can be a better alternative in certain situations.
Generators and parallel processing in Python
Parallel processing isn’t nearly as difficult as I thought it’d be when I first started learning about it. This is due to the fact that modern operating systems and programming languages already handle most of the hard parts for you and let you worry only about the implementation of your algorithm.
But a solution to a problem isn’t perfect just because it’s “parallel”. And no, this statement is not about the diminishing returns of parallelisation (which is a whole other issue), but there are bad and good implementations of any parallelised algorithm. This post explains how to leverage generators in Python to enhance parallelisation so that waiting time is minimized while the code itself remains simple and reusable.
Most older posts are gone
I have made the decision to hide most old posts except a few that look like they could still be useful today. The reason is that a lot of points I’ve made in other posts fall into one or more of these categories:
- Obsolete/deprecated (Relevant framework changed to fix them, or no longer work with latest versions of framework)
- I was young and foolish (Bad advice given from my own inexperience)
- Not that interesting!
Since I don’t use Unity anymore, the posts which did survived the purge are still not guaranteed to work or be relevant today. I’ve no interest to go back and fix or revise them unless someone points out a specific fault in them.
New posts have not been coming, and that’s because I have less time to experiment in non-work related stuff. However, this site will still be reserved for the future as it doesn’t really cost that much to keep up and running.
A better method to recalculate normals in Unity – Part 2
It’s been over 2 years since I posted about a method to recalculate normals in Unity that fixes on some of the issues of Unity’s default RecalculateNormals() method. I’ve used this algorithm (and similar variations) myself in non-Unity projects and I’ve since made minor adjustments, but I never bothered to update the Unity version of the code. Someone recently reported to me that it fails when working with meshes with multiple materials, so I decided to go ahead and update it.
Serializing delegates in Unity
Delegates are one of the nicer features of C#. They’re essentially high-level and type-safe references to methods. But, like pretty much every fancy C# feature, delegate values are not serializable by default. If you hold a reference to a delegate, it will be lost during code hot-reload. I will show you a way to serialize them and explain how they work.
Note: This solution is inspired by the uFAction tool in Unity, which I am not affiliated with. Go check it out here.
Custom Serialization with ISerializationCallbackReceiver
Starting from Unity 4.5, any class can be made to inherit from ISerializationCallbackReceiver. This allows us to write methods that can be used to control seialization and deserialization, and it demands from the class to implement two public methods: OnBeforeSerialize() and OnAfterDeserialize(). These methods are automatically called when that class inherits from UnityEngine.Object or is marked with the [Serializable] attribute.
The idea behind this concept is both simple and powerful, but there are certain things you need to have in mind. Not only I will show you how to use this interface, I will also provide some information on things you should avoid or on things that won’t work as expected.
Controlling ScriptableObject instantiation
ScriptableObjects become (unfortunately) necessary when you start developing editor tools. That, and every other class that inherits from UnityEngine.Object, has the unique ability to maintain proper references after deserialization. Every other class creates a copy per reference (as if it were a struct) after deserialization, which can be very troublesome.
One of the least pleasant aspects of ScriptableObject is that you cannot control their instantiation. Using their constructor to create them does not work as expected. The only proper way to create a ScriptableObject from scratch is to call the ScriptableObject.CreateInstance<DerivedType>() static method, where DerivedType is a type which derives from ScriptableObject. Unfortunately, This method does not take any parameters. I will show you an easy way to help control their instantiation, so that the users of your ScriptableObject classes will be less prone to use them incorrectly.
C# Properties in Unity
C# Properties are one of the nicer features of C#, but there are things to keep in mind when using them in Unity. The framework doesn’t seem to like them too much. I will show you what the Unity-specific problems on using properties are and how to easily address them.
A better method to recalculate normals in Unity

You might have noticed that, for some meshes, calling Unity’s built-in function to RecalculateNormals(), things look different (i.e. worse) than when calculating them from the import settings. A similar problem appears when recalculating normals after combining meshes, with obvious seams between them. For this post I’m going to show you how RecalculateNormals() in Unity works and how and why it is very different from Normal calculation on importing a model. Moreover, I will offer you a fast solution that fixes this problem.
This article is also very useful to those who want to generate 3D meshes dynamically during gameplay and not just those who encountered this problem.
The Scheming Developer