   Scenegraph: Should I implement my own matrix operations?
  I'm writing my own scenegraph engine. I know there are good ones out there already, but I feel like my knowledge of OpenGL and 3D concepts in general is severely lacking.My question is should I rely on OpenGL's built-in matrix operations, or should I implement my own? I am going to render scene elements in order of state changes to be the most efficient. Because of this I don't think I can rely on OpenGL's matrix stack, since there may be no spacial relationship between two elements which are going to be rendered in succession other than their location in world-space. Due to this I'm pretty sure that I am forced to calculate each object's world coordinates before rendering it and simply use glLoadMatrix for each object. Is this the wrong thing to do? Thanks.   
  OpenGL's built'in matrix operations are slow because they are not inlined and they use a single global matrix. In a scene graph it makes a lot more sense to have individual pre-calculated matrices for all objects instead of doing glRotate() and glTranslate() every frame.I would suggest coding your own matrix library or use an existing one. Try VMath or D3DXMATRIX.   ;Quote:Original post by deathkrushOpenGL's built'in matrix operations are slow because they are not inlined and they use a single global matrix. In a scene graph it makes a lot more sense to have individual pre-calculated matrices for all objects instead of doing glRotate() and glTranslate() every frame.I would suggest coding your own matrix library or use an existing one. Try VMath or D3DXMATRIX.Thanks for the suggestion. Unfortunately for me I'm not using C++, so VMath isn't gonna cut it :(. Also I'm sticking just to OpenGL, so anything D3D isn't going to work either.   ;  I used Direct3D's matrix class in my OpenGL app, it was working fine, but that was in C++.   ;Quote:Original post by smrThanks for the suggestion. Unfortunately for me I'm not using C++, so VMath isn't gonna cut it :(. Also I'm sticking just to OpenGL, so anything D3D isn't going to work either.So, write your own. It's not really hard to write a matrix class that gets you off the ground and running. It will be harder to write functions to calc the inverse and other things like that, but transformation matrices really aren't so hard (of course, this is after you understand row major/column major, which I didn't. And then I got more confused [smile]).For the basics: addition, multiplication, resetting to identity, rotation matrices, scale matrices, etc, etc (actually, scratch the addition, I don't have that defined for my matrix class and I'm going strong).   ;Quote:Original post by deathkrushOpenGL's built'in matrix operations are slow because they are not inlined and they use a single global matrix. In a scene graph it makes a lot more sense to have individual pre-calculated matrices for all objects instead of doing glRotate() and glTranslate() every frame.Arn't glTranslate and glRotate done on the graphics card if it supports hardware TnL?Also, a lot of objects are not static and require the matrix to be recalculated every frame. So i guess you're right for static objects, but for moving obejcts wouldnt it be better to take full advantage of hardware TnL?;  You need C functions dealing with matrix ops? I happen to be working on a project that accelerates 3D math, written in asm. I think it is pretty cool, but then again, I am a bit biased ;}homepagehttp://simdx86.sourceforge.netsf pagewww.sourceforge.net/projects/simdx86It uses a variety of SIMD instruction sets such as 3DNow! and SSE/SSE2/SSE3 and runs under Win32 and Linux, though it should compile under BSDs as well.It currently needs GCC to build, but if you are using MSVC, I can port the matrix ops for you double time. I am working on MSVC port for the entire project and version 0.4 is almost finished.Check it out sometime, it sounds like the thing you need. Oh, and by the way, you aren't using C++? So there *is* someone other than me who does that ;}If you have any questions of any kind, just drop me an e-mail:baggett.patrick@gmail.comHope it helps   ;Quote:Original post by Anonymous PosterArn't glTranslate and glRotate done on the graphics card if it supports hardware TnL?Also, a lot of objects are not static and require the matrix to be recalculated every frame. So i guess you're right for static objects, but for moving obejcts wouldnt it be better to take full advantage of hardware TnL?glTranslate(), glRotate(), glScale() and glMultMatrix() all use FPU instructions to calculate the matrix, there is no T&L involved (unless you are using a super rare GPU that does those in hardware). If you are lucky OpenGL might even use SSE, but you are completely dependent on the quality of the drivers.The problem is that if you have to calculate lots of matrices this way you will stall the CPU with function calls. Think about it, to perform translate, rotate and scale on an object and save this matrix in you scene graph using OpenGL you have to go through these steps:glPushMatrix() //we don't want to destroy the current transformation matrixglLoadIdentity()glTranslate()glRotate()glScale()glGetFloatfv(GL_MODELVIEW_MATRIX, &object->matrix) //a nasty function that does a VERY LONG switch statementglPopMatrix() //restore the old transformation matrixThat's seven function calls!If you have your own matrix library with inlined functions, optimized for SSE and maybe even with expression templates, you do something like this:object->matrix = Matrix44::Translate() * Matrix44::Rotate() * Matrix44::Scale();This piece of code doesn't even touch the current transformation matrix, so you don't have to use a matrix stack. It's inlined by the compiler, so there is no function call overhead (0 function calls!) and it can even be partially evaluated at compile if the matrix library is using expression templates. That'smiles ahead of what OpenGL built-in stuff can do.   ;  Thx for the info. But what does the T in TnL do then?   ;Quote:Original post by Anonymous PosterThx for the info. But what does the T in TnL do then?I'm pretty sure the T in T&L stands for Matrix * Vector operations for transforming lots of vertices using a single transformation matrix. Nothing new, really. (correct me if I'm wrong)   