
Math namespace Question
Posted Monday, 2 November, 2009 - 19:43 by mohamed_helala| Project: | The Open Toolkit library |
| Version: | all versions |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | mohamed_helala |
| Status: | closed |
Jump to:
Description
dear
i would like to ask questions regarding the core of opentk.
1- the Math nameaspace contains implementations for the matrixes and verctors used allover opentk. all these types are implemented as structures rather than classes, the question is why?. all this copying of structures that may results in a memory overhead.
2-the matrix structure of the Math nameaspace (matrix4d) implements a transformaton matrix with last row as the translation vector rather than the last column which is opposite to the conventions used in literature. so why?.
best regards


Comments
#1
refandoutparameters.#2
Closing after a week without activity.
#3
First, I would like to express my thanks to those who are developing this neat open-source library.
Regarding the proper placement of the translation coefficients into the transformation matrix, all the literature (OpenGL Reference Manual, OpenGL Programming Guide, and, above all, the specs of Opengl) places these coefficients at the last column of the matrix rather than the last row, and performs the transformation of a homogeneous point P with a 4x4 matrix M using the following formula:
P' = M P <------- (P and P' are represented by column vectors)
The layout of the matrix values in memory (row-major vs column-major) has nothing to do with this issue. It is D3D that adopts the convention of putting the translation coefficients at the last row and performing the transformation this way:
P' = P M <------ (P and P' are represented by row vectors)
In addition, if you have two transformations M1 and M2, where M1 is to be applied first, the composite transformation M' in OpenGL is given by:
M' = M2 M1
On the other hand, D3D concatenates them this way:
M' = M1 M2
Currently, the Math library of OpenTK adopts the convention of D3D rather than OpenGL. In my opinion, it will be a source of bugs and confusion for people who are familiar with OpenGL (for whom the library is actually designed).
So, I suggest to adopt the OpenGL convention in this library rather than D3D either by changing the implementation of the current matrix class or by implementing a separate one and keeping the current. The first suggestion is better because I have not seen any code sample or example that uses the Matrix4d class.
Best Regards
#4
If I might...
Yes, the OpenGL convention in this area is very unfortunate. It is against the common way of laying out arrays in memory:
The translation elements in this case are
m, n, owhich makes the matrix row-major. Which IS very much related to the way the matrix is stored in memory no matter what someone from ARB said twenty years ago. Things get messier with OpenGL state machine being droped and everyone writing their own shaders.Pardon me but it's way easier to transpose the matrix than to keep in mind what index goes where all the time.
Edit: It is against the natural way of writing matrices on paper as well. Never seen anyone writing them by columns...