Introducing my math library

I am trying to develop a math library for my new graphics’ projects. Many such libraries exist, but the thing is that I want mine to work both in C++ and in GLSL.

The idea is to implement GLSL’s built-in features in C++ first, and then create new ones based on them. Since the core features will be available in both GLSL (they are built-in) and C++ (I will have implemented them), the new code should be able to execute in both. Of course, care should be taken to use just the subset of C++ syntactically compatible with GLSL, but this hopefully won’t be a problem. The possibilities of this are quite promising.

For once, I will have a math library with sensible syntax (I trust the experience of the OpenGL® ARB) in C++. But also, it will allow me to double the worth of any addition I do to the library. When I will add the ray component to the library, it will allow for both CPU raytracing or GPU relief mapping. When I will add the sphere component, it will serve both as scene geometry or as an auxiliary structure for Screen Space Directional Occlusion. And so on.

The idea is to have these components defined in files that can be read and sent to the GPU for their compilation into a shader using glShaderSource.

There is already a library using GLSL’s syntax, called glm. It does not satisfy me because of two different reasons. First, the library does not implement all built-in features according to the specification. For example, some constructors are missing from the library (unsurprisingly. It’s amazing how many combinations of parameters are supported in GLSL). Another problem is that the extensions of the library are not built with the idea of being run in GLSL, and they won’t. For example, the quaternion class is actually a class. In order to work with GLSL it should be something like:

#define quat vec4

and a set of functions working over it. This is because GLSL does not support neither the classes nor even typedefs, but it does support some C preprocessor directives.

For all these reasons, I am developing my own library, which is proving to be quite a chalenge. The first problem I encountered was how to implement swizzling. The idea is to allow things such as:

vec2 v2;
vec2 w2;
vec3 v3;
v3.yz = v2.yx + w2.yy

Obviously storing in each vector all the possible permutations as public members and update all them when needed is a not an option. Basically because for a 4D vector there are combinations that would need to be updated concurrently for any vector operation. Not exactly efficient. Apart from that, it would still not work in the situation when swizzling occurs at the left-hand side of an assignation.

Using some macros and template meta-programming, the closer I have gotten is to have the following code working:

vec2 v2;
vec2 w2;
vec3 v3;
v3.yz = vec2(v2.yx) + vec2(w2.yy)

which is close enough and is still valid syntax in GLSL.

In the next post I will explain how.

No Comments

Hello world!

Well, and this is the first post. There is still much I have to do to customize this blog but I am ready to start writing.

By the way, the reason I chose this theme (Fussion) is that it allows to use a liquid (flexible-width) layout. It your resolution has more than 1024 pixels wide, feel free to press the button on the top-right of the screen.

No Comments