VSMathLib – Very Simple Math Library

This lib aims at providing a less steep learning curve for those who are familiar with OpenGL (pre 3.0) and want to use the core profile of more recent OpenGL versions.

One of the features that was not selected to be part of the core functionality was matrix handling. Previously we had OpenGL and GLU functions that provided the means for easily setting the camera, defining projections, and performing geometric transformations on graphical objects.

Writing a “hello world” type of application, such as drawing a triangle in OpenGL, was fairly simple. Teaching OpenGL was also made easy due to this built in functionality.

Now writing a hello world is far more complex. Hence teaching OpenGL is also more difficult.

Is there any benefit in removing the matrix stuff from OpenGL? I honestly don’t see any advantage. Yes the driver code is simpler and lighter. But the matrix code was already stable. I find it hard to believe that any one implementing drivers would have any major objection to keeping that code on the basis of increasing difficulty in the drivers code maintenance.

Also, performance wise, I don’t thing there are any major benefits in removing this code. These matrix operations still have to be performed and they are present in the vast majority of graphical applications. Are we, the programmers, who are not supposed to know the inner workings of the driver, expected to build a more efficient implementation of these functions?

Furthermore, graphical applications are about drawing a very large number of triangles. This number has increased over time, and it will continue to increase as the hardware keeps getting better and better. So in what sense are the matrix setting operations harmful performance wise? Are glTranslation or gluLookAt the culprits for performance issues?

As for matrix access inside a shader, It is also not clear to me how we programmers can provide a better solution than a driver who controls the whole process.

So, from where I stand, building an OpenGL application from scratch has become harder, and teaching people how to do it as also become harder. And I haven’t still seen a good justification for it.

The matrix functionality does not have any implications with the new features, it worked perfectly with shaders, hence its usage was not limited to fixed functionality.

There should have been an attempt from Khronos to explain why dropping such functionality was necessary. The arguments that I’ve heard, driver maintenance and performance issues, don’t seem to be very convincing to a lot of people.

Assuming that there are really strong arguments for dropping this functionality, then Khronos Group should have made an effort to ease things for programmers to adopt the new core profile. This could have been done with some auxiliary software libs that replaced the missing functionality. Programmers could start using the core profile from day one with those libs, and slowly start to move on to more efficient solutions performance wise, assuming that the software libs had a real measurable impact on the applications.

For instance, dropping the immediate mode seems wise from a performance point of view  (although we had display lists to cover for that, and they worked well, at least on nVidia’s hardware), but suddenly we lost the ability to display fonts on an OpenGL window as the available libs for this purpose that I know of all use non-core functionality.

Gaming industry on the other hand does not suffer from this right now. For a game house, with all the expertise they already have, it is fairly simple to implement all the missing features, and probably most of the companies didn’t use them anyway.

Nevertheless, the harder it is to teach and learn OpenGL the more likely people will search for other solutions for 3D graphics without the added complication that the core profile entails. In the long term these options can have an impact on the number of people who use OpenGL to teach 3D graphics and this can’t certainly be beneficial for spreading the usage of OpenGL.

As Knuth once said: “Premature Optimization is the root of all evil”. I just hope that this isn’t the case with the core profile.

This is just an opinion, please do contradict me if you feel otherwise. I want to be convinced that OpenGL is on the right track 🙂

Anyway, enough complaining 😉

For more information on this lib visit the In Action and Specification pages.