eye and center swapped in lookat

[paroj]

if a camera is situated in point e, we want to render in the frame (e, x',y',z') and not (c, x',y',z') as stated here:
https://github.com/ssloy/tinyrenderer/wiki/Lesson-5-Moving-the-camera#let-us-create-our-own-glulookat

As an aftereffect you move to -center instead of -eye as gluLookAt would do:
https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/gluLookAt.xml

But I want to say that this is a really cool and useful lecture that you have put together.

I came up with a similar idea to warm my students up with python and opencv. However, I stopped at flat-shading and thus things are far less impressive - but thats at about 10 lines of python/ opencv:
https://www.rojtberg.net/1709/fast-wire-frame-rendering-with-opencv/

[yms20]

So your course is call 'train construction' and you teach them how to bye a ticket? Pavel Rojtberg <notifications@github.com> schrieb am So., 24. Jan. 2021, 00:23:

…

if a camera is situated in point *e*, we want to render in the frame (*e*, x',y',z') and not (c, x',y',z') as stated here: https://github.com/ssloy/tinyrenderer/wiki/Lesson-5-Moving-the-camera#let-us-create-our-own-glulookat As an aftereffect you move to -center instead of -eye as gluLookAt would do: https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/gluLookAt.xml But I want to say that this is a really cool and useful lecture that you have put together. I came up with a similar idea to warm my students up with python and opencv. However, I stopped at flat-shading and thus things are far less impressive - but thats at about 10 lines of python/ opencv: https://www.rojtberg.net/1709/fast-wire-frame-rendering-with-opencv/ — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#62>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACRBWTHGVHG6FMJVHHKXMLS3NK77ANCNFSM4WQBZPKQ> .

[paroj]

So your course is call 'train construction' and you teach them how to bye a
ticket?

no, it is about computer vision and I teach them how to relate the basic terms to rendering. But great to hear that people care about kids getting a good education!

[yms20]

Having only 2 lessons into the depth of edged wing data structure and the basics of matrix multiplication myself during university I want to apologize for my misleading and provoking assumption. I understand that the mass of interconnected fields of "mathematical craftsmanship' can't be teached in a single course. Therefor I really suggest to reference this tiny render as additional information in every course related to computer graphics. Pavel Rojtberg <notifications@github.com> schrieb am So., 24. Jan. 2021, 00:55:

…

So your course is call 'train construction' and you teach them how to bye a ticket? no, it is about computer vision and I teach them how to relate the basic terms to rendering. But great to hear that people care about kids getting a good education! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#62 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACRBWRAUGQD5GBQXFHF3O3S3NOVJANCNFSM4WQBZPKQ> .

[ssloy]

@paroj I have not looked closely at the issue, but have you seen that my projection matrices are built for a camera situated at the axis z and looking towards origin? That is a bit different from the popular place-the-camera-to-the-origin approach.

[paroj]

I have not looked closely at the projection matrix - it seemed overly simplistic to me though. Still need to read your rationale for it.

Anyway.. this is only about the construction of the view transform, which is independent of how you implement projection. You will even end up with the same matrix if you fix this - you just gain consistency with GL and naming.

[ssloy]

@paroj it is dependent on the way to construct the projection matrix, because for that we need to know where the camera is. As for the consistency, I see your point, but with modern opengl the modelview/projection matrices have disappeared :)

[paroj]

no, this is independent of where the camera is. You simply got the naming when constructing the transformation backwards. Try to do what I suggest and you will see ;)

[paroj]

Just read your camera section:

but have you seen that my projection matrices are built for a camera situated at the axis z and looking towards origin? That is a bit different from the popular place-the-camera-to-the-origin approach.

Actually, your camera is placed at the origin as well. At least if we define the camera as in "the image-plane", which is kept at z=0 for you and at z=f elsewhere, but thats only a minor difference.

When changing c as described here:
https://github.com/ssloy/tinyrenderer/wiki/Lesson-4-Perspective-projection#time-to-work-in-full-3d

you are not moving the camera location, but the focal-length (aka zoom) see "Intrinsic" tab at the bottom of this page:
https://ksimek.github.io/2012/08/22/extrinsic/

[ssloy]

no, this is independent of where the camera is. You simply got the naming when constructing the transformation backwards. Try to do what I suggest and you will see ;)

A pull request is welcome!

[paroj]

which is kept at z=0 for you and at z=f elsewhere, but thats only a minor difference.

ok, I admit I did not full comprehend the consequences of that choice. Thats not a minor difference and it definitely makes thinking about the code hard as I cannot compare with the results of virtually any other renderer out there.

• when I rotate the camera, there is some offset due to the shifted center of rotation
• as you skip the NDC conversion, I might be looking at something behind the camera

#63 has the changes that got me into this. However, it contains a purposeful sign-error to keep the rendering the same.

For now I will continue to make an Ogre3D rendersystem out of this. With that in place I can hopefully pinpoint where the other part of the sign-error comes from.

[ssloy]

Thank you for opening this issue; I'll keep that in mind and if I have a spare time, will try to use standard opengl convention. I am keeping the issue open

[paroj]

ok, Im done hacking this into Ogre:

now I can come back to why things do not work the way they should here..

[dvorontsov]

Hello @ssloy, thank you very much for your informative lectures!

I am going through each lesson carefully myself, and doing my own implementation in code. And I came across this issue as well. I see that your view matrix does not account for camera translation, as its displacing the camera by the center (which is (0, 0, 0) = no displacement), instead of moving the camera along the z-axis.

You can test this by changing the position of the camera and re-running the renderer. Currently its position is at (1, 1, 3). Change it to something like (1, 1, 9). We would expect the camera to be further away from the center and the model to be rendered smaller. But we can see that the change only affected the angle at which we see the render, but not the distance, as the distance stayed unchanged.

You can also verify it by printing ModelView matrix:
0.948683 0.000000 -0.316228 0.000000
-0.095346 0.953463 -0.286039 0.000000
0.301511 0.301511 0.904534 0.000000
0.000000 0.000000 0.000000 1.000000

You can see that the translation component of the matrix is zero, so the camera's distance from the origin stays fixed.

Maybe I am missing something, as I am in the middle of learning this topic, but that is my understanding so far.

[paroj]

You can see that the translation component of the matrix is zero, so the camera's distance from the origin stays fixed.

actually the camera is moving - what you observe is the image plane staying at zero. The difference is subtle if only one object is rendered - see the vertigo effect. Note, the camera definition in this repo is unique, hence you are not looking at a ModelView matrix, but rather a "ModelImagePlane" matrix.