Eigen has Eigen::SparseMatrix, what's the equivalent feature in GLM? I've looked through its documentation, and googled, couldn't find it. But it's hard to believe glm doesn't have sparse matrix.
But it's hard to believe glm doesn't have sparse matrix.
Why is that so hard to believe? Sparse matrices are outside of GLM's job description.
GLM is intended to mimic the OpenGL shading language's vector/matrix facilities. Obviously it adds its own stuff, but that's the core of the system.
Sparse matrices aren't part of GLSL, so they're not part of GLM. And sparse matrices are kind of outside of standard graphics work, at least as far as common 3D or 2D transformation tasks are concerned.
This is also why its predefined vector and matrix types only go up to 4.
GLM is not a generic matrix/vector library.
Related
I know what is column-major and how to deal with it. Question what was there purpose to implement system in that way? Any technical or conceptual restricts?
By arranging matrices like that in memory, you have immediate access to the column vectors (obviously). When using right associative multiplication (i.e. what OpenGL and most other graphics systems do to allow for the easy chaining of transformations) the column vectors of a matrix are the basis vectors of the coordinate system the matrix is mapping to.
And having easy access to these basis vectors is kind of useful for further graphics operations, like setting up mirroring planes, billboards, etc.
TL;DR: When doing graphics programming you often want to use the basis vectors of a transformation for other things. If right associative multiplication is used, the basis vectors are the columns of the transformation matrices.
I am used to Eigen for almost all my mathematical linear algebra work.
Recently, I have discovered that Boost also provides a C++ template class library that provides Basic Linear Algebra Library (Boost::uBLAS). This got me wondering if I can get all my work based only on boost as it is already a major library for my code.
A closer look at both didn't really got me a clearer distinction between them:
Boost::uBLAS :
uBLAS provides templated C++ classes for dense, unit and sparse vectors, dense, identity, triangular, banded, symmetric, hermitian and sparse matrices. Views into vectors and matrices can be constructed via ranges, slices, adaptor classes and indirect arrays. The library covers the usual basic linear algebra operations on vectors and matrices: reductions like different norms, addition and subtraction of vectors and matrices and multiplication with a scalar, inner and outer products of vectors, matrix vector and matrix matrix products and triangular solver.
...
Eigen :
It supports all matrix sizes, from small fixed-size matrices to arbitrarily large dense matrices, and even sparse matrices.
It supports all standard numeric types, including std::complex, integers, and is easily extensible to custom numeric types.
It supports various matrix decompositions and geometry features.
Its ecosystem of unsupported modules provides many specialized features such as non-linear optimization, matrix functions, a polynomial solver, FFT, and much more.
...
Does anyone have a better idea about their key differences and on which basis can we choose between them?
I'm rewriting a substantial project from boost::uBLAS to Eigen. This is production code in a commercial environment. I was the one who chose uBLAS back in 2006 and now recommended the change to Eigen.
uBLAS results in very little actual vectorization performed by the compiler. I can look at the assembly output of big source files, compiled to amd64 architecture, with SSE, using the float type, and not find a single ***ps instruction (addps, mulps, subps, 4 way packed single-precision floating point instructions) and only ***ss instructions (addss, ..., scalar single-precision).
With Eigen, the library is written to make sure that vector instructions result.
Eigen is very feature complete. Has lots of matrix factorizations and solvers. In boost::uBLAS the LU factorization is an undocumented add-on, a piece of contributed code. Eigen has additions for 3D geometry, such as rotations and quaternions, not uBLAS.
uBLAS is slightly more complete on the most basic operations. Eigen lacks some things, such as projection (indexing a matrix using another matrix), while uBLAS has it. For features that both have, Eigen is more terse, resulting in expressions that are easier to read.
Then, uBLAS is completely stale. I can't understand how anyone considers it in 2016/2017. Read the FAQ:
Q: Should I use uBLAS for new projects?
A: At the time of writing (09/2012) there are a lot of good matrix libraries available, e.g., MTL4, armadillo, eigen. uBLAS offers a stable, well tested set of vector and matrix classes, the typical operations for linear algebra and solvers for triangular systems of equations. uBLAS offers dense, structured and sparse matrices - all using similar interfaces. And finally uBLAS offers good (but not outstanding) performance. On the other side, the last major improvement of uBLAS was in 2008 and no significant change was committed since 2009. So one should ask himself some questions to aid the decision: Availability? uBLAS is part of boost and thus available in many environments. Easy to use? uBLAS is easy to use for simple things, but needs decent C++ knowledge when you leave the path. Performance? There are faster alternatives. Cutting edge? uBLAS is more than 10 years old and missed all new stuff from C++11.
I just did a time complexity comparison between boost and eigen for fairly trivial matrix computations. These results, limited as they are, seem to denote that boost is a much better alternative.
I had an FEM code which does the pre-processing parts (setting up the element matrices and stitching them together). So naturally, this would involve a lot of memory allocations.
I wrote identical pieces of codes with Boost and Eigen on C++ (gcc 5.4.0, ubuntu 16.04, Intel i3 Quad Core, 2.40GHz, RAM : 4Gb) and ran them separately for varying node sizes (N) and calculated time using the linux cl-utility.
As far as I'm concerned, I have decided to proceed with my code in Boost.
Choose Eigen if you care the performance and performance gain introduced by expression templates, and choose uBlas if you only want to learn expression templates.
http://eigen.tuxfamily.org/index.php?title=Benchmark
I've been messing around with OpenGL a little bit and I don't fully understand what the purpose of the matrices are for. Is it to provide animation for the objects or something?
Matrices are used to represent transformations of points and vectors in openGL. I suggest you brush up on some linear algebra, and, in particular, you learn about transformation matrices. You cannot be a good graphics programmer without understanding transformations!
For 3D vectors, 4x4 matrix stores nicely all the needed transforms (move, rotate, scale, and project) in one simple package. And not only that, you can cascade transformations together by simple multiply operation. I think that is the main reason for those. Of course, you can also have 3x3 rotation matrices, as well as quaternions involved in transforms: still, 4x4 matrix can store all those transforms, although extracting single operations out of that can be pretty tricky.
The MultMatrix appears to only multiply 4x4 matrices, which makes sense for OpenGL purposes, but I was wondering if a more general matrix multiplication function existed within OpenGL.
No, as can be easily verified by looking at the documentation, including the GL Shader Language. The largest matrix data type is a 4x4.
It is very true there is a whole craft of of getting GPUs to do more general purpose math, including string and text manipulation for e.g. cryptographic purposes, by using OpenGL primitives in very tricky ways. However you asked for a general purpose matrix multiplication function.
OpenCL is a somewhat different story. It doesn't have a multiply primitive, but it's designed for general numeric computation, so examples and libraries are very common.
You can also easily code a general matrix multiply for NVIDIA processors in CUDA. Their tutorials include the design of such a routine.
A lot of people think, that legacy OpenGL's (up to OpenGL-2.1) matrix multiplication would be in some way faster. This is not the case. The fixed function pipeline matrix manipulation functions are all executed on the CPU and only update the GPU matrix register on demand before a drawing call.
There's no benefit in using OpenGL for doing matrix math multiplication. If you want do to GPGPU computing you must do this using either OpenCL or compute shaders and to actually benefit from it, it must be applied to a very well parallelized problem.
In newer OpenGL specifications, matrix manipulation functions are removed. You need to calculate the transformation matrices by hand and pass them to the shaders. Although glRotate, glScale, etc. disappeared, I didn't see anything in exchange...
My question:
how do you handle the transformations? Do you dig the theory and implement all by hand, or use some predefined libraries? Is there any "official" OpenGL solution?
For example, datenwolf points to his hand made C library in this post. For Java users (Android) there is AffineTransform class, but it applies to 3x3 matrices, so it needs an extra effort to apply it to OpenGL mat4
What is your solution?
how do you handle the transformations? Do you dig the theory and implement all by hand, or use some predefined libraries?
Either way goes. But the thing is: In a real program that deals with 3D geometry you need those transformation matrices for a lot more than just rendering stuff. Say you have some kind of physics simulation running. The position of rigid objects is usually represented by their transformation matrix. So if doing a physics sim, you've got that transformation matrix lying around somewhere anyway, so you just use that.
In fully integrated simulation engines you'll also want to avoid redundancies, so you take some physics simulation library like ODE, Bullet or so and modify it in a way that it can work directly on your object representing structures without copying the data into library specific records for procressing and then back.
So you usually end up with some mixture. Some of the math comes in preexisting libraries, others you implement yourself.
I agree with datenwolf, but to give an example I use Eigen, which is a fantastic general purpose matrix math library.
above glsl 3.0 the glTraslate(),glRotate(),fTransform() etc. functions are deprecated.. but still can be use.
one better way is to use some math library like GLM http://glm.g-truc.net/ which is compatible with the glsl specifications.
The projection matrix, model matrix and view matrix are passed to the shader as uniform variables.