Jump to content
  • Advertisement
Sign in to follow this  
yoshscout

OpenGL OpenGL Vector (coming from DirectX)

This topic is 4098 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

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

Share this post


Link to post
Share on other sites
Advertisement
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);

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by 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
Hi yoshscout,

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
D3DXVECTOR3 my_vector(0.0f, 0.0f, 0.0f);

glcolor3fv(my_vector);
Shouldn't that be:
    D3DXVECTOR3 my_vector(0.0f, 0.0f, 0.0f);

glcolor3fv(&my_vector.x);
Or some variation thereof?

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!