Light source and default camera position different on command line
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.1dist, 100dist);
break;
}
case Camera::ProjectionType::ORTHOGONAL: {
auto height = dist * tan(cam.fov/2M_PI/180);
glOrtho(-heightaspectratio, heightaspectratio,
-height, height,
-100dist, +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 marius@kintel.net wrote:
On Sep 10, 2018, at 8:47 AM, nop head nop.head@gmail.com 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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 nop.head@gmail.com 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.1dist, 100dist);
break;
}
case Camera::ProjectionType::ORTHOGONAL: {
auto height = dist * tan(cam.fov/2M_PI/180);
glOrtho(-heightaspectratio, heightaspectratio,
-height, height,
-100dist, +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 marius@kintel.net wrote:
On Sep 10, 2018, at 8:47 AM, nop head nop.head@gmail.com 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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 nop.head@gmail.com 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 nop.head@gmail.com 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.1dist, 100dist);
break;
}
case Camera::ProjectionType::ORTHOGONAL: {
auto height = dist * tan(cam.fov/2M_PI/180);
glOrtho(-heightaspectratio, heightaspectratio,
-height, height,
-100dist, +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 marius@kintel.net wrote:
On Sep 10, 2018, at 8:47 AM, nop head nop.head@gmail.com 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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 nop.head@gmail.com 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 nop.head@gmail.com 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 nop.head@gmail.com 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.1dist, 100dist);
break;
}
case Camera::ProjectionType::ORTHOGONAL: {
auto height = dist * tan(cam.fov/2M_PI/180);
glOrtho(-heightaspectratio, heightaspectratio,
-height, height,
-100dist, +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 marius@kintel.net wrote:
On Sep 10, 2018, at 8:47 AM, nop head nop.head@gmail.com 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Sep 15, 2018, at 8:18 AM, nop head nop.head@gmail.com 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
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 marius@kintel.net wrote:
On Sep 15, 2018, at 8:18 AM, nop head nop.head@gmail.com 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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 nop.head@gmail.com 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 marius@kintel.net wrote:
On Sep 15, 2018, at 8:18 AM, nop head nop.head@gmail.com 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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 nop.head@gmail.com 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 nop.head@gmail.com 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 marius@kintel.net wrote:
On Sep 15, 2018, at 8:18 AM, nop head nop.head@gmail.com 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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 nop.head@gmail.com 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 nop.head@gmail.com wrote:
Using the formula here: https://www.khronos.org/regist
ry/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 nop.head@gmail.com 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 marius@kintel.net wrote:
On Sep 15, 2018, at 8:18 AM, nop head nop.head@gmail.com 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Sep 16, 2018, at 8:37 AM, nop head nop.head@gmail.com 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