Subject: [boost] Is there any need for a math library doing vectors and matrices operations?
From: Christophe Riccio (g.truc.creation_at_[hidden])
Date: 2008-11-03 12:26:27
Hi,
For a 3D programmers using vectors and matrices is as common as using
integers. Actually, it's probably even more common!
For this reason, every 3D programmer relies on a math library but as they
usually don't need much … they implement their own basic math library and
that fine. However, most of the time a single graphics software could uses
several math libraries because it uses several external libraries that each
of them use there own math library.
It involves:
- A lot of unnecessary copy and conversion of data.
- Different meanings for overloaded operators.
- Unspecified conventions: row major matrix, column major matrix, left or
right handed?
- Use of poor math libraries.
- Several libraries to understand, to learn: a waste of time for trivial and
common need!
GPU programmers get some really convenient languages to do graphics on GPU.
Cg:
http://developer.download.nvidia.com/cg/Cg_2.0/2.1.0012/Cg-2.1_October2008_LanguageSpecification.pdf
HLSL: http://msdn.microsoft.com/en-us/library/bb509561(VS.85).aspx<http://msdn.microsoft.com/en-us/library/bb509561%28VS.85%29.aspx>
GLSL:
http://www.opengl.org/registry/doc/GLSLangSpec.Full.1.30.08.withchanges.pdf
These languages are the result of a lot of experimented developers in 3D
graphics and are basically the same. I decided to build a C++ math library
based on all the rules that those developers agreed to be good rules and it
result in GLM: http://glm.g-truc.net.
However, those GPU languages provide good features but limited features: No
quaternion, no transformation, lot of limitation on types and rules that
couldn't apply directly in C++ (swizzle operators). GLM has limitations
because it results of too few developers to think about it. I would like to
get more feedback and makes it even more useful. I would lie to making it
better find more agreement so that one day it could be ready to be
integrated to Boost and hopefully to C++ standard.
I'm afraid that such kind of library already have been submitted and
rejected, I know it need more work but I believe on my approach and I'm not
afraid to change the library so that everyone agree it's good.
Thanks,
Christophe Riccio