# How to ensure that a randomly-generated velocity vector moves the camera forward within a valid arc?

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


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.
• 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 and this is causing some issues
– Amir
Jun 21, 2021 at 1:44
• 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
Jun 21, 2021 at 1:48
• 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. Jun 21, 2021 at 15:01
• I compute Azimuth as suggested in the answer here --> computergraphics.stackexchange.com/questions/10958/… . 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
Jun 22, 2021 at 12:12
• 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. Jun 22, 2021 at 14:15