We have solved my problem in another thread but I'm still interested in this approach (and the OpenGL camera in general.)  The code above is implemented as:

			vec3 bdir = normalize(c_mycamera.front - c_mycamera.position);
			bdir.x = bdir.x * 1.2;
			bdir.y = bdir.y * 1.2;
			bdir.z = bdir.z * 1.2;
			vec3 ballpos = c_mycamera.position  +bdir;
			ball = glm::translate (ball, ballpos);

and here's a video with the same wrong unchanged behavior:

https://youtu.be/sA2bWb3SWz8
 

Why is it still rotating with the terrain, can we make this work too?

Thank you,

Josheir

P.S.  I'll add the video of the other working code soon!

Here's the link to a ball that stays in it's position while the terrain below it rotates.

https://www.youtube.com/watch?v=x6ihw1xkW8o

For reference, code of a working orbiting camera.

1.) Initialize camera vectors on setup:

m_target is the position of the ball, translated to for example 0/0/0

m_position is the initial camera position, set to for example m_target - vec3{0,0,5}

glm::vec3 direction{ m_target - m_position };
m_distance = glm::length( m_target - m_position );
m_yaw = glm::degres( std::atan2( -direction.x, direction.z ) );
m_pitch = glm::degrees( std::atan2( direction.y, std::sqrt( ( direction.x * direction.x) + ( direction.y * direction.y ) ) ) );

I use degrees because intuitive and makes more sense on display.

2.) In your render loop, after having processed input:

float yaw{ -glm::radians( m_yaw ) };
float pitch{ -glm::radians( m_pitch ) };
// Calculate the camera position on the sphere around the target
m_position = glm::dvec3{ m_distance * std::sin( yaw ) * std::cos( pitch ),
						 m_distance * std::sin( pitch ),
						-m_distance * std::cos( yaw ) * std::cos( pitch ) };
// Normalization not necessarily needed here. But later when buidling the frustum.
m_front = glm::normalize( m_target - m_position );
// conversion to float because precision isn't needed here
m_viewMatrix = glm::lookAt( glm::vec3{ m_position }, glm::vec3{ m_target }, m_up );
// Also re-calculate the right vector. Normalize for later use
m_right = glm::normalize( glm::cross( m_front, m_up ) );
m_projectionViewMatrix = m_perspectiveProjectionMatrix * m_viewMatrix;

Code for an orbiting camera. Projection matrix is only calculated when viewport or near/far planes change.

If you want to change the distance for example with the mouse wheel, you must recalc it in the loop. You will want to use pitch and yaw from the ball, so that the camera is following it. Also, maybe you will want to limit camera movement to the y/z plane, which should be trivial now that you have read the linear algebra things ?

No guarantee ;-).

Edit: looks like you have deleted the video and thus invalidated my post. The camera in the video was still freely turning and not locked to the ball.

47 minutes ago, Josheir said:

Here's the link to a ball that stays in it's position while the terrain below it rotates.

https://www.youtube.com/watch?v=x6ihw1xkW8o

FYI, that link appears to be wrong.

I just switched it from private to public, tell me if it fails again please.

That's a different video than the one i reacted upon in my post.

Is your problem solved ? Because it seems that it is the camera that stays in position in relation to the terrain and the ball moves around as the camera turns. I thought you wanted the camera moving around the ball. Seems i misunderstood ...

36 minutes ago, Josheir said:

I just switched it from private to public, tell me if it fails again please.

Well, if that's what you were after, then I guess I was wrong all along about what behavior you wanted  I thought at one point you mentioned it was a golf or golf-like game, so I was envisioning a ball that was stationary (like on a tee or whatever) while the camera rotated around it to determine the direction in which it would be hit. In that video though, you basically have first-person controls, with a ball that's being 'carried around', as it were. (It also doesn't look like it's actually centered, but maybe that's incidental.) Anyway, maybe I just misunderstood.

Instead of the camera rotating around, the world just rotates instead.  It is my first project in OpenGL, it's what I envisioned.  Thanks for your help!  Yes, that's my current problem and it's solved.  

Thanks,

Josheir

Thanks for the orbital camera, really great!