Light source and default camera position different on command line

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Light source and default camera position different on command line

nophead
The default camera position is different in the GUI compared with the command line. I can move the camera but when viewed from the same place in the GUI the lighting is different. It seems to be higher up in the GUI. Why are they different?






_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Light source and default camera position different on command line

kintel
Administrator
Possibly an oversight.
The cmd-line output was created primarily for regression testing purposes against itself, and the camera and 3D scene management hasn’t received a lot of love, as writing this in low-level OpenGL feels wrong and we haven’t found time to choose and tinker with an appropriate higher-level framework.

 -Marius


> On Sep 5, 2018, at 6:20 AM, nop head <[hidden email]> wrote:
>
> The default camera position is different in the GUI compared with the command line. I can move the camera but when viewed from the same place in the GUI the lighting is different. It seems to be higher up in the GUI. Why are they different?
>
> <veroboard.png>
> <veroboard_gui.png>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Light source and default camera position different on command line

nophead
Seems like the GUI should be changed to match the command line. The command line looks towards the first quadrant (x+,y+) the GUI default is towards the third quadrant (x-, y+) which seems like a mistake.

On 5 September 2018 at 14:16, Marius Kintel <[hidden email]> wrote:
Possibly an oversight.
The cmd-line output was created primarily for regression testing purposes against itself, and the camera and 3D scene management hasn’t received a lot of love, as writing this in low-level OpenGL feels wrong and we haven’t found time to choose and tinker with an appropriate higher-level framework.

 -Marius


> On Sep 5, 2018, at 6:20 AM, nop head <[hidden email]> wrote:
>
> The default camera position is different in the GUI compared with the command line. I can move the camera but when viewed from the same place in the GUI the lighting is different. It seems to be higher up in the GUI. Why are they different?
>
> <veroboard.png>
> <veroboard_gui.png>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Light source and default camera position different on command line

nophead
Sorry that should say second quadrant, not third.

On 6 September 2018 at 16:21, nop head <[hidden email]> wrote:
Seems like the GUI should be changed to match the command line. The command line looks towards the first quadrant (x+,y+) the GUI default is towards the third quadrant (x-, y+) which seems like a mistake.

On 5 September 2018 at 14:16, Marius Kintel <[hidden email]> wrote:
Possibly an oversight.
The cmd-line output was created primarily for regression testing purposes against itself, and the camera and 3D scene management hasn’t received a lot of love, as writing this in low-level OpenGL feels wrong and we haven’t found time to choose and tinker with an appropriate higher-level framework.

 -Marius


> On Sep 5, 2018, at 6:20 AM, nop head <[hidden email]> wrote:
>
> The default camera position is different in the GUI compared with the command line. I can move the camera but when viewed from the same place in the GUI the lighting is different. It seems to be higher up in the GUI. Why are they different?
>
> <veroboard.png>
> <veroboard_gui.png>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Light source and default camera position different on command line

nophead
Also it is very close, 140 but the constructor uses 500 which seems a bit far but of course it depends on what size objects people work on. Perhaps reset view should also do view all?

On 6 September 2018 at 16:25, nop head <[hidden email]> wrote:
Sorry that should say second quadrant, not third.

On 6 September 2018 at 16:21, nop head <[hidden email]> wrote:
Seems like the GUI should be changed to match the command line. The command line looks towards the first quadrant (x+,y+) the GUI default is towards the third quadrant (x-, y+) which seems like a mistake.

On 5 September 2018 at 14:16, Marius Kintel <[hidden email]> wrote:
Possibly an oversight.
The cmd-line output was created primarily for regression testing purposes against itself, and the camera and 3D scene management hasn’t received a lot of love, as writing this in low-level OpenGL feels wrong and we haven’t found time to choose and tinker with an appropriate higher-level framework.

 -Marius


> On Sep 5, 2018, at 6:20 AM, nop head <[hidden email]> wrote:
>
> The default camera position is different in the GUI compared with the command line. I can move the camera but when viewed from the same place in the GUI the lighting is different. It seems to be higher up in the GUI. Why are they different?
>
> <veroboard.png>
> <veroboard_gui.png>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Light source and default camera position different on command line

nophead
What I don't understand is why the lighting is different. The light comes from above in the GUI but it seems to be below on the command line.

The lighting seems to be setup here: https://github.com/openscad/openscad/blob/c6a485651fa29f1a878ea454558192492f7467ec/src/GLView.cc#L345 and that is called in OffScreewView here: https://github.com/openscad/openscad/blob/c6a485651fa29f1a878ea454558192492f7467ec/src/OffscreenView.cc#L14

On 6 September 2018 at 16:48, nop head <[hidden email]> wrote:
Also it is very close, 140 but the constructor uses 500 which seems a bit far but of course it depends on what size objects people work on. Perhaps reset view should also do view all?

On 6 September 2018 at 16:25, nop head <[hidden email]> wrote:
Sorry that should say second quadrant, not third.

On 6 September 2018 at 16:21, nop head <[hidden email]> wrote:
Seems like the GUI should be changed to match the command line. The command line looks towards the first quadrant (x+,y+) the GUI default is towards the third quadrant (x-, y+) which seems like a mistake.

On 5 September 2018 at 14:16, Marius Kintel <[hidden email]> wrote:
Possibly an oversight.
The cmd-line output was created primarily for regression testing purposes against itself, and the camera and 3D scene management hasn’t received a lot of love, as writing this in low-level OpenGL feels wrong and we haven’t found time to choose and tinker with an appropriate higher-level framework.

 -Marius


> On Sep 5, 2018, at 6:20 AM, nop head <[hidden email]> wrote:
>
> The default camera position is different in the GUI compared with the command line. I can move the camera but when viewed from the same place in the GUI the lighting is different. It seems to be higher up in the GUI. Why are they different?
>
> <veroboard.png>
> <veroboard_gui.png>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Light source and default camera position different on command line

nophead
It seems to be a difference between the vector camera mode and the gimbal camera mode. If I set the command line to use the gimbal camera with same viewing angle as the vector camera default then I get the same view but lit from above as it is in the GUI.

Why would a gimbal camera pointed in the same direction, at the same distance have different lighting?

On 6 September 2018 at 17:43, nop head <[hidden email]> wrote:
What I don't understand is why the lighting is different. The light comes from above in the GUI but it seems to be below on the command line.

The lighting seems to be setup here: https://github.com/openscad/openscad/blob/c6a485651fa29f1a878ea454558192492f7467ec/src/GLView.cc#L345 and that is called in OffScreewView here: https://github.com/openscad/openscad/blob/c6a485651fa29f1a878ea454558192492f7467ec/src/OffscreenView.cc#L14

On 6 September 2018 at 16:48, nop head <[hidden email]> wrote:
Also it is very close, 140 but the constructor uses 500 which seems a bit far but of course it depends on what size objects people work on. Perhaps reset view should also do view all?

On 6 September 2018 at 16:25, nop head <[hidden email]> wrote:
Sorry that should say second quadrant, not third.

On 6 September 2018 at 16:21, nop head <[hidden email]> wrote:
Seems like the GUI should be changed to match the command line. The command line looks towards the first quadrant (x+,y+) the GUI default is towards the third quadrant (x-, y+) which seems like a mistake.

On 5 September 2018 at 14:16, Marius Kintel <[hidden email]> wrote:
Possibly an oversight.
The cmd-line output was created primarily for regression testing purposes against itself, and the camera and 3D scene management hasn’t received a lot of love, as writing this in low-level OpenGL feels wrong and we haven’t found time to choose and tinker with an appropriate higher-level framework.

 -Marius


> On Sep 5, 2018, at 6:20 AM, nop head <[hidden email]> wrote:
>
> The default camera position is different in the GUI compared with the command line. I can move the camera but when viewed from the same place in the GUI the lighting is different. It seems to be higher up in the GUI. Why are they different?
>
> <veroboard.png>
> <veroboard_gui.png>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org






_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Light source and default camera position different on command line

kintel
Administrator
> On Sep 6, 2018, at 1:58 PM, nop head <[hidden email]> wrote:
>
> Why would a gimbal camera pointed in the same direction, at the same distance have different lighting?
>
I still don’t think this was intentional, so cleaning up and unifying the lighting for the different camera models would be a good step forward.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Light source and default camera position different on command line

nophead
But the lighting code is already the same for both cameras. I don't understand why it comes out different. Are the lighting positions relative to the world or the camera?

On 10 September 2018 at 05:40, Marius Kintel <[hidden email]> wrote:
> On Sep 6, 2018, at 1:58 PM, nop head <[hidden email]> wrote:
>
> Why would a gimbal camera pointed in the same direction, at the same distance have different lighting?
>
I still don’t think this was intentional, so cleaning up and unifying the lighting for the different camera models would be a good step forward.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Light source and default camera position different on command line

kintel
Administrator
> On Sep 10, 2018, at 8:47 AM, nop head <[hidden email]> wrote:
>
> But the lighting code is already the same for both cameras. I don't understand why it comes out different. Are the lighting positions relative to the world or the camera?
>
The two cameras have slightly different ways of managing OpenGL matrices (https://github.com/openscad/openscad/blob/master/src/GLView.cc#L91):
* The gimbal camera sets up the camera parameters in GL_PROJECTION mode, then resets the MODELVIEW matrix and rotates the scene
* The vector camera set up the camera projection in GL_PROJECTION mode, then does a gluLookat().

Without looking at this in great detail, I’d guess that the gimbal mode is messing with stuff it shouldn’t do with the PROJECTION matrix, causing the lights to have different relative directions in gimbal and vector modes.

Setting up OpenGL cameras and lights using these low-level functions can be tricky and is error prone...

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Light source and default camera position different on command line

nophead
From here: https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glLight.xml for GL_POSITION it says "params contains four integer or floating-point values that specify the position of the light in homogeneous object coordinates." and "The position is transformed by the modelview matrix when glLight is called (just as if it were a point), and it is stored in eye coordinates."

glLight is called before the camera is set up so it should be consistent in eye coordinates, i.e. fixed relative to the camera, not the world. This is certainly true in the GUI gimbal mode. When you rotate around the world the light is always coming from over your left shoulder.

Both camera modes call gluLookat(), with the same up vector. In gimbal mode it always looks down the Y axis and then rotates the world. The vector mode just looks along an arbitrary vector. Since the light positions have been previously baked into eye coordinates I don't understand how they end up different in vector mode. They both set up the projection matrix with the same calls, just slightly different parameters. Yes the gimbal mode then messes with the MODELVIEW matrix but we can see that doesn't affect the lighting relative to the camera.
                       
I refactored setupCamera() to use the same code for both cameras:
void GLView::setupCamera()
{
    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    const bool gimbal = cam.type == Camera::CameraType::GIMBAL;
    auto center = gimbal ? Vector3d(0.0,0.0,0.0)                : cam.center;
    auto eye    = gimbal ? Vector3d(0.0, -cam.zoomValue(), 0.0) : cam.eye;
    auto dist   = (center - eye).norm();
    switch (this->cam.projection) {
        case Camera::ProjectionType::PERSPECTIVE: {
            gluPerspective(cam.fov, aspectratio, 0.1*dist, 100*dist);
            break;
        }
        case Camera::ProjectionType::ORTHOGONAL: {
            auto height = dist * tan(cam.fov/2*M_PI/180);
            glOrtho(-height*aspectratio, height*aspectratio,
                    -height, height,
                    -100*dist, +100*dist);
            break;
        }
    }
    Vector3d dir(eye - center);
    Vector3d up(0.0,0.0,1.0);
    if (dir.cross(up).norm() < 0.001) { // View direction is ~parallel with up vector
        up << 0.0,1.0,0.0;
    }

    glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();
    gluLookAt(eye[0], eye[1], eye[2],
              center[0], center[1], center[2],
              up[0], up[1], up[2]);

    if(gimbal) {
        glRotated(cam.object_rot.x(), 1.0, 0.0, 0.0);
        glRotated(cam.object_rot.y(), 0.0, 1.0, 0.0);
        glRotated(cam.object_rot.z(), 0.0, 0.0, 1.0);
    }
}

If the Camera class maintained correct values in object_rot, eye and centre it wouldn't even need a type. The different modes are just different ways of setting those properties.

All the test still pass but the GUI now looks the same as the tests, i.e. lit from below. The difference is the position of glLoadIdentity()relative to gluLookAt(). I think gluLookAt just sets the model view matrix, so calling glLoadIdentity after it erases its effect.

So without really understanding the bug I can fix it by unifying the camera modes. The problem is the lights from below are not ideal. I can probably change the light setup to make the GUI mode the same as it was, but then half the tests will fail.


On 15 September 2018 at 03:20, Marius Kintel <[hidden email]> wrote:
> On Sep 10, 2018, at 8:47 AM, nop head <[hidden email]> wrote:
>
> But the lighting code is already the same for both cameras. I don't understand why it comes out different. Are the lighting positions relative to the world or the camera?
>
The two cameras have slightly different ways of managing OpenGL matrices (https://github.com/openscad/openscad/blob/master/src/GLView.cc#L91):
* The gimbal camera sets up the camera parameters in GL_PROJECTION mode, then resets the MODELVIEW matrix and rotates the scene
* The vector camera set up the camera projection in GL_PROJECTION mode, then does a gluLookat().

Without looking at this in great detail, I’d guess that the gimbal mode is messing with stuff it shouldn’t do with the PROJECTION matrix, causing the lights to have different relative directions in gimbal and vector modes.

Setting up OpenGL cameras and lights using these low-level functions can be tricky and is error prone...

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Light source and default camera position different on command line

nophead
Actually a few of the tests do now fail due to light changes. Those which use use the Gimbal camera mode.

openscad-camrot_camera-tests
Expected image Actual image


1108/1124 Testing: openscad-camrot_camera-tests
1108/1124 Test: openscad-camrot_camera-tests
Command: "C:/msys64/mingw64/bin/python.exe" "C:/msys64/home/ChrisP/openscad/tests/test_cmdline_tool.py" "--comparator=" "-c" "C:/msys64/mingw64/bin/convert.exe" "-s" "png" "-t" "openscad-camrot" "-f" "camera-tests" "C:/msys64/home/ChrisP/openscad/tests/../Release/openscad.exe" "C:/msys64/home/ChrisP/openscad/tests/../testdata/scad/3D/misc/camera-tests.scad" "--imgsize=500,500" "--camera=0,0,0,440,337.5,315,200" "-o"
Directory: C:/msys64/home/ChrisP/openscad/tests
"openscad-camrot_camera-tests" start time: Sep 15 12:23 GMT Daylight Time
Output:

So I think the correct fix is to change the lights so these pass and then regenerate all the test results for the vector camera tests.


On 15 September 2018 at 12:23, nop head <[hidden email]> wrote:
From here: https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glLight.xml for GL_POSITION it says "params contains four integer or floating-point values that specify the position of the light in homogeneous object coordinates." and "The position is transformed by the modelview matrix when glLight is called (just as if it were a point), and it is stored in eye coordinates."

glLight is called before the camera is set up so it should be consistent in eye coordinates, i.e. fixed relative to the camera, not the world. This is certainly true in the GUI gimbal mode. When you rotate around the world the light is always coming from over your left shoulder.

Both camera modes call gluLookat(), with the same up vector. In gimbal mode it always looks down the Y axis and then rotates the world. The vector mode just looks along an arbitrary vector. Since the light positions have been previously baked into eye coordinates I don't understand how they end up different in vector mode. They both set up the projection matrix with the same calls, just slightly different parameters. Yes the gimbal mode then messes with the MODELVIEW matrix but we can see that doesn't affect the lighting relative to the camera.
                       
I refactored setupCamera() to use the same code for both cameras:
void GLView::setupCamera()
{
    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    const bool gimbal = cam.type == Camera::CameraType::GIMBAL;
    auto center = gimbal ? Vector3d(0.0,0.0,0.0)                : cam.center;
    auto eye    = gimbal ? Vector3d(0.0, -cam.zoomValue(), 0.0) : cam.eye;
    auto dist   = (center - eye).norm();
    switch (this->cam.projection) {
        case Camera::ProjectionType::PERSPECTIVE: {
            gluPerspective(cam.fov, aspectratio, 0.1*dist, 100*dist);
            break;
        }
        case Camera::ProjectionType::ORTHOGONAL: {
            auto height = dist * tan(cam.fov/2*M_PI/180);
            glOrtho(-height*aspectratio, height*aspectratio,
                    -height, height,
                    -100*dist, +100*dist);
            break;
        }
    }
    Vector3d dir(eye - center);
    Vector3d up(0.0,0.0,1.0);
    if (dir.cross(up).norm() < 0.001) { // View direction is ~parallel with up vector
        up << 0.0,1.0,0.0;
    }

    glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();
    gluLookAt(eye[0], eye[1], eye[2],
              center[0], center[1], center[2],
              up[0], up[1], up[2]);

    if(gimbal) {
        glRotated(cam.object_rot.x(), 1.0, 0.0, 0.0);
        glRotated(cam.object_rot.y(), 0.0, 1.0, 0.0);
        glRotated(cam.object_rot.z(), 0.0, 0.0, 1.0);
    }
}

If the Camera class maintained correct values in object_rot, eye and centre it wouldn't even need a type. The different modes are just different ways of setting those properties.

All the test still pass but the GUI now looks the same as the tests, i.e. lit from below. The difference is the position of glLoadIdentity()relative to gluLookAt(). I think gluLookAt just sets the model view matrix, so calling glLoadIdentity after it erases its effect.

So without really understanding the bug I can fix it by unifying the camera modes. The problem is the lights from below are not ideal. I can probably change the light setup to make the GUI mode the same as it was, but then half the tests will fail.


On 15 September 2018 at 03:20, Marius Kintel <[hidden email]> wrote:
> On Sep 10, 2018, at 8:47 AM, nop head <[hidden email]> wrote:
>
> But the lighting code is already the same for both cameras. I don't understand why it comes out different. Are the lighting positions relative to the world or the camera?
>
The two cameras have slightly different ways of managing OpenGL matrices (https://github.com/openscad/openscad/blob/master/src/GLView.cc#L91):
* The gimbal camera sets up the camera parameters in GL_PROJECTION mode, then resets the MODELVIEW matrix and rotates the scene
* The vector camera set up the camera projection in GL_PROJECTION mode, then does a gluLookat().

Without looking at this in great detail, I’d guess that the gimbal mode is messing with stuff it shouldn’t do with the PROJECTION matrix, causing the lights to have different relative directions in gimbal and vector modes.

Setting up OpenGL cameras and lights using these low-level functions can be tricky and is error prone...

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Light source and default camera position different on command line

nophead
Changing the lights as follows seems to get back to the original GUI lighting.

-  GLfloat light_position0[] = {-1.0, -1.0, +1.0, 0.0};
-  GLfloat light_position1[] = {+1.0, +1.0, -1.0, 0.0};
+  GLfloat light_position0[] = {+1.0, -1.0, -1.0, 0.0};
+  GLfloat light_position1[] = {-1.0, +1.0, +1.0, 0.0};

Had to change the sign of both X and Z, which I think means its rotated 180 around the Y axis. I have no idea why this is needed.

The few tests that failed now pass and all the vector camera tests fail, about 40% of the total. Is there a quick way of updating all the test images or do I have to manually dig them out and replace them all?

On 15 September 2018 at 12:28, nop head <[hidden email]> wrote:
Actually a few of the tests do now fail due to light changes. Those which use use the Gimbal camera mode.

openscad-camrot_camera-tests
Expected image Actual image


1108/1124 Testing: openscad-camrot_camera-tests
1108/1124 Test: openscad-camrot_camera-tests
Command: "C:/msys64/mingw64/bin/python.exe" "C:/msys64/home/ChrisP/openscad/tests/test_cmdline_tool.py" "--comparator=" "-c" "C:/msys64/mingw64/bin/convert.exe" "-s" "png" "-t" "openscad-camrot" "-f" "camera-tests" "C:/msys64/home/ChrisP/openscad/tests/../Release/openscad.exe" "C:/msys64/home/ChrisP/openscad/tests/../testdata/scad/3D/misc/camera-tests.scad" "--imgsize=500,500" "--camera=0,0,0,440,337.5,315,200" "-o"
Directory: C:/msys64/home/ChrisP/openscad/tests
"openscad-camrot_camera-tests" start time: Sep 15 12:23 GMT Daylight Time
Output:

So I think the correct fix is to change the lights so these pass and then regenerate all the test results for the vector camera tests.


On 15 September 2018 at 12:23, nop head <[hidden email]> wrote:
From here: https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glLight.xml for GL_POSITION it says "params contains four integer or floating-point values that specify the position of the light in homogeneous object coordinates." and "The position is transformed by the modelview matrix when glLight is called (just as if it were a point), and it is stored in eye coordinates."

glLight is called before the camera is set up so it should be consistent in eye coordinates, i.e. fixed relative to the camera, not the world. This is certainly true in the GUI gimbal mode. When you rotate around the world the light is always coming from over your left shoulder.

Both camera modes call gluLookat(), with the same up vector. In gimbal mode it always looks down the Y axis and then rotates the world. The vector mode just looks along an arbitrary vector. Since the light positions have been previously baked into eye coordinates I don't understand how they end up different in vector mode. They both set up the projection matrix with the same calls, just slightly different parameters. Yes the gimbal mode then messes with the MODELVIEW matrix but we can see that doesn't affect the lighting relative to the camera.
                       
I refactored setupCamera() to use the same code for both cameras:
void GLView::setupCamera()
{
    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    const bool gimbal = cam.type == Camera::CameraType::GIMBAL;
    auto center = gimbal ? Vector3d(0.0,0.0,0.0)                : cam.center;
    auto eye    = gimbal ? Vector3d(0.0, -cam.zoomValue(), 0.0) : cam.eye;
    auto dist   = (center - eye).norm();
    switch (this->cam.projection) {
        case Camera::ProjectionType::PERSPECTIVE: {
            gluPerspective(cam.fov, aspectratio, 0.1*dist, 100*dist);
            break;
        }
        case Camera::ProjectionType::ORTHOGONAL: {
            auto height = dist * tan(cam.fov/2*M_PI/180);
            glOrtho(-height*aspectratio, height*aspectratio,
                    -height, height,
                    -100*dist, +100*dist);
            break;
        }
    }
    Vector3d dir(eye - center);
    Vector3d up(0.0,0.0,1.0);
    if (dir.cross(up).norm() < 0.001) { // View direction is ~parallel with up vector
        up << 0.0,1.0,0.0;
    }

    glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();
    gluLookAt(eye[0], eye[1], eye[2],
              center[0], center[1], center[2],
              up[0], up[1], up[2]);

    if(gimbal) {
        glRotated(cam.object_rot.x(), 1.0, 0.0, 0.0);
        glRotated(cam.object_rot.y(), 0.0, 1.0, 0.0);
        glRotated(cam.object_rot.z(), 0.0, 0.0, 1.0);
    }
}

If the Camera class maintained correct values in object_rot, eye and centre it wouldn't even need a type. The different modes are just different ways of setting those properties.

All the test still pass but the GUI now looks the same as the tests, i.e. lit from below. The difference is the position of glLoadIdentity()relative to gluLookAt(). I think gluLookAt just sets the model view matrix, so calling glLoadIdentity after it erases its effect.

So without really understanding the bug I can fix it by unifying the camera modes. The problem is the lights from below are not ideal. I can probably change the light setup to make the GUI mode the same as it was, but then half the tests will fail.


On 15 September 2018 at 03:20, Marius Kintel <[hidden email]> wrote:
> On Sep 10, 2018, at 8:47 AM, nop head <[hidden email]> wrote:
>
> But the lighting code is already the same for both cameras. I don't understand why it comes out different. Are the lighting positions relative to the world or the camera?
>
The two cameras have slightly different ways of managing OpenGL matrices (https://github.com/openscad/openscad/blob/master/src/GLView.cc#L91):
* The gimbal camera sets up the camera parameters in GL_PROJECTION mode, then resets the MODELVIEW matrix and rotates the scene
* The vector camera set up the camera projection in GL_PROJECTION mode, then does a gluLookat().

Without looking at this in great detail, I’d guess that the gimbal mode is messing with stuff it shouldn’t do with the PROJECTION matrix, causing the lights to have different relative directions in gimbal and vector modes.

Setting up OpenGL cameras and lights using these low-level functions can be tricky and is error prone...

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Light source and default camera position different on command line

nophead
An unfortunate side effect of the GUI lighting position is that two faces of cubes in a lot of tests are the same shade. It looks a lot less contrasty.

cgalpngtest_child-tests
Expected image Actual image



It looks a lot less contrasty. To get the same stark contrast as before you have to look from the below.




On 15 September 2018 at 13:18, nop head <[hidden email]> wrote:
Changing the lights as follows seems to get back to the original GUI lighting.

-  GLfloat light_position0[] = {-1.0, -1.0, +1.0, 0.0};
-  GLfloat light_position1[] = {+1.0, +1.0, -1.0, 0.0};
+  GLfloat light_position0[] = {+1.0, -1.0, -1.0, 0.0};
+  GLfloat light_position1[] = {-1.0, +1.0, +1.0, 0.0};

Had to change the sign of both X and Z, which I think means its rotated 180 around the Y axis. I have no idea why this is needed.

The few tests that failed now pass and all the vector camera tests fail, about 40% of the total. Is there a quick way of updating all the test images or do I have to manually dig them out and replace them all?

On 15 September 2018 at 12:28, nop head <[hidden email]> wrote:
Actually a few of the tests do now fail due to light changes. Those which use use the Gimbal camera mode.

openscad-camrot_camera-tests
Expected image Actual image


1108/1124 Testing: openscad-camrot_camera-tests
1108/1124 Test: openscad-camrot_camera-tests
Command: "C:/msys64/mingw64/bin/python.exe" "C:/msys64/home/ChrisP/openscad/tests/test_cmdline_tool.py" "--comparator=" "-c" "C:/msys64/mingw64/bin/convert.exe" "-s" "png" "-t" "openscad-camrot" "-f" "camera-tests" "C:/msys64/home/ChrisP/openscad/tests/../Release/openscad.exe" "C:/msys64/home/ChrisP/openscad/tests/../testdata/scad/3D/misc/camera-tests.scad" "--imgsize=500,500" "--camera=0,0,0,440,337.5,315,200" "-o"
Directory: C:/msys64/home/ChrisP/openscad/tests
"openscad-camrot_camera-tests" start time: Sep 15 12:23 GMT Daylight Time
Output:

So I think the correct fix is to change the lights so these pass and then regenerate all the test results for the vector camera tests.


On 15 September 2018 at 12:23, nop head <[hidden email]> wrote:
From here: https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glLight.xml for GL_POSITION it says "params contains four integer or floating-point values that specify the position of the light in homogeneous object coordinates." and "The position is transformed by the modelview matrix when glLight is called (just as if it were a point), and it is stored in eye coordinates."

glLight is called before the camera is set up so it should be consistent in eye coordinates, i.e. fixed relative to the camera, not the world. This is certainly true in the GUI gimbal mode. When you rotate around the world the light is always coming from over your left shoulder.

Both camera modes call gluLookat(), with the same up vector. In gimbal mode it always looks down the Y axis and then rotates the world. The vector mode just looks along an arbitrary vector. Since the light positions have been previously baked into eye coordinates I don't understand how they end up different in vector mode. They both set up the projection matrix with the same calls, just slightly different parameters. Yes the gimbal mode then messes with the MODELVIEW matrix but we can see that doesn't affect the lighting relative to the camera.
                       
I refactored setupCamera() to use the same code for both cameras:
void GLView::setupCamera()
{
    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    const bool gimbal = cam.type == Camera::CameraType::GIMBAL;
    auto center = gimbal ? Vector3d(0.0,0.0,0.0)                : cam.center;
    auto eye    = gimbal ? Vector3d(0.0, -cam.zoomValue(), 0.0) : cam.eye;
    auto dist   = (center - eye).norm();
    switch (this->cam.projection) {
        case Camera::ProjectionType::PERSPECTIVE: {
            gluPerspective(cam.fov, aspectratio, 0.1*dist, 100*dist);
            break;
        }
        case Camera::ProjectionType::ORTHOGONAL: {
            auto height = dist * tan(cam.fov/2*M_PI/180);
            glOrtho(-height*aspectratio, height*aspectratio,
                    -height, height,
                    -100*dist, +100*dist);
            break;
        }
    }
    Vector3d dir(eye - center);
    Vector3d up(0.0,0.0,1.0);
    if (dir.cross(up).norm() < 0.001) { // View direction is ~parallel with up vector
        up << 0.0,1.0,0.0;
    }

    glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();
    gluLookAt(eye[0], eye[1], eye[2],
              center[0], center[1], center[2],
              up[0], up[1], up[2]);

    if(gimbal) {
        glRotated(cam.object_rot.x(), 1.0, 0.0, 0.0);
        glRotated(cam.object_rot.y(), 0.0, 1.0, 0.0);
        glRotated(cam.object_rot.z(), 0.0, 0.0, 1.0);
    }
}

If the Camera class maintained correct values in object_rot, eye and centre it wouldn't even need a type. The different modes are just different ways of setting those properties.

All the test still pass but the GUI now looks the same as the tests, i.e. lit from below. The difference is the position of glLoadIdentity()relative to gluLookAt(). I think gluLookAt just sets the model view matrix, so calling glLoadIdentity after it erases its effect.

So without really understanding the bug I can fix it by unifying the camera modes. The problem is the lights from below are not ideal. I can probably change the light setup to make the GUI mode the same as it was, but then half the tests will fail.


On 15 September 2018 at 03:20, Marius Kintel <[hidden email]> wrote:
> On Sep 10, 2018, at 8:47 AM, nop head <[hidden email]> wrote:
>
> But the lighting code is already the same for both cameras. I don't understand why it comes out different. Are the lighting positions relative to the world or the camera?
>
The two cameras have slightly different ways of managing OpenGL matrices (https://github.com/openscad/openscad/blob/master/src/GLView.cc#L91):
* The gimbal camera sets up the camera parameters in GL_PROJECTION mode, then resets the MODELVIEW matrix and rotates the scene
* The vector camera set up the camera projection in GL_PROJECTION mode, then does a gluLookat().

Without looking at this in great detail, I’d guess that the gimbal mode is messing with stuff it shouldn’t do with the PROJECTION matrix, causing the lights to have different relative directions in gimbal and vector modes.

Setting up OpenGL cameras and lights using these low-level functions can be tricky and is error prone...

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Light source and default camera position different on command line

kintel
Administrator
In reply to this post by nophead
> On Sep 15, 2018, at 8:18 AM, nop head <[hidden email]> wrote:
>
> The few tests that failed now pass and all the vector camera tests fail, about 40% of the total. Is there a quick way of updating all the test images or do I have to manually dig them out and replace them all?
>
Regenerating failing tests is a necessary evil, and requires some manual review.
..but we can automatically generate these expected files on the cmd-line:

$ TEST_GENERATE=1 ctest -R <test regex>

Some info here, but not too well organized: https://github.com/openscad/openscad/blob/master/doc/testing.txt

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Light source and default camera position different on command line

nophead
Yes I have reviewed them and they all see to just differ in lighting, apart from the few that fail on my machine due to different Z fighting. If I update those for the lighting change then presumably they will fail on somebody else's hardware. Is that OK?

I am thinking the vector mode can only do a subset of the gimbal mode because it can't rotate around Y. If so, to avoid GUI and command line diverging again, we can remove all the vector camera code and just convert command line vector parameters to gimbal parameters.

If we do unify the camera modes we have some decisions to make. As well as lighting differences the default view is at a different angle and distance. The command line looks towards the first quadrant at a shallower angle [70.53, 0, 315]. The GUI looks at the second quadrant with a steeper downwards angle [55, 0, 25] The default distance is 500 on the command line but 140 in the GUI.

I think looking to the first quadrant is more logical, so the azimuth should always be 315. To avoid big changes to the tests I think we should adopt 70 for the altitude. That will make tiny changes to the tests but the lighting means they all need regenerating anyway.

Distance 500 means you can see about +/- 100 in the Y direction. 140 shows about +/- 30. I propose to make the GUI distance 500 to match the command line and the tests. When you reset the view it is better to be able to see more.

Although I have fixed the lighting bug I don't totally understand why. I think when you call gluLookAt with the centre at the origin and the eye on the X axis you will end up with a matrix similar to the identity matrix but with a few different signs. I don't understand how that can change the lighting without altering the view in any other way. If the modelview matrix is different in any way, surely the view should change spatially?



On 16 September 2018 at 00:55, Marius Kintel <[hidden email]> wrote:
> On Sep 15, 2018, at 8:18 AM, nop head <[hidden email]> wrote:
>
> The few tests that failed now pass and all the vector camera tests fail, about 40% of the total. Is there a quick way of updating all the test images or do I have to manually dig them out and replace them all?
>
Regenerating failing tests is a necessary evil, and requires some manual review.
..but we can automatically generate these expected files on the cmd-line:

$ TEST_GENERATE=1 ctest -R <test regex>

Some info here, but not too well organized: https://github.com/openscad/openscad/blob/master/doc/testing.txt

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Light source and default camera position different on command line

nophead
Using the formula here: https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/gluLookAt.xml I hand calculated the modelview matrix to be

1  0  0  0
0  0  1  0
0 -1  0  0
0  0  0  1

Which looks like a 90 degree rotation about X to me. When this is overwritten by the identity matrix how does that affect the lights, which are supposed to be fixed relative to the eye and not the view of the model? It's getting on for 20 years since I last did OpenGL but this is doing my head in.


On 16 September 2018 at 11:00, nop head <[hidden email]> wrote:
Yes I have reviewed them and they all see to just differ in lighting, apart from the few that fail on my machine due to different Z fighting. If I update those for the lighting change then presumably they will fail on somebody else's hardware. Is that OK?

I am thinking the vector mode can only do a subset of the gimbal mode because it can't rotate around Y. If so, to avoid GUI and command line diverging again, we can remove all the vector camera code and just convert command line vector parameters to gimbal parameters.

If we do unify the camera modes we have some decisions to make. As well as lighting differences the default view is at a different angle and distance. The command line looks towards the first quadrant at a shallower angle [70.53, 0, 315]. The GUI looks at the second quadrant with a steeper downwards angle [55, 0, 25] The default distance is 500 on the command line but 140 in the GUI.

I think looking to the first quadrant is more logical, so the azimuth should always be 315. To avoid big changes to the tests I think we should adopt 70 for the altitude. That will make tiny changes to the tests but the lighting means they all need regenerating anyway.

Distance 500 means you can see about +/- 100 in the Y direction. 140 shows about +/- 30. I propose to make the GUI distance 500 to match the command line and the tests. When you reset the view it is better to be able to see more.

Although I have fixed the lighting bug I don't totally understand why. I think when you call gluLookAt with the centre at the origin and the eye on the X axis you will end up with a matrix similar to the identity matrix but with a few different signs. I don't understand how that can change the lighting without altering the view in any other way. If the modelview matrix is different in any way, surely the view should change spatially?



On 16 September 2018 at 00:55, Marius Kintel <[hidden email]> wrote:
> On Sep 15, 2018, at 8:18 AM, nop head <[hidden email]> wrote:
>
> The few tests that failed now pass and all the vector camera tests fail, about 40% of the total. Is there a quick way of updating all the test images or do I have to manually dig them out and replace them all?
>
Regenerating failing tests is a necessary evil, and requires some manual review.
..but we can automatically generate these expected files on the cmd-line:

$ TEST_GENERATE=1 ctest -R <test regex>

Some info here, but not too well organized: https://github.com/openscad/openscad/blob/master/doc/testing.txt

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Light source and default camera position different on command line

nophead
I found that calling glLoadIdentity after gluLookAt does not erase its effect, so I think despite all the documentation on the web saying it just modifies the modelview matrix, it must do something else.

On 16 September 2018 at 11:56, nop head <[hidden email]> wrote:
Using the formula here: https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/gluLookAt.xml I hand calculated the modelview matrix to be

1  0  0  0
0  0  1  0
0 -1  0  0
0  0  0  1

Which looks like a 90 degree rotation about X to me. When this is overwritten by the identity matrix how does that affect the lights, which are supposed to be fixed relative to the eye and not the view of the model? It's getting on for 20 years since I last did OpenGL but this is doing my head in.


On 16 September 2018 at 11:00, nop head <[hidden email]> wrote:
Yes I have reviewed them and they all see to just differ in lighting, apart from the few that fail on my machine due to different Z fighting. If I update those for the lighting change then presumably they will fail on somebody else's hardware. Is that OK?

I am thinking the vector mode can only do a subset of the gimbal mode because it can't rotate around Y. If so, to avoid GUI and command line diverging again, we can remove all the vector camera code and just convert command line vector parameters to gimbal parameters.

If we do unify the camera modes we have some decisions to make. As well as lighting differences the default view is at a different angle and distance. The command line looks towards the first quadrant at a shallower angle [70.53, 0, 315]. The GUI looks at the second quadrant with a steeper downwards angle [55, 0, 25] The default distance is 500 on the command line but 140 in the GUI.

I think looking to the first quadrant is more logical, so the azimuth should always be 315. To avoid big changes to the tests I think we should adopt 70 for the altitude. That will make tiny changes to the tests but the lighting means they all need regenerating anyway.

Distance 500 means you can see about +/- 100 in the Y direction. 140 shows about +/- 30. I propose to make the GUI distance 500 to match the command line and the tests. When you reset the view it is better to be able to see more.

Although I have fixed the lighting bug I don't totally understand why. I think when you call gluLookAt with the centre at the origin and the eye on the X axis you will end up with a matrix similar to the identity matrix but with a few different signs. I don't understand how that can change the lighting without altering the view in any other way. If the modelview matrix is different in any way, surely the view should change spatially?



On 16 September 2018 at 00:55, Marius Kintel <[hidden email]> wrote:
> On Sep 15, 2018, at 8:18 AM, nop head <[hidden email]> wrote:
>
> The few tests that failed now pass and all the vector camera tests fail, about 40% of the total. Is there a quick way of updating all the test images or do I have to manually dig them out and replace them all?
>
Regenerating failing tests is a necessary evil, and requires some manual review.
..but we can automatically generate these expected files on the cmd-line:

$ TEST_GENERATE=1 ctest -R <test regex>

Some info here, but not too well organized: https://github.com/openscad/openscad/blob/master/doc/testing.txt

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Light source and default camera position different on command line

nophead
Eureka. I think gluLookAt actually modifies the current matrix. So when  glMatrixMode(GL_MODELVIEW);  glLoadIdentity(); was after it, it actually modifies the projection matrix because that was selected when the projection was set. Moving it after glLoadIdentity() makes it operate on the modelview matrix instead. That is why the view stays the same and the lighting changes.


On 16 September 2018 at 13:28, nop head <[hidden email]> wrote:
I found that calling glLoadIdentity after gluLookAt does not erase its effect, so I think despite all the documentation on the web saying it just modifies the modelview matrix, it must do something else.

On 16 September 2018 at 11:56, nop head <[hidden email]> wrote:
Using the formula here: https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/gluLookAt.xml I hand calculated the modelview matrix to be

1  0  0  0
0  0  1  0
0 -1  0  0
0  0  0  1

Which looks like a 90 degree rotation about X to me. When this is overwritten by the identity matrix how does that affect the lights, which are supposed to be fixed relative to the eye and not the view of the model? It's getting on for 20 years since I last did OpenGL but this is doing my head in.


On 16 September 2018 at 11:00, nop head <[hidden email]> wrote:
Yes I have reviewed them and they all see to just differ in lighting, apart from the few that fail on my machine due to different Z fighting. If I update those for the lighting change then presumably they will fail on somebody else's hardware. Is that OK?

I am thinking the vector mode can only do a subset of the gimbal mode because it can't rotate around Y. If so, to avoid GUI and command line diverging again, we can remove all the vector camera code and just convert command line vector parameters to gimbal parameters.

If we do unify the camera modes we have some decisions to make. As well as lighting differences the default view is at a different angle and distance. The command line looks towards the first quadrant at a shallower angle [70.53, 0, 315]. The GUI looks at the second quadrant with a steeper downwards angle [55, 0, 25] The default distance is 500 on the command line but 140 in the GUI.

I think looking to the first quadrant is more logical, so the azimuth should always be 315. To avoid big changes to the tests I think we should adopt 70 for the altitude. That will make tiny changes to the tests but the lighting means they all need regenerating anyway.

Distance 500 means you can see about +/- 100 in the Y direction. 140 shows about +/- 30. I propose to make the GUI distance 500 to match the command line and the tests. When you reset the view it is better to be able to see more.

Although I have fixed the lighting bug I don't totally understand why. I think when you call gluLookAt with the centre at the origin and the eye on the X axis you will end up with a matrix similar to the identity matrix but with a few different signs. I don't understand how that can change the lighting without altering the view in any other way. If the modelview matrix is different in any way, surely the view should change spatially?



On 16 September 2018 at 00:55, Marius Kintel <[hidden email]> wrote:
> On Sep 15, 2018, at 8:18 AM, nop head <[hidden email]> wrote:
>
> The few tests that failed now pass and all the vector camera tests fail, about 40% of the total. Is there a quick way of updating all the test images or do I have to manually dig them out and replace them all?
>
Regenerating failing tests is a necessary evil, and requires some manual review.
..but we can automatically generate these expected files on the cmd-line:

$ TEST_GENERATE=1 ctest -R <test regex>

Some info here, but not too well organized: https://github.com/openscad/openscad/blob/master/doc/testing.txt

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Light source and default camera position different on command line

kintel
Administrator

> On Sep 16, 2018, at 8:37 AM, nop head <[hidden email]> wrote:
>
> Eureka. I think gluLookAt actually modifies the current matrix. So when  glMatrixMode(GL_MODELVIEW);  glLoadIdentity(); was after it, it actually modifies the projection matrix because that was selected when the projection was set. Moving it after glLoadIdentity() makes it operate on the modelview matrix instead. That is why the view stays the same and the lighting changes.
>
>
Looks right.
FYI, there is source code: https://cgit.freedesktop.org/mesa/glu/tree/src/libutil/project.c#n108

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
12