Jump to content
  • Advertisement
Sign in to follow this  
vicviper

generic math library

This topic is 4888 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

The math of your game can run indepently from the graphics core (OpenGL,DX)
Only when rendering, you'd need to convert your matrices to the graphics native format ( Col Order for OpenGL, Row order to DX) . Currently, Ogre, Irrlitch and WildMagic support both apis. Those manage matrices with a compressed structure (Quaterions and points) to then transform the matrices to OpenGL or DX core.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by joanusdmentia
Quote:
Original post by Anonymous Poster
Umm you say I am out of base, I think not. However I give you the benefic of the doubt and accept that perhaps I am ignorant of some new development on linear algebra, so I ask you to get me out of my ignorance.
I am an Opengl user since I can remember, and in the last few years I had been forces to work with DirectX, I had to admit directX is not as bad as it has been portrayed to be.
I had never had problem with coordinate system, Opengl and DirectX work as well in a left-handed system as they do in a right-handed system.

The issue is with the fact that DirectX stores its matrices differently to OpenGL. DirectX stores them as row-major and OpenGL as column-major, ie. DirectX matrices are the transpose of OpenGL matrices, and vice-versa. This means that while one is calculating V*M the other has to either calculate M*V or V*M' (with V being treated as a row or column vector as appropriate), and since the later would be pointless they choose the former.


Actually, and I was just corrected on this misunderstanding myself, the matrices in GL vs DX are *NOT* transposes of each other, and are identical save other differences due to other conventions such as bounding planes. This stems from the fact that while GL and D3D use column vectors and row vectors respectively, they also use different conventions for matrix-vector multiplication; GL = M*v=v', D3D = v*M=v', such that matrices are column-major(GL) and row-major(D3D) So, while they do look different on paper, taking the elements of the matrix as a 1-Dimensional array of 16 elements, the matrix will always contain the corresponding data at the same element index, ie- the tx, ty and tz elements will always be at elements 13, 14 and 15 (again, taken as a 1-D array in memory) regardless of whether the matrix is in GL or D3D. You could memcopy one to the other and have the same matrix, no transpose neccesary.

This is an extremely common misconception, I was only corrected earlier this week myself, so don't feel bad.


Quote:
Original post by Anonymous Poster
In 99.99% of the case that this basics data type are converted into classes at best you get 60 to 80% efficiency, because of all of the hidden overhead classes have to go thought in other to keep conformance with the law of algebra. J


There's no law stating that you have to emulate algebra to be a class, although that is the typical implimentation. Take, for example, a vector class. It is perfectly valid to not define the standard mathematical opperators and rather define methods like add(vec3 ret, vec3 lhs, vec3 rhs) or mul(vec3 ret, mat3 lhs, vec3 rhs) for the sake of efficiency. Likewise, theres no law stating that one must conform to C++'s operator behavior, for example: it is not necessary that assignment opperators return their value on the stack after assignment (called pass-through assignment,) which allows code like vec1 = vec2 = vec3 * mat; but 99.9% of the time is not used. Therefore, I define all my assignment operators as void return types and do not allow that type of statement, its bad coding practice anyhow. I also provide for both algebraic and 3-Operand style methods in my math lib, the latter being more performant, the former more convenient. A class implimentation of vectors or other mathimatics need not be 20-40% behind a C-style implimentation, a well-designed class should be little if any less efficitent, say < 5-10%, as it is entirely possible to limit the impact of constructor overhead.

[Edited by - Ravyne on December 5, 2005 4:42:16 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Ravyne
Actually, and I was just corrected on this misunderstanding myself, the matrices in GL vs DX are *NOT* transposes of each other, and are identical save other differences due to other conventions such as bounding planes. This stems from the fact that while GL and D3D use column vectors and row vectors respectively, they also use different conventions for matrix-vector multiplication; GL = M*v=v', D3D = v*M=v', such that matrices are column-major(GL) and row-major(D3D) So, while they do look different on paper, taking the elements of the matrix as a 1-Dimensional array of 16 elements, the matrix will always contain the corresponding data at the same element index, ie- the tx, ty and tz elements will always be at elements 13, 14 and 15 (again, taken as a 1-D array in memory) regardless of whether the matrix is in GL or D3D. You could memcopy one to the other and have the same matrix, no transpose neccesary.

This is an extremely common misconception, I was only corrected earlier this week myself, so don't feel bad.


I stand corrected, and apologies to the anon poster. Hmm, thinking about it that does make sense. The matrix is transposed by the chosen conventions, but transposed again by storage ending up with GL and D3D matrices being the same.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!