Probably mistake in lookat about tinyrenderer

[ssloy]

No, that is not a mistake. The goal is to compute a change of coordinates where the center becomes origin and the eye lies on the z-axis. So we subtract center and not eye.

[wavvs]

@ssloy , Can you explain why other implementations subtract eye instead center? Is it because you have only 1 object on scene?

[ssloy]

@wavvs, can you give me a link to another implementation so I could check it?

[wavvs]

@ssloy, https://github.com/g-truc/glm/blob/aa38362b2c80d099a5e3b1645f7d9b2decf5e4bd/glm/gtc/matrix_transform.inl#L754
https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/gluLookAt.xml
https://www.scratchapixel.com/lessons/mathematics-physics-for-computer-graphics/lookat-function

[ssloy]

@wavvs, thank you. There is no mistake. The difference is I suppose that the object is centered at the origin and the camera is placed at the z-axis facing origin.

The links you gave me suppose the opposite:

Remember that the camera in its default position is assumed to be centred at the origin and aligned along the negative z-axis.

Check the very beginning of their code:

vec<3, T, Q> const f(normalize(center - eye));

Where I do

Vec3f z = (eye-center).normalize();

So at the end it boils down to the same thing.

[wavvs]

They do vec<3, T, Q> const f(normalize(center - eye));, but take negative forward vector Result[0][2] =-f.x;, and you take eye - center and take positive forward vector in right-handed system, so yes, it's the same.
So you place object at the origin of camera space coordinates, not camera itself. Do I understand right?

[ssloy]

Yes, that's right.

[wavvs]

@ssloy, thank you!

[mcejp]

I am also seeing some unexpected camera behavior -- for example, moving the eye further away from center does not zoom the scene out.

[ssloy]

I am also seeing some unexpected camera behavior -- for example, moving the eye further away from center does not zoom the scene out.

It is not a bug, it is a feature. The job of the lookat function is to place the camera at the Oz axis, nothing more (e.g. for a parallel projection).
The actual distance between the origin and the camera is set in the perspective matrix.

[mcejp]

Fair enough, but would you agree that this makes your lookAt different from what is the "usual convention"?

By no means am I trying to say that it is wrong, let alone that you should change anything, I just disagree with your summary that So at the end it boils down to the same thing, which I find quite misleading :-)

In any case, thank you for your great work!

[ssloy]

I am not sure what you mean when you say "the usual convention". If I am not mistaken, the standard gluLookAt() function does not set the perspective projection, you need to call gluPerspective() for that. I emulate exactly this behaviour.

However, yes, indeed, it would make sense to set the object-to-camera distance directly from lookat(), since we have this information. But it is a non-standard behaviour as far as I know :(

[mcejp]

The usual convention (LookAt in GLU & glm) includes translating the scene away from the camera by length(eye - center).
gluPerspective does not even have the camera distance as an argument; disregarding the clipping that we don't care about here, the only input is FOV which would be fixed most of the time. How could the camera position be taken into consideration in gluPerspective?

[ssloy]

Check the code from the guys who define what OpenGL is:
https://www.khronos.org/opengl/wiki/GluLookAt_code, esp the line:
NormalizeVector(forward);

gluPerspective() does not have the camera distance as the argument, however it does have the field of view argument that is equivalent to the distance.

[mcejp]

My bad, it is not length(eye - center) that matters, only eye (e.g. every vertex is pushed away from the camera proportionally to its distance from the eye plane).

I was still not able to figure out how to convert from a conventional (eye, center, FOV°) tuple to (eye', center', factor) that would achieve the same result in Tinyrenderer, but I was able to work around by just including glm and using its implementation of the matrix calculations :-)