OpenGL Vector (coming from DirectX)
Author
This is not a hard problem to solve but i couldn't find a built in type of vector in OpenGL. In DirectX, there is D3DXVECTOR2 3 and 4. I can define my own, I just wanna make sure I'm not doing something profoundly stupid...
Actually, I might just go ahead and use the one from the PhysX engine actually. Any down side of that?
NxVec3 is looking good
OpenGL is only the counterpart to Direct3D, not the whole DirectX suite, so you will need auxiliary libraries to provide the extra functionality. Using the PhysX vector should work, but you'd need to include the physx header wherever you use the vectors (unless you make a wrapper). Also make sure any matrix implementations you use are in column-vector, not row-vector format.
I personally use the vmath library, it's tiny (almost everything is inside a single header), so you can just plop it in your project. Matrices are in OpenGL native format, which is good. Also it has implicit casting to T* so you can pass one to an opengl function that expects a vector or matrix without casting.
e.g.
Vector3f bork(13.3f,43.1f,32.0f);
glVertex3fv(bork);
I personally use the vmath library, it's tiny (almost everything is inside a single header), so you can just plop it in your project. Matrices are in OpenGL native format, which is good. Also it has implicit casting to T* so you can pass one to an opengl function that expects a vector or matrix without casting.
e.g.
Vector3f bork(13.3f,43.1f,32.0f);
glVertex3fv(bork);
Since you're looking for an OpenGL-compatible math library (or at least appear to be), I'll go ahead and put in a plug for the CML (I'm sure the aforementioned vmath library would be a good choice as well).
Author
thank you guys -- this was one of those things that had me really wondering about opengl haha
i kind of hated DXUT (GLUT rip-off?) but D3DX was nice. this will fill in the gap. having to roll your own all the time has got to be the biggest downer in opengl, but things like this fix it up
for the record, the physx library only has 3d vectors and 3x3 matrices
i kind of hated DXUT (GLUT rip-off?) but D3DX was nice. this will fill in the gap. having to roll your own all the time has got to be the biggest downer in opengl, but things like this fix it up
for the record, the physx library only has 3d vectors and 3x3 matrices
Author
jyk one thing i saw, i might be wrong is that you are using a class for constants and its templated so you can get return value in correct type, but it would be better to you #define i think for compiler reasons. if the compilers smart enough, it should combine all the multiplication, division together into 1 constant but calling from function would probably botch that optimization. both look nice! just what the doctor ordered
Author
i dont see an email for vmath author he has
#define DEG2RAD(x) ((x * M_PI) / 180.0)
but it should be
#define DEG2RAD(x) (((x) * M_PI) / 180.0)
if you put
DEG2RAD(a+b) then it expands to ((a + b * M_PI) /180.0)
:-D
#define DEG2RAD(x) ((x * M_PI) / 180.0)
but it should be
#define DEG2RAD(x) (((x) * M_PI) / 180.0)
if you put
DEG2RAD(a+b) then it expands to ((a + b * M_PI) /180.0)
:-D
Quote:Original post by yoshscout
i dont see an email for vmath author he has
#define DEG2RAD(x) ((x * M_PI) / 180.0)
but it should be
#define DEG2RAD(x) (((x) * M_PI) / 180.0)
if you put
DEG2RAD(a+b) then it expands to ((a + b * M_PI) /180.0)
:-D
Good spotting :)
His mail is listed a level up from the vmath page (http://home.zcu.cz/~bartipan/), probably best if you mail him so you get the credit.
Quote:Original post by yoshscoutHi yoshscout,
jyk one thing i saw, i might be wrong is that you are using a class for constants and its templated so you can get return value in correct type, but it would be better to you #define i think for compiler reasons. if the compilers smart enough, it should combine all the multiplication, division together into 1 constant but calling from function would probably botch that optimization. both look nice! just what the doctor ordered
The conventional wisdom is that, when programming in C++, constants should be favored over #define's.
I'm fairly certain that when presented with an expression such as 3.14159.f / 180.f (or whatever), the compiler will treat the expression as a single constant - there will be no run-time evaluation involved. As for the functions, they are of course all inlined (unless the compiler decides not to inline them for some reason), so there shouldn't be any run-time penalty there either.
Just FYI, we have some forums set up on the CML website. We're always looking for feedback, so please feel free to post this or any other suggestions over there (that way Demian, the other developer on the project, can have a shot at replying as well).
Most people don't know this, but DirectX math works fine with OpenGL. OpenGL takes D3DXVECTORs just like standard C arrays. So all of the following is perfectly valid.
D3DXVECTOR3 my_vector(0.0f, 0.0f, 0.0f);
glcolor3fv(my_vector);
glVertex3fv(my_vector);
glTranslate(my_vector);
etc...
So, unless you really care about being cross-platform, you don't have to roll your own math library for OpenGL.
D3DXVECTOR3 my_vector(0.0f, 0.0f, 0.0f);
glcolor3fv(my_vector);
glVertex3fv(my_vector);
glTranslate(my_vector);
etc...
So, unless you really care about being cross-platform, you don't have to roll your own math library for OpenGL.
Quote:D3DXVECTOR3 my_vector(0.0f, 0.0f, 0.0f);Shouldn't that be:
glcolor3fv(my_vector);
D3DXVECTOR3 my_vector(0.0f, 0.0f, 0.0f); glcolor3fv(&my_vector.x);This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
