Jump to content
  • Advertisement
Sign in to follow this  
0v3rloader

OpenGL Object position & orientation best strategies

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

Hi, I'm designing a class which will form the basis of all scene-related objects like 3d models and lights, for instance, and when complete will offer such functionalities as support for object's position and orientation, a simple event-driven design, among others. In particular, I would like to know what the best way is to go about designing and implementing support for objects' position and orientation. The design I have so far come up with is more or less as follows: - have a 3d vector describing the object's position (_pos) - have another 3d vector describing the object's initial direction (_idir) - have a structure describing the object's rotation in degrees (_rot, which has 3 data members, _rx, _ry, _rz, and a limited set of mostly inlined accessors and mutators) - have a quaternion describing the object's current orientation (_ori) - have a 3d vector describing the object's present direction (_dir), after transformations to orientation are applied - the final orientation quaternion, _ori, would have to be converted to a 4X4 matrix and loaded directly into OpenGL's model view matrix. I'm really not sure about this design, as I've no experience whatsoever developing 3d graphics apps. Do you spot any flaws, logical inconsistencies or have any suggestions? I'm at a loss here and would appreciate feedback from you guys. Thank you for your time. [Edited by - 0v3rloader on July 25, 2007 10:02:14 PM]

Share this post


Link to post
Share on other sites
Advertisement
Maybe it's a bit overkill - eulerian angles work pretty well most of the time and Rotate doesn't need more than a few angles.
Mantaining a separate matrix per node seems useless considering the cost involved.

I general, I've found little pieces of code in which having a quaternion or an explicit matrix is more useful than angles, but this doesn't seem a good rationale to put all this stuff in a scenegraph to me, especially if the scenegraph is meant to be static. In that case consider you won't really transform at runtime - you'll pre-transform at load time so how exactly your scenegraph stores this data isn't really of importance.

For now, I would suggest to keep it easy. Take head, roll, pitch and here you are.

Share this post


Link to post
Share on other sites
You're keeping around a lot of redundant information. Why not simply standardize "initial direction" as +X or -Z or something, and keep around only position and orientation, with orientation expressed in either euler angles or a quaternion or a rotation matrix?

Share this post


Link to post
Share on other sites
Thanks everybody for the input, it is much appreciated! :)

Quote:
Sneftel wrote:
You're keeping around a lot of redundant information. Why not simply standardize "initial direction" as +X or -Z or something, and keep around only position and orientation, with orientation expressed in either euler angles or a quaternion or a rotation matrix?

Because the project I'm working on requires the use of dynamic objects - models and lights - and also I'll need to do some calculations mainly involving objects' direction (like collision detection.)

Quote:
Khrom wrote:
Maybe it's a bit overkill - eulerian angles work pretty well most of the time and Rotate doesn't need more than a few angles.
Mantaining a separate matrix per node seems useless considering the cost involved.

Very much true and actually one of my concerns is the extra processing time cost involved - not so much the additional memory usage, as computers have plenty of it nowadays.

But consider the following. I've found that using my quaternion class to apply rotations to objects, that being 3 quat multiplications and final mul by direction vector (plus class instantiation overheads), is 12% faster on average than calling OpenGL's glTranslatef and glRotatef functions. However, the benchmark I conducted failed to take into account the final calculation of the modelview matrix, though I'm predicting that once it is implemented it will be as fast as calling OGL's set of methods... And the main advantage here is I'll have access to the object's (cached and) updated direction vector, orientation quat and even modelview matrix.

But, still, there's a memory tradeoff involved...

Quote:
(...) especially if the scenegraph is meant to be static.

...which is where it gets complicated, as I'm designing my ad-hoc graphics engine in a way so as to support either static or dynamic objects and to cache as many calculations as possible. This means that, for instance, only one orientation quat and modelview matrix is calculated per transformation.


Having said all that, what do you guys think?

Share this post


Link to post
Share on other sites
I'm not too well versed in these, so I'm probably missing something, but what exactly is the direction vector for? It's just derived from the orientation, is it not? I can see how you might want to cache direction, but the other variables do seem quite redundant. Also, what purpose do the separate initial and current direction serve? Are these variables used by the collision detection for some kind of avoidance algorithm?

All I do in my game is convert the position to a 4-dimensional matrix and multiply it by the orientation quaternion, and with that I have everything I need to represent the object's world transform. I have methods to apply rotation in "axis-angle" but it gets converted to quaternions internally, so that I'm never storing anything except the position vector, orientation quaternion, and cached transform matrix (the last being something I'm contemplating getting rid of, since it's a throwback to the time when I had a hierarchical scene graph which necessitated complicated transform voodoo). Granted, I'm not yet doing any fancy collision beyond sphere-ray tests for picking so I'm sure there's a lot of stuff I'm missing here.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!