Jump to:

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?.

Comments

Comment viewing options

Benchmarks have shown structures to be significantly faster than classes for this kind of use, due to smaller memory footprint and stack allocations (you can create math structures at will without involving the GC). You can avoid the copying overhead by using overloads that use ref and out parameters.

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.

The translation elements in this case are m, n, o which 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...