Hi Gazi,
It is true that OSG differs from your literature. That does not make OSG
incorrect. In fact, the literature wasn't always dominated by the format
you're promoting.
This link http://steve.hollasch.net/cgindex/math/matrix/column-vec.html
provides some history on the matter.
One format isn't correct, and the other incorrect. It's simply a
convention, and one needs to be aware of the convention used in the
context in which one is working. OSG assumes row vectors while OpenGL
assumes column vectors, but OSG (like C++) uses row-major ordering while
OpenGL uses column-major ordering. This combination makes OSG binary
compatible with OpenGL but not notationally compatible. Perhaps binary
compatibility and ease of coding was the reason for the convention
chosen, or it could be other historical factors. We would have to get
that answer from Robert. Whatever the reason, that's the convention OSG
uses and it's in no way 'incorrect'.
Direct3D (and presumably any literature directed to it) uses the same
row-vector convention as OSG so it's hard to convincingly paint OSG as
some maverick API in this context.
Regards,
Mark
Gazi Alankus wrote:
A correct transformation matrix (which is a 2D entity) according to
math literature:
R11 R12 R13 Tx
R21 R22 R23 Ty
R31 R32 R33 Tz
0 0 0 1
That matrix stored in column-major order in 1D memory:
R11 R21 R31 0 R12 R22 R32 0 R13 R23 R33 0 Tx Ty Tz 1
That matrix stored in row-major order in 1D memory:
R11 R12 R13 Tx R21 R22 R23 Ty R31 R32 R33 Tz 0 0 0 1
If these are the things you dispute, that is an easier argument to
deal with. Otherwise my response follows:
2009/1/15 Paul Fotheringham <[email protected]
<mailto:[email protected]>>
[...]
Eh? By what definition exactly?
http://fly.cc.fer.hr/~unreal/theredbook/appendixg.html
<http://fly.cc.fer.hr/%7Eunreal/theredbook/appendixg.html>
http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/translate.html
http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/rotate.html
Rotation matrix order:
http://en.wikipedia.org/wiki/Rotation_matrix
Which is the order in the OpenGL man pages. If you create a simple
rotation matrix in OSG and compare it to there, you'll see that it's
transposed according to this definition.
OpenGL is neither row-major or column-major.
http://en.wikipedia.org/wiki/Row-major_order
You can't store a well-defined multidimensional entity in one
dimensional storage and say it's neither. If you do, the definition of
the multidimensional entity becomes open to interpretation. Which
actually is not, as explained in the next paragraph.
It treats a transformation matrix as 16 floats, nothing more. Only
when one imposes a 4x4 structure of rows and columns on the 16
numbers does one then encounter the question "Which way shall I
order them?". At that point you choose row-major or column-major
as the description of how your data is stored in the matrix.
Yes, and the definition of the matrix multiplication operator in OSG
makes it clear that the first index of the array is rows and second
index is columns. Also if you look at the code closely, the first
index is always referred to as rows. So, when you treat the indices as
such, you see that the matrix being stored is actually a transposed
version of a transformation matrix. Hence, you have to treat them as
transposed transformation matrices to get your math right.
> There is no such
> thing as
> "row-major matrix" since matrices are
> mathematical entities that have
> nothing to do with storage.
Yes there is, I've just described it above. It's storage that has
nothing to do with it i.e. OpenGL's view of it as 16 numbers, it's
how you construct your mathematical entity, your matrix, that
imposes one view or the other.
You don't construct the mathematical entity of transformation matrices
based on how OpenGL stores matrices. The mathematical definition in
the literature is clear, which is also used in the OpenGL man pages
when talking about transformation matrices.
I know it sucks, but it's just the way it is.
-Gazi
------------------------------------------------------------------------
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
