<p>The velocity vector becomes your forward vector, just normalize it. The up direction doesn't change, use whatever version up the camera usually uses. The last vector (call it the &quot;right hand&quot; vector) is the cross product of up, and forward. Then, do a second cross with the forward vector and the right hand vector to guarantee an orthonormal basis.</p>
<p>The last  bit needed is the translation which will have to come from somewhere.</p>
<p>The exact ordering of all the operations is going to depend on the setup you are using. Is up direction y or z ect.</p>
<p>Once the matrix if formed, find its inverse. (Since you went through the trouble of making sure it is orthonormal, the inverse is equivalent to the transpose.)</p>
<p>This is the new view matrix.</p>
<p>Edit:
When dealing with Azimuth and Elevation you can extract the angles from a vector using the geometric asin and acos functions. For example:</p>
<pre class="lang-cpp prettyprint-override"><code>    vec3d fwd = target_point - camera_point; // generate a vector somehow
    fwd = normalize(fwd); // normalize it
    float azimuth = acos( fwd.x );
    float elevation = asin( fwd.y );  // extract angles
    if( fwd.z &lt; 0 ) { elevation = -elevation; } // fix quadrant based sgn(z)
</code></pre>
<p>The above assumes that z is the up axis, and that azimuth/elevation are given in radians.</p>
<p>Now that the look direction is decided. Save it off to the side, and begin turning the camera. A good approach to turning the camera is to have a &quot;radians per a second&quot; turn rate. Get the time delta between updates from the system. And use those values to compute how much the camera should turn each frame just by computing the total number of radians that is needed for each direction.</p>
<pre class="lang-cpp prettyprint-override"><code>    float time_delta_in_seconds = elapsed_seconds_since_last_frame();
    const float radians_per_second = 0.1; // slowish
    float turn_amount = time_delta_in_seconds * radians_per_second;
    float turn_amount = min(radians_to_turn, turn_amount); // don't overlook
    radians_to_turn -= turn_amount; // update  - converges on zero
</code></pre>
<p>So each frame:</p>
<ol>
<li>update the velocity vector</li>
<li>compute the new camera settings but don't use them, save them</li>
<li>compute your camera turn amount and update the camera with the new values</li>
</ol>
<p>Make the 3 steps independent and the camera will just keep turning, chasing the velocity vector.</p>
<p>Handling user intervention seems self evident, if the user turns the camera disable the auto camera turning. If you want the camera to start turning after some preset amount of time, then just set a timer that enables auto turning and reset it every time the user moves the camera.</p>
<p>While this isn't the best system for auto camera following, it works and should (hopefully) get you going. The camera turning will be very mechanical since the turn rate is fixed. But once its all set its not to hard to add acceleration using the same ideas.</p>
<p>It just occurred to me that this is like 3 separate questions in one, really these should have been asked separately. At any rate, this should help some I hope.</p>

CC BY-SA 4.0
2021-06-15T16:44:10.443Z
Thank you for your response. The issue is I am not sure how to use the View matrix due to the setup of the camera in the framework I am using. In this framework, I can only set the camera's look direction (`look_dir` -- has components `x`, `y`, `z`), the distance (`dis`) from the camera to `look_dir`, `azimuth` and `elevation` manually. In some simple scenarios you can imagine `look_dir` being equivalent to `velocity_vec` but there are two issues with this: 1) I don't want to camera to have a sudden shift like 2) Velocity vector does not always determine where the camera looks.
Amir
CC BY-SA 4.0
2021-06-15T16:49:02.423Z
However, in my case it is okay if `look_dir` becomes equivalent to the velocity vector after some time (say 1 second -- assuming each second has 30 frames or so). However, I am not sure how to update all of the parameters such as `look_dir`, `dis`, `azimuth` and `elevation` given a velocity vector. Maybe I should use the View Matrix in some way for this? I would appreciate if you can help me with this.
Amir
CC BY-SA 4.0
2021-06-15T17:15:57.723Z
Thats the beauty of using a vector and the approach I outlined above. The velocity vector has that info built into it. Once you have the matrix built you can extract all the other information from the matrix itself. (I can add an edit showing that if you need, but I won't probably get to it today sorry)
pmw1234
CC BY-SA 4.0
2021-06-15T17:41:18.550Z
I'd highly appreciate it if you can update your answer and include the new solution. Also, would you mind looking through the comments I posted above that were exchanged with another user before posting your updated solution? I think those comments might also provide you some more information on what I need. Really appreciate it
Amir
CC BY-SA 4.0
2021-06-16T04:24:36.873Z
This documentation for the framework I am using might be helpful as well:
http://www.mujoco.org/book/haptix.html#uiCamera
Amir
CC BY-SA 4.0
2021-06-16T12:10:26.223Z
Thank you so much for the updated answer. I'm not entirely sure what you mean by "disable the auto camera turning" but just to clarify, I am not interacting with the scene visually; I am only using scripting to do everything.
Amir
CC BY-SA 4.0
2021-06-16T13:04:03.923Z
This should translate to scripting.
pmw1234
CC BY-SA 4.0
2021-06-17T03:53:17.200Z
I tried your solution and things seem to work fine. However, I get some weird behavior when I rotate the camera around the scene; at some point the camera's direction starts getting wrong and I'm not sure what is the reason. Just to make sure, `target_point` is where I want the camera to look at and `camera_point` is the current position of the camera, induced by the velocity vector, right?Also,note that MuJoCo uses Z as its up vector.To account for this I didn't change the way I am computing `azimuth` but I replaced `fwd.y` with `fwd.z` for computing elevation and still get the weird behavior
Amir
CC BY-SA 4.0
2021-06-17T11:25:43.010Z
This is most likely the camera crossing an axis from positive to negative (or vica versa) and is what the line "if( fwd.z )..." is dealing with. There was an error in my notes that said y was up, it should have been z is up. Either way, this will be specific to your setup. Just verify that the camera starts looking "the wrong direction" when it crosses an axis, and that will tell you the culprit.
pmw1234
CC BY-SA 4.0
2021-06-17T21:25:48.700Z
Thank you. Apparently changing the condition from `if (fwd.z)` to `if (fwd.y`) and negating `azimuth` in addition to `elevation` solved the issue but why don't you negate `azimuth` in your pseudocode? Also, is `target_point` where I want the camera to look at and `camera_point` the current position of the camera?
Amir
CC BY-SA 4.0
2021-06-17T21:40:39.143Z
I adapted the code from my own polar coordinate camera I must have introduced a bug when writing the pseudocode.  And yes target_point is where you want to look and camera_point is the current camera position. But you could also use the velocity vector in place of the target/camera vector, just be sure to normalize it.
pmw1234
CC BY-SA 4.0
2021-06-24T01:21:53.620Z
After implementing your approach I realized that this approach fails if I move the camera in the scene as suggested [here](https://computergraphics.stackexchange.com/questions/10979/how-to-ensure-that-a-randomly-generated-velocity-vector-moves-the-camera-forward). Here's the challenge: I spawn the camera in a random location in the scene, point the camera to (0, 0, 0) and move the camera "forward" in the direction it is pointing.
Amir
CC BY-SA 4.0
2021-06-24T03:30:06.957Z
This works sometimes but fails completely some other times if the quadrant where the camera is spawned does not meet my assumption on how I should negate `azimuth`. In other words, in some scenarios, `azimuth` should somehow depend on the direction in which the camera is moving. Do you have an idea for what I need to do to fix this issue?
You can read about this issue in the comments under the answer [here](https://computergraphics.stackexchange.com/questions/10979/how-to-ensure-that-a-randomly-generated-velocity-vector-moves-the-camera-forward) as well. I appreciate you for your time
Amir
CC BY-SA 4.0
2021-06-24T11:34:32.703Z
I just sat down with my own version of an azimuth/elevation camera thinking you had run into a bug, but it works flawlessly. I checked all 8 possible combinations along with moving through them. Setting the camera up is a matter of getting the geometry functions associated with the correct axis and then checking the quadrant.
pmw1234
CC BY-SA 4.0
2021-06-24T12:38:00.450Z
Thank you for looking into this. Do you mean simply negating Azimuth would be sufficient if `y` changes sign? Here are some renderings that I have obtained via your solution for calculating Azimuth. 
https://ibb.co/z46q7Q6, 
https://ibb.co/9sbCMXy, 
https://ibb.co/RTKcX88, 
https://ibb.co/59pKmGZ, 
https://ibb.co/yXDMwn5, 
https://ibb.co/25RhYB0, 
https://ibb.co/v1vvj1H, 
https://ibb.co/gvmqC70, 
https://ibb.co/YytQ652, 
https://ibb.co/KDcCgmp
Amir
CC BY-SA 4.0
2021-06-24T12:38:45.850Z
Note that in the first image the camera is located at (2, 0, 0) and points to (0, 0, 0) with Azimuth 180 (from your approach). Moving the camera to the right and left will increase and decrease `y` respectively.  The camera is then moved to a random location in the scene and is moved forward afterwards. As you can see the camera starts looking back after it passes a quadrant.
Amir
CC BY-SA 4.0
2021-06-24T12:40:55.827Z
Here's another set of images. These renderings are completely wrong (except the first two images) as the camera seems to be looking backwards all the time.

https://ibb.co/MsmcJhr, 
https://ibb.co/Ptz4r40, 
https://ibb.co/Bgn10mw, 
https://ibb.co/vky9zHX, 
https://ibb.co/S6xbHVY, 
https://ibb.co/frN39bn, 
https://ibb.co/KDj91VN, 
https://ibb.co/nkhLfF3, 
https://ibb.co/7kFk3GB, 
https://ibb.co/fShv07p
Amir
CC BY-SA 4.0
2021-06-24T23:31:28.747Z
I played with this even more in my code, I even gave it nonsensical setups and it still works fine. Here are a few things to check: acos and asin usually return radians but you listed degree's, make sure that all your angles are using using the same angle measurements. Make sure the vector is normalized if its not then you will get nonsensical results. And, again, make sure the up, forward, and right  are properly associated between the camera and the vectors.
pmw1234
CC BY-SA 4.0
2021-06-24T23:41:37.920Z
Also I just went over the math for this again and this all works out, there is nothing special going on here.
pmw1234
CC BY-SA 4.0
2021-06-11T11:35:50.833Z
2021-06-17T11:22:37.937Z
2021-06-17T11:22:37.937Z
pmw1234
<p>My goal is to update camera parameters given a velocity vector so that the camera points in the direction of the velocity vector. How should one compute the update matrix for the camera parameters?</p>

CC BY-SA 4.0
2021-06-10T22:37:06.127Z
when you say camera points, you mean to change the look at direction to conform with the velocity vector or just the position of the camera?
gallickgunner
CC BY-SA 4.0
2021-06-11T01:06:29.667Z
@gallickgunner Thank you for the question. I meant to say I need both the position and the look direction should conform with the velocity vector
Amir
CC BY-SA 4.0
2021-06-11T03:10:21.520Z
@gallickgunner Let me give you a better picture of what I actually need to do. In the framework I am using I need to set the camera's look direction (`look_dir`), the distance (`dis`) from the camera to `look_dir`, `azimuth` and `elevation` manually. Initially I was thinking I should first compute the rotation matrix replace the camera rotation matrix with the updated one, but it seems that this is not possible and I need to manually compute these camera parameters. I'm not entirely sure how to obtain these parameters starting from a given velocity vector. Do you know how I can do this?
Amir
CC BY-SA 4.0
2021-06-11T05:36:46.647Z
I still don't understand why you want to change the `look_dir` to that of the velocity vector. Also azimuth and elevation, are you using trackball style camera defined using spherical coordinates? A normal camera usually is defined by `side`, `up`, `look_at` and the `position` vectors.  For the camera's position you could do something as simple as divide the velocity vector by 60 if let's say the app is running at 60 FPS then add it to the position, so after 1 complete second it's where it should be. If you wanna change the look_at as well you could lerp between the original and the velocity?
gallickgunner
CC BY-SA 4.0
2021-06-15T17:01:21.753Z
@gallickgunner I'm not sure what the camera type is but it's possible that it's a trackball style camera. What you suggested in terms of dividing the velocity vector by a number and adding it to the previous one is what I am going to use temporarily. However, this only works well if I assume that velocity vector does not rotate the camera and only moves the camera in space. I'm also not entirely sure if this would work for a trackball camera.
Amir
CC BY-SA 4.0
2021-06-15T17:12:01.433Z
Generally speaking, in case velocity vector is responsible to rotate the camera (which is what I need eventually) the camera parameters such as `look_dir`, `dis`, `azimuth` and `elevation` should be somehow computed in another way but I'm not sure how I should do that. Note that I cannot simply divide the velocity vector by 60 and change the parameter `dis` because `dis` takes on a single real value and not `x`, `y` and `z`. How do you think I should change `dis` in the simple, divide-by-60` case?
Amir
CC BY-SA 4.0
2021-06-16T05:36:33.843Z
What is `dis` actually? You wrote it's the distance of the camera to the `look_at` dir but that's not possible, It's a direction vector. I'm guessing it's the distance of the camera to the object being focused at? If so you, you move the camera first, then compute the distance from the new position vector and the position vector of the object/target. Since it's not intuitive to rotate the camera as well, you'll have to give in details what kind of effect do you wanna achieve and calculate rotation w.r.t to that. There is no standard answer to your question, depends on your situation.
gallickgunner
CC BY-SA 4.0
2021-06-16T12:06:12.973Z
@gallickgunner This might be helpful for you to better understand what `dis` is. Sorry that I made it confusing by providing a somewhat misinterpretion of  what `dis` is: http://www.mujoco.org/book/haptix.html#uiCamera
Amir
<3d><transformations><mathematics><camera>
How compute new camera parameters given a velocity vector?
Amir
# How compute new camera parameters given a velocity vector?

(Asked by: username_0 on 2021-06-10)

My goal is to update camera parameters given a velocity vector so that the camera points in the direction of the velocity vector. How should one compute the update matrix for the camera parameters?

**Tags:** 3d, transformations, mathematics, camera

> **Comments:**
> **username_1**: when you say camera points, you mean to change the look at direction to conform with the velocity vector or just the position of the camera?  
> **username_0**: @username_1 Thank you for the question. I meant to say I need both the position and the look direction should conform with the velocity vector  
> **username_0**: @username_1 Let me give you a better picture of what I actually need to do. In the framework I am using I need to set the camera's look direction (`look_dir`), the distance (`dis`) from the camera to `look_dir`, `azimuth` and `elevation` manually. Initially I was thinking I should first compute the rotation matrix replace the camera rotation matrix with the updated one, but it seems that this is not possible and I need to manually compute these camera parameters. I'm not entirely sure how to obtain these parameters starting from a given velocity vector. Do you know how I can do this?  
> **username_1**: I still don't understand why you want to change the `look_dir` to that of the velocity vector. Also azimuth and elevation, are you using trackball style camera defined using spherical coordinates? A normal camera usually is defined by `side`, `up`, `look_at` and the `position` vectors.  For the camera's position you could do something as simple as divide the velocity vector by 60 if let's say the app is running at 60 FPS then add it to the position, so after 1 complete second it's where it should be. If you wanna change the look_at as well you could lerp between the original and the velocity?  
> **username_0**: @username_1 I'm not sure what the camera type is but it's possible that it's a trackball style camera. What you suggested in terms of dividing the velocity vector by a number and adding it to the previous one is what I am going to use temporarily. However, this only works well if I assume that velocity vector does not rotate the camera and only moves the camera in space. I'm also not entirely sure if this would work for a trackball camera.  
> **username_0**: Generally speaking, in case velocity vector is responsible to rotate the camera (which is what I need eventually) the camera parameters such as `look_dir`, `dis`, `azimuth` and `elevation` should be somehow computed in another way but I'm not sure how I should do that. Note that I cannot simply divide the velocity vector by 60 and change the parameter `dis` because `dis` takes on a single real value and not `x`, `y` and `z`. How do you think I should change `dis` in the simple, divide-by-60` case?  
> **username_1**: What is `dis` actually? You wrote it's the distance of the camera to the `look_at` dir but that's not possible, It's a direction vector. I'm guessing it's the distance of the camera to the object being focused at? If so you, you move the camera first, then compute the distance from the new position vector and the position vector of the object/target. Since it's not intuitive to rotate the camera as well, you'll have to give in details what kind of effect do you wanna achieve and calculate rotation w.r.t to that. There is no standard answer to your question, depends on your situation.  
> **username_0**: @username_1 This might be helpful for you to better understand what `dis` is. Sorry that I made it confusing by providing a somewhat misinterpretion of  what `dis` is: http://www.mujoco.org/book/haptix.html#uiCamera  

---

## 1 answers

### Answer by username_2 on 2021-06-11. Score: 1 | Accepted answer

The velocity vector becomes your forward vector, just normalize it. The up direction doesn't change, use whatever version up the camera usually uses. The last vector (call it the "right hand" vector) is the cross product of up, and forward. Then, do a second cross with the forward vector and the right hand vector to guarantee an orthonormal basis.

The last bit needed is the translation which will have to come from somewhere.

The exact ordering of all the operations is going to depend on the setup you are using. Is up direction y or z ect.

Once the matrix if formed, find its inverse. (Since you went through the trouble of making sure it is orthonormal, the inverse is equivalent to the transpose.)

This is the new view matrix.

Edit:
When dealing with Azimuth and Elevation you can extract the angles from a vector using the geometric asin and acos functions. For example:

```cpp
    vec3d fwd = target_point - camera_point; // generate a vector somehow
    fwd = normalize(fwd); // normalize it
    float azimuth = acos( fwd.x );
    float elevation = asin( fwd.y );  // extract angles
    if( fwd.z < 0 ) { elevation = -elevation; } // fix quadrant based sgn(z)

```

The above assumes that z is the up axis, and that azimuth/elevation are given in radians.

Now that the look direction is decided. Save it off to the side, and begin turning the camera. A good approach to turning the camera is to have a "radians per a second" turn rate. Get the time delta between updates from the system. And use those values to compute how much the camera should turn each frame just by computing the total number of radians that is needed for each direction.

```cpp
    float time_delta_in_seconds = elapsed_seconds_since_last_frame();
    const float radians_per_second = 0.1; // slowish
    float turn_amount = time_delta_in_seconds * radians_per_second;
    float turn_amount = min(radians_to_turn, turn_amount); // don't overlook
    radians_to_turn -= turn_amount; // update  - converges on zero

```

So each frame:

1. update the velocity vector
2. compute the new camera settings but don't use them, save them
3. compute your camera turn amount and update the camera with the new values

Make the 3 steps independent and the camera will just keep turning, chasing the velocity vector.

Handling user intervention seems self evident, if the user turns the camera disable the auto camera turning. If you want the camera to start turning after some preset amount of time, then just set a timer that enables auto turning and reset it every time the user moves the camera.

While this isn't the best system for auto camera following, it works and should (hopefully) get you going. The camera turning will be very mechanical since the turn rate is fixed. But once its all set its not to hard to add acceleration using the same ideas.

It just occurred to me that this is like 3 separate questions in one, really these should have been asked separately. At any rate, this should help some I hope.

> **Comments:**
> **username_0**: Thank you for your response. The issue is I am not sure how to use the View matrix due to the setup of the camera in the framework I am using. In this framework, I can only set the camera's look direction (`look_dir` -- has components `x`, `y`, `z`), the distance (`dis`) from the camera to `look_dir`, `azimuth` and `elevation` manually. In some simple scenarios you can imagine `look_dir` being equivalent to `velocity_vec` but there are two issues with this: 1) I don't want to camera to have a sudden shift like 2) Velocity vector does not always determine where the camera looks.  
> **username_0**: However, in my case it is okay if `look_dir` becomes equivalent to the velocity vector after some time (say 1 second -- assuming each second has 30 frames or so). However, I am not sure how to update all of the parameters such as `look_dir`, `dis`, `azimuth` and `elevation` given a velocity vector. Maybe I should use the View Matrix in some way for this? I would appreciate if you can help me with this.  
> **username_2**: Thats the beauty of using a vector and the approach I outlined above. The velocity vector has that info built into it. Once you have the matrix built you can extract all the other information from the matrix itself. (I can add an edit showing that if you need, but I won't probably get to it today sorry)  
> **username_0**: I'd highly appreciate it if you can update your answer and include the new solution. Also, would you mind looking through the comments I posted above that were exchanged with another user before posting your updated solution? I think those comments might also provide you some more information on what I need. Really appreciate it  
> **username_0**: This documentation for the framework I am using might be helpful as well: http://www.mujoco.org/book/haptix.html#uiCamera  
> **username_0**: Thank you so much for the updated answer. I'm not entirely sure what you mean by "disable the auto camera turning" but just to clarify, I am not interacting with the scene visually; I am only using scripting to do everything.  
> **username_2**: This should translate to scripting.  
> **username_0**: I tried your solution and things seem to work fine. However, I get some weird behavior when I rotate the camera around the scene; at some point the camera's direction starts getting wrong and I'm not sure what is the reason. Just to make sure, `target_point` is where I want the camera to look at and `camera_point` is the current position of the camera, induced by the velocity vector, right?Also,note that MuJoCo uses Z as its up vector.To account for this I didn't change the way I am computing `azimuth` but I replaced `fwd.y` with `fwd.z` for computing elevation and still get the weird behavior  
> **username_2**: This is most likely the camera crossing an axis from positive to negative (or vica versa) and is what the line "if( fwd.z )..." is dealing with. There was an error in my notes that said y was up, it should have been z is up. Either way, this will be specific to your setup. Just verify that the camera starts looking "the wrong direction" when it crosses an axis, and that will tell you the culprit.  
> **username_0**: Thank you. Apparently changing the condition from `if (fwd.z)` to `if (fwd.y`) and negating `azimuth` in addition to `elevation` solved the issue but why don't you negate `azimuth` in your pseudocode? Also, is `target_point` where I want the camera to look at and `camera_point` the current position of the camera?  
> **username_2**: I adapted the code from my own polar coordinate camera I must have introduced a bug when writing the pseudocode.  And yes target_point is where you want to look and camera_point is the current camera position. But you could also use the velocity vector in place of the target/camera vector, just be sure to normalize it.  
> **username_0**: After implementing your approach I realized that this approach fails if I move the camera in the scene as suggested [here](https://computergraphics.stackexchange.com/questions/10979/how-to-ensure-that-a-randomly-generated-velocity-vector-moves-the-camera-forward). Here's the challenge: I spawn the camera in a random location in the scene, point the camera to (0, 0, 0) and move the camera "forward" in the direction it is pointing.  
> **username_0**: This works sometimes but fails completely some other times if the quadrant where the camera is spawned does not meet my assumption on how I should negate `azimuth`. In other words, in some scenarios, `azimuth` should somehow depend on the direction in which the camera is moving. Do you have an idea for what I need to do to fix this issue? You can read about this issue in the comments under the answer [here](https://computergraphics.stackexchange.com/questions/10979/how-to-ensure-that-a-randomly-generated-velocity-vector-moves-the-camera-forward) as well. I appreciate you for your time  
> **username_2**: I just sat down with my own version of an azimuth/elevation camera thinking you had run into a bug, but it works flawlessly. I checked all 8 possible combinations along with moving through them. Setting the camera up is a matter of getting the geometry functions associated with the correct axis and then checking the quadrant.  
> **username_0**: Thank you for looking into this. Do you mean simply negating Azimuth would be sufficient if `y` changes sign? Here are some renderings that I have obtained via your solution for calculating Azimuth.  https://ibb.co/z46q7Q6,  https://ibb.co/9sbCMXy,  https://ibb.co/RTKcX88,  https://ibb.co/59pKmGZ,  https://ibb.co/yXDMwn5,  https://ibb.co/25RhYB0,  https://ibb.co/v1vvj1H,  https://ibb.co/gvmqC70,  https://ibb.co/YytQ652,  https://ibb.co/KDcCgmp  
> **username_0**: Note that in the first image the camera is located at (2, 0, 0) and points to (0, 0, 0) with Azimuth 180 (from your approach). Moving the camera to the right and left will increase and decrease `y` respectively.  The camera is then moved to a random location in the scene and is moved forward afterwards. As you can see the camera starts looking back after it passes a quadrant.  
> **username_0**: Here's another set of images. These renderings are completely wrong (except the first two images) as the camera seems to be looking backwards all the time.  https://ibb.co/MsmcJhr,  https://ibb.co/Ptz4r40,  https://ibb.co/Bgn10mw,  https://ibb.co/vky9zHX,  https://ibb.co/S6xbHVY,  https://ibb.co/frN39bn,  https://ibb.co/KDj91VN,  https://ibb.co/nkhLfF3,  https://ibb.co/7kFk3GB,  https://ibb.co/fShv07p  
> **username_2**: I played with this even more in my code, I even gave it nonsensical setups and it still works fine. Here are a few things to check: acos and asin usually return radians but you listed degree's, make sure that all your angles are using using the same angle measurements. Make sure the vector is normalized if its not then you will get nonsensical results. And, again, make sure the up, forward, and right  are properly associated between the camera and the vectors.  
> **username_2**: Also I just went over the math for this again and this all works out, there is nothing special going on here.  

---

