Along the years, I have accumulated tons of different utility functions for performing games-related geometric tests. Recently, I was faced by a task of implementing a generic script API for math and geometry handling. It would become a part of a generic API for a script-driven 3D engine. The scripting system would be used potentially by people who are very unfamiliar with scripting, and possibly even with mathematics. Around the same time, I was investigating developing code for a project that uses the Android NDK platform, and was looking for a math library to use on that architecture.


Rather than trying to solve the same problem twice for two different projects, I started collecting all the code I had scattered all over, and began bundling it up to an object-oriented package that would be usable for both projects. At first I was thinking this would only be a quickish job of collecting and repackaging existing code lying around on my hard drive:"I have this all here already.. I'll just quickly rename and move this and this around to make it coherent..", but not long after, I realized I was actually undertaking on *three* different projects:

  1. The main library for 3D mathematics and geometry manipulation, that I am now calling MathGeoLib, in the lack of any imagination.
  2. Since the library is being used in a scripting engine, the functionality needs a "glue layer" to be exposed to the scripting layer. Instead of trying to do it manually, I began to write an automatic script binding generator that generates the necessary code that provides the interop between C++ and JavaScript.
  3. Because the library will be the primitive base for a whole API of 3D mathematics and geometric manipulation, and the intended audience is for novices and non-programmers, the documentation is equally important, or even more important than the variety of the features themselves. Instead of settling for automatically generated doxygen reference pages, I wanted to create a documentation look that was more concise and clutter free compared to what doxygen offers. Therefore I started writing my own documentation generator (though using doxygen as the backend).

You can see the combined results on the MathGeoLib homepage. The library offers the following classes: float2, float3, float4, float3x3, float3x4, float4x4, Quat, Line, Ray, LineSegment, Plane, Triangle, Polygon, Circle, Sphere, Capsule, AABB, OBB, Frustum, Polyhedron, Clock and LCG. To browse the code, and have a look at what the new documentation generator looks like, visit the class reference documentation page.

Note that I am not overly interested in "preaching" people to start using this library, since I am not that big fan of open source development in general and I have little time to do free maintenance work or tech support on the library ("you are on your own"). Instead, I hope that the documentation and online source code will function as a useful repository to anyone looking for code snippets on how certain intersection tests or mathematical constructs are often implemented in game engines.

If you find it useful, go ahead and have a try. I am interested in hearing about any problems you might have, but remember that the burden of maintenance will be all yours to carry, if you go ahead and invest on this library. You were warned.