   Scene Graph DOF nodes
  I'm finishing up the new architecture for my 3D engine redesign and am just locking down the last nitty gritty for the scene graph before I finish my UML and start coding.So the only remaining question are my rotation and translation nodes in the scene graph. I am going to have both a 3rd person camera and a FSP style camera.For both the 3rd person camera rotation and between key frame interpolation for model animation I am going to use Quaternions.So I am presented with this over arching design decision, which is how to store the orientation angles. This one question is actually composed of a few smaller problems.One is Quaternions are ill suited for the FPS style camera. So I want a storage format that is cheap to convert to a matrix and a Quaternion.The second is storing orientation as straight Quaternions makes simply adding to an angle from say mouse input more difficult, so I want an easier way to modify the orientation.And the third is, my understand of Quaternions is not shale we say, complete. So for translation, to add velocity to the Quaternions orientation, the equations I found want a vector to be used with the Quatrenions. But a velocity vector contains both direction and speed. And the direction is stored as a euler angle. So how in a Quaternions based system do I add translation information?I have done some reading and pretty much settled on storing the orientation as euler angles. Why? It is very cheap to go from a euler angle to a Quanternion and very easy to modify the angle from input.So any help or thoughts here would be helpful.   
Quote:One is Quaternions are ill suited for the FPS style camera. So I want a storage format that is cheap to convert to a matrix and a Quaternion.Not true; they're perfectly fine for a first-person camera, and they can be fairly cheaply (cheaply enough) converted to any other representation you might want (although generally you won't need to do anything but a matrix conversion). Why do you think they're "ill suited?"Quote:The second is storing orientation as straight Quaternions makes simply adding to an angle from say mouse input more difficult, so I want an easier way to modify the orientation.No it doesn't. You might not be thinking about the problem correctly; how do you envision this to be "difficult?"Quote:And the third is, my understand of Quaternions is not shale we say, complete. So for translation, to add velocity to the Quaternions orientation, the equations I found want a vector to be used with the Quatrenions. But a velocity vector contains both direction and speed. And the direction is stored as a euler angle. So how in a Quaternions based system do I add translation information?I don't really understand this question. A quaternion stores only orientation information (it is basically a compact representation of an axis-angle rotation). It can't store translation. You have to store that separately, and then combine it with the rotation matrix generated from the quaternion when the time comes.Quote:I have done some reading and pretty much settled on storing the orientation as euler angles. Why? It is very cheap to go from a euler angle to a Quanternion and very easy to modify the angle from input.So any help or thoughts here would be helpful.Use Euler angles, or quaternions. Don't bother with both. If you use Euler angles in any way, you are then very easily subject to gimbal lock and no amount of converting things to quaternions will prevent that, so there is really little point. I would advocate not using Euler angles at all and sticking entirely with quaternions, as they are only slightly less compact (four floats instead of three) and have a number of very useful properties that make them a lot easier to work with in an intuitive way than Euler angles.   ;  All my of information on these came from:http://www.gamasutra.com/features/19980703/quaternions_01.htmIn there they said:Quote:Note that I do not recommend using quaternion interpolation for first-person action games since these games typically require instant response to player actions, and SLERP does take time.So storing everything as straight Quaternions say for my camera class. The Quaternion will define the orientation the camera is looking down. So I would convert from my final Quaternion orientation to a rotation matrix. Easy enough. But for flexible velocity I need to be able to affect the velocity (meaning direction and speed). So say I modify the Quaternion based on mouse input. This changes where you are looking. Then I would have something storing their speed along the vector specified by the Quaternion. Now I want to affect that vector with say, gravity. How do I add downward velocity to this system?   ;Quote:In there they said:They're talking about smoothly moving a camera from point A to point B over time, as you might do for a cinematic. I'm not sure what they're on, as by definition this "takes time;" a quaternion-based camera is perfectly able to jump from point A to point B (and orientation A to orientation B) instantaniously.Quote:But for flexible velocity I need to be able to affect the velocity (meaning direction and speed). So say I modify the Quaternion based on mouse input. This changes where you are looking. Then I would have something storing their speed along the vector specified by the Quaternion. Now I want to affect that vector with say, gravity. How do I add downward velocity to this system?Adding "downward velocity" (and in fact, the notion of velocity altogether) is basically entirely an issue of physics simulation and has nothing to do with a camera. Your physics system adjusts the player's velocity and thus, the player's position. The camera (which is concerned only with viewing the world, and nothing else) is then updated so that its new position is the same as the player's new position. This update is handled by your game logic and not by the camera or the physics system. Most likely, the camera's orientation is not affected by this displacement unless you want to confuse or annoy the user.   ;  Why not just use a 4x4 matrix for both translation/rotation, or a vector for translation and a 3x3 matrix for rotation? The memory impact isn't as big as you'd think. Personally, I find them easier than Quaternions, not to mention matrices are about as 'low-level' as one can get with geometric state.   ;  bbaahhh your totally right. And I even knew this and have it in my notes. But i'm too freaking tired and had a brain fart. Thank you for clearing up my stupidity!   ;Quote:Why not just use a 4x4 matrix for both translation/rotation, or a vector for translation and a 3x3 matrix for rotation?You'll lose the ability to interpolate rotations in an elegant fashion, but if you don't need to, that's an option.   ;Quote:Original post by jpetrieQuote:Why not just use a 4x4 matrix for both translation/rotation, or a vector for translation and a 3x3 matrix for rotation?You'll lose the ability to interpolate rotations in an elegant fashion, but if you don't need to, that's an option.Not really - it's a moderately expensive thing to convert a 3x3 rotation matrix to a quat, then slerp it with something else, then convert it back to a matrix, but not an issue if you're only going to be doing it a few times a frame or something.If you're only going to be doing rotation and translation on your entities, you can just store the one 4x4 matrix, and extract the rotation submatrix (upper 3x3) and/or the the translation vector (last column or row, depending on your orientation).Things do get more complicated in heirarchies, but they're still doable.I personally store the contributing components (rotation, translation, scale) independently, and synthesize the matrix per-frame. I haven't found it to be a particularly big deal, even in the context of a real commercial game.   ;Quote:Not really - it's a moderately expensive thing to convert a 3x3 rotation matrix to a quat, then slerp it with something else, then convert it back to a matrix, but not an issue if you're only going to be doing it a few times a frame or something.Oh, of course. That just doesn't fit into my definition of "elegant." :);Quote:Original post by jpetrieQuote:Not really - it's a moderately expensive thing to convert a 3x3 rotation matrix to a quat, then slerp it with something else, then convert it back to a matrix, but not an issue if you're only going to be doing it a few times a frame or something.Oh, of course. That just doesn't fit into my definition of "elegant." :)Ah - I thought you were referring to the quality of the rotation, not the quality of the implementation. :)As far as elegance of implementation, as I mentioned I prefer to keep separate things separate, until they need to be together, which is why I synthesize the matrix.   