<p>Something like this should work:</p>
<pre><code>forward_direction = normalize(-current_cam_pos)
right_direction = (forward_direction.y, -forward_direction.x, 0)
angle = uniform(-pi/4, pi/4)
new_direction = (cos(angle) * forward) + (sin(angle) * right)
new_pos = new_direction * how_far_you_want_to_move
</code></pre>
<p>Some notes:</p>
<ul>
<li>The <code>normalize</code> will blow up due to a division by 0 if your camera position is ever (0,0,0), so you may want to check for that case and use a default direction value instead.</li>
<li>This also gets more complicated if your camera moves in Z: the (y, -x) trick for picking <code>right_direction</code> only works in a 2D plane.</li>
<li>This doesn’t take care of aiming the camera back at the origin, since your sample code doesn’t mention how that works in your system, so after one move you’ll need to re-do that for the <code>forward_direction</code> (or <code>camera_dir</code> in your example) calculation to be correct.</li>
</ul>

CC BY-SA 4.0
2021-06-21T01:44:51.927Z
Thank you so much for your answer; I haven't implemented your solution (will do in 2 days after I come back from a short trip). I just wanted to leave this comment here to let you know that the camera system I am using is a little bit different and I need to compute Azimuth for the new camera look vector (see [this](https://computergraphics.stackexchange.com/questions/10958/how-compute-new-camera-parameters-given-a-velocity-vector) and this is causing some issues
Amir
CC BY-SA 4.0
2021-06-21T01:48:03.360Z
At the beginning the camera is looking at (0, 0, 0) but after I update the camera position with a random velocity vector, I compute Azimuth for `normalize(-new_pos*2 - new_pos)` to ensure the camera looks in the correct direction. However, this causes some issues as I need to flip the sign of Azimuth if the `x` or `y` coordinates of the new camera pos change sign. Although the solution I have implemented as of now is incorrect but I think I'll face the same issue once I implement yours. Do you know how I can adress this?
Amir
CC BY-SA 4.0
2021-06-21T15:01:06.690Z
How are you computing the azimuth? It sounds like you might be using `atan(y / x)` or similar, which does require recovering the quadrant based on the original signs; most languages provide an `atan2(y, x)` function which will do that for you.
Noah Witherspoon
CC BY-SA 4.0
2021-06-22T12:12:11.260Z
I compute Azimuth as suggested in the answer here --> https://computergraphics.stackexchange.com/questions/10958/how-compute-new-camera-parameters-given-a-velocity-vector . Currently I negate Azimuth with the `if` condition in that answer but it doesn't work properly. Do you still think it's because of what you mentioned?
Amir
CC BY-SA 4.0
2021-06-22T14:15:50.170Z
I think the approach in that answer will work if you negate it based on the `y` value rather than `z`—it looks like the author of that was describing a coordinate system where your camera was staying in the XZ plane and Y was up, where in your description above the camera is in the XY plane with Z up.
Noah Witherspoon
CC BY-SA 4.0
2021-06-21T00:18:24.940Z
2021-06-21T00:18:24.940Z
Noah Witherspoon
<p>I spawn a camera in a scene using random coordinates for <code>x</code> and <code>y</code> and setting <code>z=0</code> and orient the camera so that it looks on the point (0, 0, 0). My goal is to move the camera forward using randomly-generated velocity vectors on the ground (so <code>z</code> stays <code>0</code>). I want to ensure that the new position of the camera is within a valid range after moving it forward, defined in degrees with respect to the current focus point/direction. More specifically, the way I determine &quot;valid range&quot; is by ensuring that the new position is within 45 degrees of the old camera's focus point (-45 degrees to the left and +45 degrees to the right). Can someone write a pseudocode on how I can achieve this?</p>
<p>Here's my attempt to do this but this doesn't seem to be the correct way to help me achieve what I want:</p>
<pre><code>camera_dir = (0, 0, 0) - current_cam_pos
while True:
    vel_vec=[uniform(-max_vel, max_vel), uniform(-max_vel, max_vel)] # generate a random velocity vector
    new_pos = camera_dir + vel_vec # compute a new position (and camera direction vector) for the camera
    if (compute_angle(new_pos, camera_dir) &lt; 45 or compute_angle(new_pos, camera_dir) &gt; 315):
        break 
</code></pre>

<3d><2d><camera><physics>
How to ensure that a randomly-generated velocity vector moves the camera forward within a valid arc?
Amir
# How to ensure that a randomly-generated velocity vector moves the camera forward within a valid arc?

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

I spawn a camera in a scene using random coordinates for `x` and `y` and setting `z=0` and orient the camera so that it looks on the point (0, 0, 0). My goal is to move the camera forward using randomly-generated velocity vectors on the ground (so `z` stays `0`). I want to ensure that the new position of the camera is within a valid range after moving it forward, defined in degrees with respect to the current focus point/direction. More specifically, the way I determine "valid range" is by ensuring that the new position is within 45 degrees of the old camera's focus point (-45 degrees to the left and +45 degrees to the right). Can someone write a pseudocode on how I can achieve this?

Here's my attempt to do this but this doesn't seem to be the correct way to help me achieve what I want:

```
camera_dir = (0, 0, 0) - current_cam_pos
while True:
    vel_vec=[uniform(-max_vel, max_vel), uniform(-max_vel, max_vel)] # generate a random velocity vector
    new_pos = camera_dir + vel_vec # compute a new position (and camera direction vector) for the camera
    if (compute_angle(new_pos, camera_dir) < 45 or compute_angle(new_pos, camera_dir) > 315):
        break 

```

**Tags:** 3d, 2d, camera, physics


---

## 1 answers

### Answer by username_1 on 2021-06-21. Score: 1 | Accepted answer

Something like this should work:

```
forward_direction = normalize(-current_cam_pos)
right_direction = (forward_direction.y, -forward_direction.x, 0)
angle = uniform(-pi/4, pi/4)
new_direction = (cos(angle) * forward) + (sin(angle) * right)
new_pos = new_direction * how_far_you_want_to_move

```

Some notes:

* The `normalize` will blow up due to a division by 0 if your camera position is ever (0,0,0), so you may want to check for that case and use a default direction value instead.
* This also gets more complicated if your camera moves in Z: the (y, -x) trick for picking `right_direction` only works in a 2D plane.
* This doesn’t take care of aiming the camera back at the origin, since your sample code doesn’t mention how that works in your system, so after one move you’ll need to re-do that for the `forward_direction` (or `camera_dir` in your example) calculation to be correct.

> **Comments:**
> **username_0**: Thank you so much for your answer; I haven't implemented your solution (will do in 2 days after I come back from a short trip). I just wanted to leave this comment here to let you know that the camera system I am using is a little bit different and I need to compute Azimuth for the new camera look vector (see [this](https://computergraphics.stackexchange.com/questions/10958/how-compute-new-camera-parameters-given-a-velocity-vector) and this is causing some issues  
> **username_0**: At the beginning the camera is looking at (0, 0, 0) but after I update the camera position with a random velocity vector, I compute Azimuth for `normalize(-new_pos*2 - new_pos)` to ensure the camera looks in the correct direction. However, this causes some issues as I need to flip the sign of Azimuth if the `x` or `y` coordinates of the new camera pos change sign. Although the solution I have implemented as of now is incorrect but I think I'll face the same issue once I implement yours. Do you know how I can adress this?  
> **username_1**: How are you computing the azimuth? It sounds like you might be using `atan(y / x)` or similar, which does require recovering the quadrant based on the original signs; most languages provide an `atan2(y, x)` function which will do that for you.  
> **username_0**: I compute Azimuth as suggested in the answer here --> https://computergraphics.stackexchange.com/questions/10958/how-compute-new-camera-parameters-given-a-velocity-vector . Currently I negate Azimuth with the `if` condition in that answer but it doesn't work properly. Do you still think it's because of what you mentioned?  
> **username_1**: I think the approach in that answer will work if you negate it based on the `y` value rather than `z`—it looks like the author of that was describing a coordinate system where your camera was staying in the XZ plane and Y was up, where in your description above the camera is in the XY plane with Z up.  

---

