I implemented rotation model for earth.  It orbits around me instead it rotates on its center.  Some tutorial explains ordering for model is:  rotation * translation.

I am figuring out but can't find solution yet. It did not work with code because it orbits around me (surface always face me around) instead of rotating its center.

prm.dmProj  = glm::perspective(cam->getFOV(), double(gl.getWidth()) / double(gl.getHeight()), DIST_NEAR, DIST_FAR);
prm.dmView  = glm::transpose(glm::toMat4(prm.crot));

// prm.obj.orot = glm::toMat4(body.getRotation(prm.now));
prm.obj.orot = glm::rotate(mat4d_t(1.0), glm::radians(90.0), vec3d_t(0.0, 1.0, 0.0));
prm.dmWorld = prm.dmView * glm::translate(glm::transpose(prm.obj.orot), prm.obj.cpos);

prm.mvp = mat4f_t(prm.dmProj * prm.dmWorld);

I tried to split dmWorld into dmView and dmModel but it still results the same but earth looks smaller.

prm.dmProj  = glm::perspective(cam->getFOV(), double(gl.getWidth()) / double(gl.getHeight()), DIST_NEAR, DIST_FAR);
prm.dmView  = glm::transpose(glm::toMat4(prm.crot));

// prm.obj.orot = glm::toMat4(body.getRotation(prm.now));
prm.obj.orot = glm::rotate(mat4d_t(1.0), glm::radians(90.0), vec3d_t(0.0, 1.0, 0.0));
prm.dmModel  = glm::translate(glm::transpose(prm.obj.orot), prm.obj.cpos);

prm.mvp = mat4f_t(prm.dmProj * prm.dmView * prm.dmModel);

When I tried to rotate full 360 degrees (on Y axis) several times for flat spinning test but... Everything gradually became flat line when rotates away from earth.  More spinning = more distorted like flat line effect.  After more several times, it became completely horizontal flat line.  I tried to rotate on its X axis and it became vertical flat line against earth on right side.  I tried barrel roll several times and everything became vertical flat circle (line) on my side of me.  Does anyone know any similar problem?

// Free travel mode
// Update current position and orientation (local reference frame)
// Applying angular velocity to rotation quaternion in local space.
//
//      dq/dt = q * w * t/2
//		w = (0, x, y, z)
//
lqrot += lqrot * wv * (dt / 2.0f);
lpos  -= lqrot * tv * dt;

That is my controls from keyboard for angular and travel velocity where prm.crot = lqrot and prm.cpos = lpos,   wv = angular velocity and tv = travel velocity  (6 DoF controls)

1 hour ago, Sword7 said:

Some tutorial explains ordering for model is:  rotation * translation.

That isn't very useful information in isolation because it could be referring to conceptual or multiplication order, and if it's multiplication order the meaning depends on whether row or column vectors are being used. Plus, the order of course depends on what results you're looking for. So I think we'd probably need to see the tutorial itself to comment meaningfully on that.

I'm not sure what some of the variable names mean, so I'm not sure how well I can follow your code.

Does your camera only rotate and not translate? (I ask because it kind of looks like you're building a view matrix using rotation only.)

The model distortion suggests you're doing something incrementally without correction, which your last code snippet suggests is the case. If 'lqrot' is a quaternion, you should normalize it periodically (e.g. once per update) to keep it (near) unit length.

Generally speaking, a simple series of transforms for a single model (excluding scale, since you don't seem to be scaling) looks like this: rotate, then translate, then transform by the view transform, then transform by the projection transform. Assuming column vectors, the order would be:

projection * view * translation * rotation

Obviously some of that might be handled in different places (e.g. in a vertex program), but that's the order conceptually. (If you're using row vectors, the order would be reversed.)

I don't know if any of that will help. If not, maybe you could explain what some of the variables are (or rename them and repost the code) so that it's a little easier to follow.

Oh I forget to normalize lqrot!  I fixed a bug now.  No more 'flat line' distortion!

View frustum is always origin (0, 0, 0) and only rotation and using object positions as relative world space.  That's why eliminates jitters (more accurate).  I am using column vector (majoring).  I am using matrix as ordering:  projection * view (rotation) * translation * rotation.

prm.obj.orot is object rotation
prm.obj.opos is object position
prm.cpos is camera position
prm.crot is camera rotation

Rendering relative to eye eliminates translation. If i am not mistaken, that's why your planet always rotates around the camera, regardless of where you translate it before rotation. Translation information is gone with building the mvp matrix relative to eye and only vertex positions remain, besides the information in the upper left 3*3 part of the mvp matrix. If you find a solution (for example, objects oriented with their rotation axis towards the camera will rotate correctly around that axis), let me know.

If i understood things right, then rendering rte is not meant for distant objects, but to keep very close (decimeters, m or cm close to the camera on an overall scale of millions of meters) things from jittering around, the contrary to distant objects so to say. Maybe drop rendering rte for scenes where things rotate, squash, jump, and flip ...

Valid until correction, of course ?

9 minutes ago, Green_Baron said:

Rendering relative to eye eliminates translation. If i am not mistaken, that's why your planet always rotates around the camera, regardless of where you translate it before rotation. Translation information is gone with building the mvp matrix relative to eye and only vertex positions remain, besides the information in the upper left 3*3 part of the mvp matrix. If you find a solution (for example, objects oriented with their rotation axis towards the camera will rotate correctly around that axis), let me know.

If i understood things right, then rendering rte is not meant for distant objects, but to keep very close (decimeters, m or cm close to the camera on an overall scale of millions of meters) things from jittering around, the contrary to distant objects so to say. Maybe drop rendering rte for scenes where things rotate, squash, jump, and flip ...

Valid until correction, of course ?

Oh!! I got it now.  I did not know that RTE method eliminates translation cause that planet rotates around camera's origin.  Thanks for let me know.  I will use RTW method for outside planets.  I will figure them out.

1 hour ago, Sword7 said:

View frustum is always origin (0, 0, 0) and only rotation and using object positions as relative world space. 

That was the relatively relevant part ...

2 hours ago, Green_Baron said:

That was the relatively relevant part ...

Yeah. Good news!! I finally resolved that object rotation problem.  I moved translation to view matrix and object now rotates on its center! I can now leave RTE method unchanged. I am now working on earth rotation model. I have to fix tile culling due to rotation when I tried to bring camera to ground.

prm.obj.orot = glm::rotate(mat4d_t(1.0), glm::radians(90.0), vec3d_t(0.0, 1.0, 0.0));

prm.dmModel = glm::transpose(prm.obj.orot);
prm.dmView = glm::translate(prm.dmView, prm.obj.cpos);

prm.mvp = mat4f_t(prm.dmProj * prm.dmView * prm.dmModel);

k ... i have no idea how that works ... could you explain further ?

4 minutes ago, Green_Baron said:

k ... i have no idea how that works ... could you explain further ?

I removed translation from model matrix and it now rotates on its center.  I put camera position (translation) into view matrix.  Now model is at its origin and camera now move around it (origin). That resolved rotation problem.