Discussion:
[OpenSCAD] Light source and default camera position different on command line
nop head
2018-09-05 10:20:57 UTC
Permalink
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?
Marius Kintel
2018-09-05 13:16:03 UTC
Permalink
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
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
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-06 15:21:27 UTC
Permalink
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.
Post by Marius Kintel
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
Post by nop head
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?
Post by nop head
<veroboard.png>
<veroboard_gui.png>
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-06 15:25:20 UTC
Permalink
Sorry that should say second quadrant, not third.
Post by nop head
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.
Post by Marius Kintel
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
Post by nop head
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?
Post by nop head
<veroboard.png>
<veroboard_gui.png>
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-06 15:48:58 UTC
Permalink
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?
Post by nop head
Sorry that should say second quadrant, not third.
Post by nop head
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.
Post by Marius Kintel
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
Post by nop head
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?
Post by nop head
<veroboard.png>
<veroboard_gui.png>
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-06 16:43:23 UTC
Permalink
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
Post by nop head
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?
Post by nop head
Sorry that should say second quadrant, not third.
Post by nop head
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.
Post by Marius Kintel
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
Post by nop head
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?
Post by nop head
<veroboard.png>
<veroboard_gui.png>
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-06 17:58:40 UTC
Permalink
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?
Post by nop head
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
Post by nop head
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?
Post by nop head
Sorry that should say second quadrant, not third.
Post by nop head
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.
Post by Marius Kintel
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
Post by nop head
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?
Post by nop head
<veroboard.png>
<veroboard_gui.png>
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.ope
nscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Marius Kintel
2018-09-10 04:40:48 UTC
Permalink
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
nop head
2018-09-10 12:47:40 UTC
Permalink
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?
Post by nop head
Post by nop head
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
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Marius Kintel
2018-09-15 02:20:21 UTC
Permalink
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
nop head
2018-09-15 11:23:19 UTC
Permalink
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.
Post by nop head
Post by nop head
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 (
* 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
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-15 11:28:27 UTC
Permalink
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.
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.
void GLView::setupCamera()
{
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
const bool gimbal = cam.type == Camera::CameraType::GIMBAL;
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.
Post by nop head
Post by nop head
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 (
* 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
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-15 12:18:27 UTC
Permalink
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?
Post by nop head
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
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.
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.
void GLView::setupCamera()
{
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
const bool gimbal = cam.type == Camera::CameraType::GIMBAL;
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.
Post by nop head
Post by nop head
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
* 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
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-15 12:34:32 UTC
Permalink
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.
Post by nop head
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?
Post by nop head
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
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.
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.
void GLView::setupCamera()
{
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
const bool gimbal = cam.type == Camera::CameraType::GIMBAL;
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.
Post by nop head
Post by nop head
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
* 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
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-18 07:27:46 UTC
Permalink
Unifying the camera modes has revealed another bug. This test now fails but
the actual image is correct in my opinion.

openscad-camtrans-viewall_camera-tests
Expected image Actual image



It tests the gimbal camera with viewall without auto center, something
that only can happen with the command line. The camera is translated a
long way from the object's center (which is on the origin), mainly in
the X direction and it is looking down the X axis, so most of of that
offset is not apparent.
The viewall logic is that the object should remain visible with any
camera rotation so it needs to view from quiet far away.
It doesn't work with the old code because it uses Camera::center,
which is not set in the gimbal camera unless auto centre is also set
(it always is in the GUI). I.e. that was the bug I fixed recently, but
it only fixed it when auto center is set.

I hacked the GUI to not set autocentre and you can see the distance is
appropriate when the camera is rotated so that the X translation is
visible.
Yes it is a bug. The gimbal camera was lit from above and the vector
camera from below. I will submit a PR soon.
Post by nop head
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.
Lit from below sure seems wrong.
nop head
2018-09-19 11:37:28 UTC
Permalink
I regenerated the test images for the corrected lighting with
TEST_GENERATE=1 and it works for all the tests except this one:

Image tests
openscad-colorscheme-cornfield-alphafail_logo
Expected image Actual image



1090/1124 Testing: openscad-colorscheme-cornfield-alphafail_logo
1090/1124 Test: openscad-colorscheme-cornfield-alphafail_logo
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-colorscheme-cornfield-alphafail" "-f" "logo"
"C:/msys64/home/ChrisP/openscad/tests/../Release/openscad.exe"
"C:/msys64/home/ChrisP/openscad/tests/../examples/Basics/logo.scad"
"--colorscheme=Cornfield" "-o"
Directory: C:/msys64/home/ChrisP/openscad/tests
"openscad-colorscheme-cornfield-alphafail_logo" start time: Sep 19
12:29 GMT Daylight Time
Output:
----------------------------------------------------------
logo
run_test() cmdline:
['C:/msys64/home/ChrisP/openscad/tests/../Release/openscad.exe',
'C:/msys64/home/ChrisP/openscad/tests/../examples/Basics/logo.scad',
'--colorscheme=Cornfield', '-o',
'/home/ChrisP/openscad/tests/openscad-colorscheme-cornfield-alphafail-output/logo-actual.png']
using font directory: C:/msys64/home/ChrisP/openscad/tests/../testdata/ttf
stderr output: ECHO: version = [2018, 8, 22]
Compiling design (CSG Products normalization)...
Normalized CSG tree has 4 elements
Compiling highlights (1 CSG Trees)...

Image comparison cmdline:
["C:/msys64/mingw64/bin/convert.exe"],['C:/msys64/home/ChrisP/openscad/tests/regression/openscad-colorscheme-cornfield-alphafail/logo-expected.png',
'/home/ChrisP/openscad/tests/openscad-colorscheme-cornfield-alphafail-output/logo-actual.png',
'-alpha', 'On', '-compose', 'difference', '-composite', '-threshold',
'10%', '-morphology', 'Erode', 'Square', '-format', '%[fx:w*h*mean]',
'info:']
actual image: /home/ChrisP/openscad/tests/openscad-colorscheme-cornfield-alphafail-output/logo-actual.png

expected image:
C:/msys64/home/ChrisP/openscad/tests/regression/openscad-colorscheme-cornfield-alphafail/logo-expected.png

Image comparison return: 0 output: b'0'

Test time = 0.62 sec
----------------------------------------------------------
Test Failed.
"openscad-colorscheme-cornfield-alphafail_logo" end time: Sep 19 12:29
GMT Daylight Time
"openscad-colorscheme-cornfield-alphafail_logo" time elapsed: 00:00:00
I have copied the file manually as well and compared the files. The
files are identical but the test still fails.
Post by nop head
Unifying the camera modes has revealed another bug. This test now fails
but the actual image is correct in my opinion.
openscad-camtrans-viewall_camera-tests
Expected image Actual image
It tests the gimbal camera with viewall without auto center, something that only can happen with the command line. The camera is translated a long way from the object's center (which is on the origin), mainly in the X direction and it is looking down the X axis, so most of of that offset is not apparent.
The viewall logic is that the object should remain visible with any camera rotation so it needs to view from quiet far away.
It doesn't work with the old code because it uses Camera::center, which is not set in the gimbal camera unless auto centre is also set (it always is in the GUI). I.e. that was the bug I fixed recently, but it only fixed it when auto center is set.
I hacked the GUI to not set autocentre and you can see the distance is appropriate when the camera is rotated so that the X translation is visible.
Yes it is a bug. The gimbal camera was lit from above and the vector
camera from below. I will submit a PR soon.
On 17 September 2018 at 03:52, Jordan Brown <
Post by nop head
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.
Lit from below sure seems wrong.
nop head
2018-09-19 12:38:35 UTC
Permalink
Looking at the difference on Github here:
https://github.com/nophead/openscad/commit/a75d9596ac85d6730a9d1658e76efa4871fa47ec?short_path=d08cf42#diff-7a2e4b520807a0b305be99f2fcb77915
I can see that the original expected result had alpha in it but the file I
have generated does not.
Post by nop head
I regenerated the test images for the corrected lighting with
Image tests
openscad-colorscheme-cornfield-alphafail_logo
Expected image Actual image
1090/1124 Testing: openscad-colorscheme-cornfield-alphafail_logo
1090/1124 Test: openscad-colorscheme-cornfield-alphafail_logo
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-colorscheme-cornfield-alphafail" "-f" "logo" "C:/msys64/home/ChrisP/openscad/tests/../Release/openscad.exe" "C:/msys64/home/ChrisP/openscad/tests/../examples/Basics/logo.scad" "--colorscheme=Cornfield" "-o"
Directory: C:/msys64/home/ChrisP/openscad/tests
"openscad-colorscheme-cornfield-alphafail_logo" start time: Sep 19 12:29 GMT Daylight Time
----------------------------------------------------------
logo
run_test() cmdline: ['C:/msys64/home/ChrisP/openscad/tests/../Release/openscad.exe', 'C:/msys64/home/ChrisP/openscad/tests/../examples/Basics/logo.scad', '--colorscheme=Cornfield', '-o', '/home/ChrisP/openscad/tests/openscad-colorscheme-cornfield-alphafail-output/logo-actual.png']
using font directory: C:/msys64/home/ChrisP/openscad/tests/../testdata/ttf
stderr output: ECHO: version = [2018, 8, 22]
Compiling design (CSG Products normalization)...
Normalized CSG tree has 4 elements
Compiling highlights (1 CSG Trees)...
["C:/msys64/mingw64/bin/convert.exe"],['C:/msys64/home/ChrisP/openscad/tests/regression/openscad-colorscheme-cornfield-alphafail/logo-expected.png', '/home/ChrisP/openscad/tests/openscad-colorscheme-cornfield-alphafail-output/logo-actual.png', '-alpha', 'On', '-compose', 'difference', '-composite', '-threshold', '10%', '-morphology', 'Erode', 'Square', '-format', '%[fx:w*h*mean]', 'info:']
actual image: /home/ChrisP/openscad/tests/openscad-colorscheme-cornfield-alphafail-output/logo-actual.png
expected image: C:/msys64/home/ChrisP/openscad/tests/regression/openscad-colorscheme-cornfield-alphafail/logo-expected.png
Image comparison return: 0 output: b'0'
Test time = 0.62 sec
----------------------------------------------------------
Test Failed.
"openscad-colorscheme-cornfield-alphafail_logo" end time: Sep 19 12:29 GMT Daylight Time
"openscad-colorscheme-cornfield-alphafail_logo" time elapsed: 00:00:00
I have copied the file manually as well and compared the files. The files are identical but the test still fails.
Post by nop head
Unifying the camera modes has revealed another bug. This test now fails
but the actual image is correct in my opinion.
openscad-camtrans-viewall_camera-tests
Expected image Actual image
It tests the gimbal camera with viewall without auto center, something that only can happen with the command line. The camera is translated a long way from the object's center (which is on the origin), mainly in the X direction and it is looking down the X axis, so most of of that offset is not apparent.
The viewall logic is that the object should remain visible with any camera rotation so it needs to view from quiet far away.
It doesn't work with the old code because it uses Camera::center, which is not set in the gimbal camera unless auto centre is also set (it always is in the GUI). I.e. that was the bug I fixed recently, but it only fixed it when auto center is set.
I hacked the GUI to not set autocentre and you can see the distance is appropriate when the camera is rotated so that the X translation is visible.
Yes it is a bug. The gimbal camera was lit from above and the vector
camera from below. I will submit a PR soon.
On 17 September 2018 at 03:52, Jordan Brown <
Post by nop head
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.
Lit from below sure seems wrong.
nop head
2018-09-19 12:52:40 UTC
Permalink
Now I am totally confused. Why would an image generated with the default
Cornfield colorscheme be expected to have a transparent background?

Why, when I changed the expected background to be not transparent, did it
not make the test pass anyway?
Looking at the difference on Github here: https://github.com/nophead/
openscad/commit/a75d9596ac85d6730a9d1658e76efa
4871fa47ec?short_path=d08cf42#diff-7a2e4b520807a0b305be99f2fcb77915 I can
see that the original expected result had alpha in it but the file I have
generated does not.
Post by nop head
I regenerated the test images for the corrected lighting with
Image tests
openscad-colorscheme-cornfield-alphafail_logo
Expected image Actual image
1090/1124 Testing: openscad-colorscheme-cornfield-alphafail_logo
1090/1124 Test: openscad-colorscheme-cornfield-alphafail_logo
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-colorscheme-cornfield-alphafail" "-f" "logo" "C:/msys64/home/ChrisP/openscad/tests/../Release/openscad.exe" "C:/msys64/home/ChrisP/openscad/tests/../examples/Basics/logo.scad" "--colorscheme=Cornfield" "-o"
Directory: C:/msys64/home/ChrisP/openscad/tests
"openscad-colorscheme-cornfield-alphafail_logo" start time: Sep 19 12:29 GMT Daylight Time
----------------------------------------------------------
logo
run_test() cmdline: ['C:/msys64/home/ChrisP/openscad/tests/../Release/openscad.exe', 'C:/msys64/home/ChrisP/openscad/tests/../examples/Basics/logo.scad', '--colorscheme=Cornfield', '-o', '/home/ChrisP/openscad/tests/openscad-colorscheme-cornfield-alphafail-output/logo-actual.png']
using font directory: C:/msys64/home/ChrisP/openscad/tests/../testdata/ttf
stderr output: ECHO: version = [2018, 8, 22]
Compiling design (CSG Products normalization)...
Normalized CSG tree has 4 elements
Compiling highlights (1 CSG Trees)...
["C:/msys64/mingw64/bin/convert.exe"],['C:/msys64/home/ChrisP/openscad/tests/regression/openscad-colorscheme-cornfield-alphafail/logo-expected.png', '/home/ChrisP/openscad/tests/openscad-colorscheme-cornfield-alphafail-output/logo-actual.png', '-alpha', 'On', '-compose', 'difference', '-composite', '-threshold', '10%', '-morphology', 'Erode', 'Square', '-format', '%[fx:w*h*mean]', 'info:']
actual image: /home/ChrisP/openscad/tests/openscad-colorscheme-cornfield-alphafail-output/logo-actual.png
expected image: C:/msys64/home/ChrisP/openscad/tests/regression/openscad-colorscheme-cornfield-alphafail/logo-expected.png
Image comparison return: 0 output: b'0'
Test time = 0.62 sec
----------------------------------------------------------
Test Failed.
"openscad-colorscheme-cornfield-alphafail_logo" end time: Sep 19 12:29 GMT Daylight Time
"openscad-colorscheme-cornfield-alphafail_logo" time elapsed: 00:00:00
I have copied the file manually as well and compared the files. The files are identical but the test still fails.
Post by nop head
Unifying the camera modes has revealed another bug. This test now fails
but the actual image is correct in my opinion.
openscad-camtrans-viewall_camera-tests
Expected image Actual image
It tests the gimbal camera with viewall without auto center, something that only can happen with the command line. The camera is translated a long way from the object's center (which is on the origin), mainly in the X direction and it is looking down the X axis, so most of of that offset is not apparent.
The viewall logic is that the object should remain visible with any camera rotation so it needs to view from quiet far away.
It doesn't work with the old code because it uses Camera::center, which is not set in the gimbal camera unless auto centre is also set (it always is in the GUI). I.e. that was the bug I fixed recently, but it only fixed it when auto center is set.
I hacked the GUI to not set autocentre and you can see the distance is appropriate when the camera is rotated so that the X translation is visible.
Yes it is a bug. The gimbal camera was lit from above and the vector
camera from below. I will submit a PR soon.
On 17 September 2018 at 03:52, Jordan Brown <
Post by nop head
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.
Lit from below sure seems wrong.
Hans L
2018-09-19 20:02:01 UTC
Permalink
This was something I added a while ago when working on the ability to
support transparent backgrounds, which I never completely finished.

The purpose of the test is to verify that the test framework is paying
attention to the alpha channel.
In order to do this, it compares an "expected" image *with* transparency(I
believe I manually generated this image from transparent branch I was
working on), against the actual image which is not expected to have
transparency.
I know it is rather confusing, but the image comparison is expected to
fail, which means it passed the test.

set_property(TEST openscad-colorscheme-cornfield-alphafail_logo PROPERTY
WILL_FAIL TRUE)
See the "WILL_FAIL TRUE" in the test CMakeLists.txt

To keep things simple I would say we can safely comment out this test until
the transparent background work is actually completed.

Hope that makes sense

Hans
Post by nop head
Now I am totally confused. Why would an image generated with the default
Cornfield colorscheme be expected to have a transparent background?
Why, when I changed the expected background to be not transparent, did it
not make the test pass anyway?
Post by nop head
https://github.com/nophead/openscad/commit/a75d9596ac85d6730a9d1658e76efa4871fa47ec?short_path=d08cf42#diff-7a2e4b520807a0b305be99f2fcb77915
I can see that the original expected result had alpha in it but the file I
have generated does not.
Post by nop head
I regenerated the test images for the corrected lighting with
Image tests
openscad-colorscheme-cornfield-alphafail_logo
Expected image Actual image
1090/1124 Testing: openscad-colorscheme-cornfield-alphafail_logo
1090/1124 Test: openscad-colorscheme-cornfield-alphafail_logo
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-colorscheme-cornfield-alphafail" "-f" "logo" "C:/msys64/home/ChrisP/openscad/tests/../Release/openscad.exe" "C:/msys64/home/ChrisP/openscad/tests/../examples/Basics/logo.scad" "--colorscheme=Cornfield" "-o"
Directory: C:/msys64/home/ChrisP/openscad/tests
"openscad-colorscheme-cornfield-alphafail_logo" start time: Sep 19 12:29 GMT Daylight Time
----------------------------------------------------------
logo
run_test() cmdline: ['C:/msys64/home/ChrisP/openscad/tests/../Release/openscad.exe', 'C:/msys64/home/ChrisP/openscad/tests/../examples/Basics/logo.scad', '--colorscheme=Cornfield', '-o', '/home/ChrisP/openscad/tests/openscad-colorscheme-cornfield-alphafail-output/logo-actual.png']
using font directory: C:/msys64/home/ChrisP/openscad/tests/../testdata/ttf
stderr output: ECHO: version = [2018, 8, 22]
Compiling design (CSG Products normalization)...
Normalized CSG tree has 4 elements
Compiling highlights (1 CSG Trees)...
["C:/msys64/mingw64/bin/convert.exe"],['C:/msys64/home/ChrisP/openscad/tests/regression/openscad-colorscheme-cornfield-alphafail/logo-expected.png', '/home/ChrisP/openscad/tests/openscad-colorscheme-cornfield-alphafail-output/logo-actual.png', '-alpha', 'On', '-compose', 'difference', '-composite', '-threshold', '10%', '-morphology', 'Erode', 'Square', '-format', '%[fx:w*h*mean]', 'info:']
actual image: /home/ChrisP/openscad/tests/openscad-colorscheme-cornfield-alphafail-output/logo-actual.png
expected image: C:/msys64/home/ChrisP/openscad/tests/regression/openscad-colorscheme-cornfield-alphafail/logo-expected.png
Image comparison return: 0 output: b'0'
Test time = 0.62 sec
----------------------------------------------------------
Test Failed.
"openscad-colorscheme-cornfield-alphafail_logo" end time: Sep 19 12:29 GMT Daylight Time
"openscad-colorscheme-cornfield-alphafail_logo" time elapsed: 00:00:00
I have copied the file manually as well and compared the files. The files are identical but the test still fails.
Post by nop head
Unifying the camera modes has revealed another bug. This test now fails
but the actual image is correct in my opinion.
openscad-camtrans-viewall_camera-tests
Expected image Actual image
It tests the gimbal camera with viewall without auto center, something that only can happen with the command line. The camera is translated a long way from the object's center (which is on the origin), mainly in the X direction and it is looking down the X axis, so most of of that offset is not apparent.
The viewall logic is that the object should remain visible with any camera rotation so it needs to view from quiet far away.
It doesn't work with the old code because it uses Camera::center, which is not set in the gimbal camera unless auto centre is also set (it always is in the GUI). I.e. that was the bug I fixed recently, but it only fixed it when auto center is set.
I hacked the GUI to not set autocentre and you can see the distance is appropriate when the camera is rotated so that the X translation is visible.
Yes it is a bug. The gimbal camera was lit from above and the vector
camera from below. I will submit a PR soon.
On 17 September 2018 at 03:52, Jordan Brown <
Post by nop head
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.
Lit from below sure seems wrong.
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-20 07:38:15 UTC
Permalink
OK, Thanks. I will comment it out.
Post by Hans L
This was something I added a while ago when working on the ability to
support transparent backgrounds, which I never completely finished.
The purpose of the test is to verify that the test framework is paying
attention to the alpha channel.
In order to do this, it compares an "expected" image *with* transparency(I
believe I manually generated this image from transparent branch I was
working on), against the actual image which is not expected to have
transparency.
I know it is rather confusing, but the image comparison is expected to
fail, which means it passed the test.
set_property(TEST openscad-colorscheme-cornfield-alphafail_logo PROPERTY
WILL_FAIL TRUE)
See the "WILL_FAIL TRUE" in the test CMakeLists.txt
To keep things simple I would say we can safely comment out this test
until the transparent background work is actually completed.
Hope that makes sense
Hans
Post by nop head
Now I am totally confused. Why would an image generated with the default
Cornfield colorscheme be expected to have a transparent background?
Why, when I changed the expected background to be not transparent, did it
not make the test pass anyway?
Looking at the difference on Github here: https://github.com/nophead/
openscad/commit/a75d9596ac85d6730a9d1658e76efa
4871fa47ec?short_path=d08cf42#diff-7a2e4b520807a0b305be99f2fcb77915 I
can see that the original expected result had alpha in it but the file I
have generated does not.
Post by nop head
I regenerated the test images for the corrected lighting with
Image tests
openscad-colorscheme-cornfield-alphafail_logo
Expected image Actual image
1090/1124 Testing: openscad-colorscheme-cornfield-alphafail_logo
1090/1124 Test: openscad-colorscheme-cornfield-alphafail_logo
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-colorscheme-cornfield-alphafail" "-f" "logo" "C:/msys64/home/ChrisP/openscad/tests/../Release/openscad.exe" "C:/msys64/home/ChrisP/openscad/tests/../examples/Basics/logo.scad" "--colorscheme=Cornfield" "-o"
Directory: C:/msys64/home/ChrisP/openscad/tests
"openscad-colorscheme-cornfield-alphafail_logo" start time: Sep 19 12:29 GMT Daylight Time
----------------------------------------------------------
logo
run_test() cmdline: ['C:/msys64/home/ChrisP/openscad/tests/../Release/openscad.exe', 'C:/msys64/home/ChrisP/openscad/tests/../examples/Basics/logo.scad', '--colorscheme=Cornfield', '-o', '/home/ChrisP/openscad/tests/openscad-colorscheme-cornfield-alphafail-output/logo-actual.png']
using font directory: C:/msys64/home/ChrisP/openscad/tests/../testdata/ttf
stderr output: ECHO: version = [2018, 8, 22]
Compiling design (CSG Products normalization)...
Normalized CSG tree has 4 elements
Compiling highlights (1 CSG Trees)...
["C:/msys64/mingw64/bin/convert.exe"],['C:/msys64/home/ChrisP/openscad/tests/regression/openscad-colorscheme-cornfield-alphafail/logo-expected.png', '/home/ChrisP/openscad/tests/openscad-colorscheme-cornfield-alphafail-output/logo-actual.png', '-alpha', 'On', '-compose', 'difference', '-composite', '-threshold', '10%', '-morphology', 'Erode', 'Square', '-format', '%[fx:w*h*mean]', 'info:']
actual image: /home/ChrisP/openscad/tests/openscad-colorscheme-cornfield-alphafail-output/logo-actual.png
expected image: C:/msys64/home/ChrisP/openscad/tests/regression/openscad-colorscheme-cornfield-alphafail/logo-expected.png
Image comparison return: 0 output: b'0'
Test time = 0.62 sec
----------------------------------------------------------
Test Failed.
"openscad-colorscheme-cornfield-alphafail_logo" end time: Sep 19 12:29 GMT Daylight Time
"openscad-colorscheme-cornfield-alphafail_logo" time elapsed: 00:00:00
I have copied the file manually as well and compared the files. The files are identical but the test still fails.
Post by nop head
Unifying the camera modes has revealed another bug. This test now
fails but the actual image is correct in my opinion.
openscad-camtrans-viewall_camera-tests
Expected image Actual image
It tests the gimbal camera with viewall without auto center, something that only can happen with the command line. The camera is translated a long way from the object's center (which is on the origin), mainly in the X direction and it is looking down the X axis, so most of of that offset is not apparent.
The viewall logic is that the object should remain visible with any camera rotation so it needs to view from quiet far away.
It doesn't work with the old code because it uses Camera::center, which is not set in the gimbal camera unless auto centre is also set (it always is in the GUI). I.e. that was the bug I fixed recently, but it only fixed it when auto center is set.
I hacked the GUI to not set autocentre and you can see the distance is appropriate when the camera is rotated so that the X translation is visible.
Yes it is a bug. The gimbal camera was lit from above and the vector
camera from below. I will submit a PR soon.
On 17 September 2018 at 03:52, Jordan Brown <
Post by nop head
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.
Lit from below sure seems wrong.
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-20 08:38:48 UTC
Permalink
I think all normal tests should catch accidental transparency now the test
framework has been updated to check it. This test is actually testing the
test system does that. It isn't testing OpenSCAD because any image that
doesn't match the 'expected' one will pass the test.

All the other tests can generate the expected image but this one can't, so
I have no easy way of making it.
Post by nop head
OK, Thanks. I will comment it out.
I would say that the test has its merits: It should trigger when the
transparency code accidentally makes things transparent that should
not be. The thing is... Testing if it precisely matches the
transparent image is not a good test to see if that happened.
A good test would combine say a purple image with the openscad image
"on top" obscuring all the purple when things are not
transparent.... When you still get the original openscad image, things
are ok. See some purple, things are not ok.
Roger.
--
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
nop head
2018-09-21 14:37:42 UTC
Permalink
I have now unified the camera modes with this PR
https://github.com/openscad/openscad/pull/2491. There is no vector mode any
more, just the option to set it up from vector parameters. It fixes the
lighting bug in vector mode, the view all without auto center bug in gimbal
mode and makes the GUI default view the same as the command line default.

I kept the camera default distance at 140 because although the default was
different for the vector camera it was never used because if you don't
specify a camera it uses viewall and autocenter. 140 is too close for me
but I think all the examples are sized for it.

The default angle is now [70, 0, 315], which is a fraction of a degree
different from the old command line default. It is different from the old
GUI default [55, 0, 25], but more logical if you design in the first
quadrant and it results in you looking towards the best lit side. IIRC it
used to be different in the distant past, or perhaps the lighting was.
nop head
2018-09-22 15:52:09 UTC
Permalink
As there is now no reason to not offer axes, scales and cross-hairs I added
them to the command line and invoked them in some of the camera tests,
expecting them to fail initially. To my surprise they pass, even though the
actual images have axes but the expected don't.

Is there some tolerance to the image comparison that is big enough to not
notice a scaled axis?
Post by nop head
I have now unified the camera modes with this PR
https://github.com/openscad/openscad/pull/2491. There is no vector mode
any more, just the option to set it up from vector parameters. It fixes the
lighting bug in vector mode, the view all without auto center bug in gimbal
mode and makes the GUI default view the same as the command line default.
I kept the camera default distance at 140 because although the default was
different for the vector camera it was never used because if you don't
specify a camera it uses viewall and autocenter. 140 is too close for me
but I think all the examples are sized for it.
The default angle is now [70, 0, 315], which is a fraction of a degree
different from the old command line default. It is different from the old
GUI default [55, 0, 25], but more logical if you design in the first
quadrant and it results in you looking towards the best lit side. IIRC it
used to be different in the distant past, or perhaps the lighting was.
Marius Kintel
2018-09-22 17:02:50 UTC
Permalink
Note that there is a PR open to control some of those view settings as cmd-line arguments. I’m on my phone so I’ll be short, but it shouldn’t be hard to find.

Yes, we have some erosion setting to let small rendering details slip through. It wasn’t int intended to allow such large changes pass by unnoticed though. Ideas are welcome!

-Marius
As there is now no reason to not offer axes, scales and cross-hairs I added them to the command line and invoked them in some of the camera tests, expecting them to fail initially. To my surprise they pass, even though the actual images have axes but the expected don't.
Is there some tolerance to the image comparison that is big enough to not notice a scaled axis?
I have now unified the camera modes with this PR https://github.com/openscad/openscad/pull/2491. There is no vector mode any more, just the option to set it up from vector parameters. It fixes the lighting bug in vector mode, the view all without auto center bug in gimbal mode and makes the GUI default view the same as the command line default.
I kept the camera default distance at 140 because although the default was different for the vector camera it was never used because if you don't specify a camera it uses viewall and autocenter. 140 is too close for me but I think all the examples are sized for it.
The default angle is now [70, 0, 315], which is a fraction of a degree different from the old command line default. It is different from the old GUI default [55, 0, 25], but more logical if you design in the first quadrant and it results in you looking towards the best lit side. IIRC it used to be different in the distant past, or perhaps the lighting was.
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Hans L
2018-09-22 17:28:14 UTC
Permalink
The default imagemagick arguments can be seen here:
https://github.com/openscad/openscad/blob/74078c561afcbaaa98bfecc8efdac805ae74d482/tests/test_cmdline_tool.py#L156

args = [expectedfilename, resultfilename, "-alpha", "On", "-compose",
"difference", "-composite", "-threshold", "10%", "-morphology",
"Erode", "Square", "-format", "%[fx:w*h*mean]", "info:"]

As I understand an exact pixel comparison would be too strict for it
to pass across different platforms due to small variations in the
output of different graphics cards.

There is a threshold for the difference (to allow for slight color
rendering variation between graphics cards?), plus the morphology
erode operation which I think the idea is to ignore possible variation
in aliasing on object borders across graphics cards, but also means
that thin differences like single pixel axes will get eroded away
entirely.
You can try tweaking the imagemagick arguments to maybe find a more
precise comparison method that reduces false negatives/positives
between test server and your dev machine.

Hans
Note that there is a PR open to control some of those view settings as cmd-line arguments. I’m on my phone so I’ll be short, but it shouldn’t be hard to find.
Yes, we have some erosion setting to let small rendering details slip through. It wasn’t int intended to allow such large changes pass by unnoticed though. Ideas are welcome!
-Marius
As there is now no reason to not offer axes, scales and cross-hairs I added them to the command line and invoked them in some of the camera tests, expecting them to fail initially. To my surprise they pass, even though the actual images have axes but the expected don't.
Is there some tolerance to the image comparison that is big enough to not notice a scaled axis?
I have now unified the camera modes with this PR https://github.com/openscad/openscad/pull/2491. There is no vector mode any more, just the option to set it up from vector parameters. It fixes the lighting bug in vector mode, the view all without auto center bug in gimbal mode and makes the GUI default view the same as the command line default.
I kept the camera default distance at 140 because although the default was different for the vector camera it was never used because if you don't specify a camera it uses viewall and autocenter. 140 is too close for me but I think all the examples are sized for it.
The default angle is now [70, 0, 315], which is a fraction of a degree different from the old command line default. It is different from the old GUI default [55, 0, 25], but more logical if you design in the first quadrant and it results in you looking towards the best lit side. IIRC it used to be different in the distant past, or perhaps the lighting was.
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-22 19:00:00 UTC
Permalink
Yes it is the morphology erode that ignores the single pixel axes. If I
remove it all the tests pass except the ones where have turned on axes plus
a couple of 2D images. However I have just re-created all the expected
images 3D for my previous changes so I won't get any aliasing differences.
I can't think how we can both ignore aliasing differences and detect single
pixel axes at the same time.

My previous machine used to anti-alias the preview but this machine
doesn't. Its only option is to use application settings or turn it off,
whereas IIRC on my old machine I could force it on for a specify
application and I think it rendered at higher resolution and downsampled to
get smooth edges. Anybody know an application specifies anti-aliasing?
Post by Hans L
https://github.com/openscad/openscad/blob/74078c561afcbaaa98bfecc8efdac8
05ae74d482/tests/test_cmdline_tool.py#L156
args = [expectedfilename, resultfilename, "-alpha", "On", "-compose",
"difference", "-composite", "-threshold", "10%", "-morphology",
"Erode", "Square", "-format", "%[fx:w*h*mean]", "info:"]
As I understand an exact pixel comparison would be too strict for it
to pass across different platforms due to small variations in the
output of different graphics cards.
There is a threshold for the difference (to allow for slight color
rendering variation between graphics cards?), plus the morphology
erode operation which I think the idea is to ignore possible variation
in aliasing on object borders across graphics cards, but also means
that thin differences like single pixel axes will get eroded away
entirely.
You can try tweaking the imagemagick arguments to maybe find a more
precise comparison method that reduces false negatives/positives
between test server and your dev machine.
Hans
Post by Marius Kintel
Note that there is a PR open to control some of those view settings as
cmd-line arguments. I’m on my phone so I’ll be short, but it shouldn’t be
hard to find.
Post by Marius Kintel
Yes, we have some erosion setting to let small rendering details slip
through. It wasn’t int intended to allow such large changes pass by
unnoticed though. Ideas are welcome!
Post by Marius Kintel
-Marius
As there is now no reason to not offer axes, scales and cross-hairs I
added them to the command line and invoked them in some of the camera
tests, expecting them to fail initially. To my surprise they pass, even
though the actual images have axes but the expected don't.
Post by Marius Kintel
Is there some tolerance to the image comparison that is big enough to
not notice a scaled axis?
Post by Marius Kintel
Post by nop head
I have now unified the camera modes with this PR
https://github.com/openscad/openscad/pull/2491. There is no vector mode
any more, just the option to set it up from vector parameters. It fixes the
lighting bug in vector mode, the view all without auto center bug in gimbal
mode and makes the GUI default view the same as the command line default.
Post by Marius Kintel
Post by nop head
I kept the camera default distance at 140 because although the default
was different for the vector camera it was never used because if you don't
specify a camera it uses viewall and autocenter. 140 is too close for me
but I think all the examples are sized for it.
Post by Marius Kintel
Post by nop head
The default angle is now [70, 0, 315], which is a fraction of a degree
different from the old command line default. It is different from the old
GUI default [55, 0, 25], but more logical if you design in the first
quadrant and it results in you looking towards the best lit side. IIRC it
used to be different in the distant past, or perhaps the lighting was.
Post by Marius Kintel
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-23 10:11:36 UTC
Permalink
I added a PR for command line axes. I have manually checked it works by
removing the erode but it won't get automatically regression tested.
However, the axes code never has been, so it is no worse than the current
situation.

While looking at the command line options I noticed they are added with
descriptions here:
https://github.com/openscad/openscad/blob/master/src/openscad.cc#L822 but
the help message doesn't use that data structure. It prints them without
descriptions here:
https://github.com/openscad/openscad/blob/master/src/openscad.cc#L138, so
they have to be added twice and kept in sync. Is there a reason for this?
Post by nop head
Yes it is the morphology erode that ignores the single pixel axes. If I
remove it all the tests pass except the ones where have turned on axes plus
a couple of 2D images. However I have just re-created all the expected
images 3D for my previous changes so I won't get any aliasing differences.
I can't think how we can both ignore aliasing differences and detect single
pixel axes at the same time.
My previous machine used to anti-alias the preview but this machine
doesn't. Its only option is to use application settings or turn it off,
whereas IIRC on my old machine I could force it on for a specify
application and I think it rendered at higher resolution and downsampled to
get smooth edges. Anybody know an application specifies anti-aliasing?
Post by Hans L
https://github.com/openscad/openscad/blob/74078c561afcbaaa98
bfecc8efdac805ae74d482/tests/test_cmdline_tool.py#L156
args = [expectedfilename, resultfilename, "-alpha", "On", "-compose",
"difference", "-composite", "-threshold", "10%", "-morphology",
"Erode", "Square", "-format", "%[fx:w*h*mean]", "info:"]
As I understand an exact pixel comparison would be too strict for it
to pass across different platforms due to small variations in the
output of different graphics cards.
There is a threshold for the difference (to allow for slight color
rendering variation between graphics cards?), plus the morphology
erode operation which I think the idea is to ignore possible variation
in aliasing on object borders across graphics cards, but also means
that thin differences like single pixel axes will get eroded away
entirely.
You can try tweaking the imagemagick arguments to maybe find a more
precise comparison method that reduces false negatives/positives
between test server and your dev machine.
Hans
Post by Marius Kintel
Note that there is a PR open to control some of those view settings as
cmd-line arguments. I’m on my phone so I’ll be short, but it shouldn’t be
hard to find.
Post by Marius Kintel
Yes, we have some erosion setting to let small rendering details slip
through. It wasn’t int intended to allow such large changes pass by
unnoticed though. Ideas are welcome!
Post by Marius Kintel
-Marius
As there is now no reason to not offer axes, scales and cross-hairs I
added them to the command line and invoked them in some of the camera
tests, expecting them to fail initially. To my surprise they pass, even
though the actual images have axes but the expected don't.
Post by Marius Kintel
Is there some tolerance to the image comparison that is big enough to
not notice a scaled axis?
Post by Marius Kintel
Post by nop head
I have now unified the camera modes with this PR
https://github.com/openscad/openscad/pull/2491. There is no vector mode
any more, just the option to set it up from vector parameters. It fixes the
lighting bug in vector mode, the view all without auto center bug in gimbal
mode and makes the GUI default view the same as the command line default.
Post by Marius Kintel
Post by nop head
I kept the camera default distance at 140 because although the default
was different for the vector camera it was never used because if you don't
specify a camera it uses viewall and autocenter. 140 is too close for me
but I think all the examples are sized for it.
Post by Marius Kintel
Post by nop head
The default angle is now [70, 0, 315], which is a fraction of a degree
different from the old command line default. It is different from the old
GUI default [55, 0, 25], but more logical if you design in the first
quadrant and it results in you looking towards the best lit side. IIRC it
used to be different in the distant past, or perhaps the lighting was.
Post by Marius Kintel
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-23 10:44:39 UTC
Permalink
This is what it currently outputs manually:

Usage: openscad.exe [ -o output_file [ -d deps_file ] ]\
[ -m make_command ] [ -D var=val [..] ] \
[ --help ] print this help message and exit \
[ --version ] [ --info ] \
[ --camera=translatex,y,z,rotx,y,z,dist | \
--camera=eyex,y,z,centerx,y,z ] \
[ --autocenter ] \
[ --viewall ] \
[ --imgsize=width,height ] [
--projection=(o)rtho|(p)ersp] \
[ --render | --preview[=throwntogether] ] \
[
--colorscheme=[Cornfield|Sunset|Metallic|Starnight|BeforeDawn|Nature|DeepOcean]
] \
[ --csglimit=num ] [ --enable=<feature> ] \
[ -p <Parameter Filename>] [-P <Parameter Set>] \
filename

This is what Boost::program_options generates automatically:

C:\msys64\home\ChrisP\openscad\release\openscad.exe: Allowed options:
-h [ --help ] help message
-v [ --version ] print the version
--info print information about the building process
--render arg if exporting a png image, do a full geometry
evaluation
--preview arg if exporting a png image, do an OpenCSG(default) or
ThrownTogether preview
--csglimit arg if exporting a png image, stop rendering at the
given
number of CSG elements
--camera arg parameters for camera when exporting png
--autocenter adjust camera to look at object center
--viewall adjust camera to fit object
--showaxes show axes
--showscale show scale markers on axes
--showcrosshairs show cross hairs at the center of the view
--imgsize arg =width,height for exporting png
--projection arg (o)rtho or (p)erspective when exporting png
--colorscheme arg colorscheme
--debug arg special debug info
-q [ --quiet ] quiet mode (don't print anything *except* errors)
-o [ --o ] arg out-file
-p [ --p ] arg parameter file
-P [ --P ] arg parameter set
-s [ --s ] arg stl-file
-x [ --x ] arg dxf-file
-d [ --d ] arg deps-file
-m [ --m ] arg makefile
-D [ --D ] arg var=val
--enable arg enable experimental features

I think by adding to a couple of the descriptions it would be better.
Post by nop head
I added a PR for command line axes. I have manually checked it works by
removing the erode but it won't get automatically regression tested.
However, the axes code never has been, so it is no worse than the current
situation.
While looking at the command line options I noticed they are added with
descriptions here: https://github.com/openscad/openscad/blob/master/src/
openscad.cc#L822 but the help message doesn't use that data structure. It
prints them without descriptions here: https://github.com/openscad/
openscad/blob/master/src/openscad.cc#L138, so they have to be added twice
and kept in sync. Is there a reason for this?
Post by nop head
Yes it is the morphology erode that ignores the single pixel axes. If I
remove it all the tests pass except the ones where have turned on axes plus
a couple of 2D images. However I have just re-created all the expected
images 3D for my previous changes so I won't get any aliasing differences.
I can't think how we can both ignore aliasing differences and detect single
pixel axes at the same time.
My previous machine used to anti-alias the preview but this machine
doesn't. Its only option is to use application settings or turn it off,
whereas IIRC on my old machine I could force it on for a specify
application and I think it rendered at higher resolution and downsampled to
get smooth edges. Anybody know an application specifies anti-aliasing?
Post by Hans L
https://github.com/openscad/openscad/blob/74078c561afcbaaa98
bfecc8efdac805ae74d482/tests/test_cmdline_tool.py#L156
args = [expectedfilename, resultfilename, "-alpha", "On", "-compose",
"difference", "-composite", "-threshold", "10%", "-morphology",
"Erode", "Square", "-format", "%[fx:w*h*mean]", "info:"]
As I understand an exact pixel comparison would be too strict for it
to pass across different platforms due to small variations in the
output of different graphics cards.
There is a threshold for the difference (to allow for slight color
rendering variation between graphics cards?), plus the morphology
erode operation which I think the idea is to ignore possible variation
in aliasing on object borders across graphics cards, but also means
that thin differences like single pixel axes will get eroded away
entirely.
You can try tweaking the imagemagick arguments to maybe find a more
precise comparison method that reduces false negatives/positives
between test server and your dev machine.
Hans
Post by Marius Kintel
Note that there is a PR open to control some of those view settings as
cmd-line arguments. I’m on my phone so I’ll be short, but it shouldn’t be
hard to find.
Post by Marius Kintel
Yes, we have some erosion setting to let small rendering details slip
through. It wasn’t int intended to allow such large changes pass by
unnoticed though. Ideas are welcome!
Post by Marius Kintel
-Marius
As there is now no reason to not offer axes, scales and cross-hairs I
added them to the command line and invoked them in some of the camera
tests, expecting them to fail initially. To my surprise they pass, even
though the actual images have axes but the expected don't.
Post by Marius Kintel
Is there some tolerance to the image comparison that is big enough to
not notice a scaled axis?
Post by Marius Kintel
Post by nop head
I have now unified the camera modes with this PR
https://github.com/openscad/openscad/pull/2491. There is no vector mode
any more, just the option to set it up from vector parameters. It fixes the
lighting bug in vector mode, the view all without auto center bug in gimbal
mode and makes the GUI default view the same as the command line default.
Post by Marius Kintel
Post by nop head
I kept the camera default distance at 140 because although the
default was different for the vector camera it was never used because if
you don't specify a camera it uses viewall and autocenter. 140 is too close
for me but I think all the examples are sized for it.
Post by Marius Kintel
Post by nop head
The default angle is now [70, 0, 315], which is a fraction of a
degree different from the old command line default. It is different from
the old GUI default [55, 0, 25], but more logical if you design in the
first quadrant and it results in you looking towards the best lit side.
IIRC it used to be different in the distant past, or perhaps the lighting
was.
Post by Marius Kintel
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-23 11:44:42 UTC
Permalink
Here it is tidied up a bit:

Usage: openscad.exe [options] file.scad
Allowed options:
-o [ --o ] arg out-file
-d [ --d ] arg deps-file
-D [ --D ] arg var=val
-m [ --m ] arg makefile
-h [ --help ] help message
-v [ --version ] print the version
--info print information about the building process
--csglimit arg if exporting a png image, stop rendering at the
given
number of CSG elements
--camera arg camera parameters when exporting png:
translate_x,y,z,rot_x,y,z,dist or
eye_x,y,z,center_x,y,z
--autocenter adjust camera to look at object center
--viewall adjust camera to fit object
--showaxes show axes in png images
--showscale show scale markers on axes
--showcrosshairs show cross hairs at the center of the view
--imgsize arg =width,height for exporting png
--render arg if exporting a png image, do a full geometry
evaluation
--preview arg if exporting a png image, do an OpenCSG(default) or
ThrownTogether preview
--projection arg (o)rtho or (p)erspective when exporting png
--colorscheme arg colorscheme Cornfield | Sunset | Metallic |
Starnight |
BeforeDawn | Nature | DeepOcean
-p [ --p ] arg customizer parameter file
-P [ --P ] arg customizer parameter set
-s [ --s ] arg stl-file deprecated, use -o
-x [ --x ] arg dxf-file deprecated, use -o
--enable arg enable experimental features
--debug arg special debug info
-q [ --quiet ] quiet mode (don't print anything *except* errors)

Auto generated with four lines of code. What do people think?
Post by nop head
Usage: openscad.exe [ -o output_file [ -d deps_file ] ]\
[ -m make_command ] [ -D var=val [..] ] \
[ --help ] print this help message and exit \
[ --version ] [ --info ] \
[ --camera=translatex,y,z,rotx,y,z,dist | \
--camera=eyex,y,z,centerx,y,z ] \
[ --autocenter ] \
[ --viewall ] \
[ --imgsize=width,height ] [
--projection=(o)rtho|(p)ersp] \
[ --render | --preview[=throwntogether] ] \
[ --colorscheme=[Cornfield|Sunset|Metallic|Starnight|BeforeDawn|Nature|DeepOcean]
] \
[ --csglimit=num ] [ --enable=<feature> ] \
[ -p <Parameter Filename>] [-P <Parameter Set>] \
filename
-h [ --help ] help message
-v [ --version ] print the version
--info print information about the building process
--render arg if exporting a png image, do a full geometry
evaluation
--preview arg if exporting a png image, do an OpenCSG(default) or
ThrownTogether preview
--csglimit arg if exporting a png image, stop rendering at the
given
number of CSG elements
--camera arg parameters for camera when exporting png
--autocenter adjust camera to look at object center
--viewall adjust camera to fit object
--showaxes show axes
--showscale show scale markers on axes
--showcrosshairs show cross hairs at the center of the view
--imgsize arg =width,height for exporting png
--projection arg (o)rtho or (p)erspective when exporting png
--colorscheme arg colorscheme
--debug arg special debug info
-q [ --quiet ] quiet mode (don't print anything *except* errors)
-o [ --o ] arg out-file
-p [ --p ] arg parameter file
-P [ --P ] arg parameter set
-s [ --s ] arg stl-file
-x [ --x ] arg dxf-file
-d [ --d ] arg deps-file
-m [ --m ] arg makefile
-D [ --D ] arg var=val
--enable arg enable experimental features
I think by adding to a couple of the descriptions it would be better.
Post by nop head
I added a PR for command line axes. I have manually checked it works by
removing the erode but it won't get automatically regression tested.
However, the axes code never has been, so it is no worse than the current
situation.
While looking at the command line options I noticed they are added with
descriptions here: https://github.com/openscad/op
enscad/blob/master/src/openscad.cc#L822 but the help message doesn't use
https://github.com/openscad/openscad/blob/master/src/openscad.cc#L138,
so they have to be added twice and kept in sync. Is there a reason for this?
Post by nop head
Yes it is the morphology erode that ignores the single pixel axes. If I
remove it all the tests pass except the ones where have turned on axes plus
a couple of 2D images. However I have just re-created all the expected
images 3D for my previous changes so I won't get any aliasing differences.
I can't think how we can both ignore aliasing differences and detect single
pixel axes at the same time.
My previous machine used to anti-alias the preview but this machine
doesn't. Its only option is to use application settings or turn it off,
whereas IIRC on my old machine I could force it on for a specify
application and I think it rendered at higher resolution and downsampled to
get smooth edges. Anybody know an application specifies anti-aliasing?
Post by Hans L
https://github.com/openscad/openscad/blob/74078c561afcbaaa98
bfecc8efdac805ae74d482/tests/test_cmdline_tool.py#L156
args = [expectedfilename, resultfilename, "-alpha", "On", "-compose",
"difference", "-composite", "-threshold", "10%", "-morphology",
"Erode", "Square", "-format", "%[fx:w*h*mean]", "info:"]
As I understand an exact pixel comparison would be too strict for it
to pass across different platforms due to small variations in the
output of different graphics cards.
There is a threshold for the difference (to allow for slight color
rendering variation between graphics cards?), plus the morphology
erode operation which I think the idea is to ignore possible variation
in aliasing on object borders across graphics cards, but also means
that thin differences like single pixel axes will get eroded away
entirely.
You can try tweaking the imagemagick arguments to maybe find a more
precise comparison method that reduces false negatives/positives
between test server and your dev machine.
Hans
Post by Marius Kintel
Note that there is a PR open to control some of those view settings
as cmd-line arguments. I’m on my phone so I’ll be short, but it shouldn’t
be hard to find.
Post by Marius Kintel
Yes, we have some erosion setting to let small rendering details slip
through. It wasn’t int intended to allow such large changes pass by
unnoticed though. Ideas are welcome!
Post by Marius Kintel
-Marius
As there is now no reason to not offer axes, scales and cross-hairs I
added them to the command line and invoked them in some of the camera
tests, expecting them to fail initially. To my surprise they pass, even
though the actual images have axes but the expected don't.
Post by Marius Kintel
Is there some tolerance to the image comparison that is big enough to
not notice a scaled axis?
Post by Marius Kintel
Post by nop head
I have now unified the camera modes with this PR
https://github.com/openscad/openscad/pull/2491. There is no vector
mode any more, just the option to set it up from vector parameters. It
fixes the lighting bug in vector mode, the view all without auto center bug
in gimbal mode and makes the GUI default view the same as the command line
default.
Post by Marius Kintel
Post by nop head
I kept the camera default distance at 140 because although the
default was different for the vector camera it was never used because if
you don't specify a camera it uses viewall and autocenter. 140 is too close
for me but I think all the examples are sized for it.
Post by Marius Kintel
Post by nop head
The default angle is now [70, 0, 315], which is a fraction of a
degree different from the old command line default. It is different from
the old GUI default [55, 0, 25], but more logical if you design in the
first quadrant and it results in you looking towards the best lit side.
IIRC it used to be different in the distant past, or perhaps the lighting
was.
Post by Marius Kintel
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Rogier Wolff
2018-09-23 12:02:49 UTC
Permalink
Post by nop head
Auto generated with four lines of code. What do people think?
That sort of changes are VERY good from a software-engineering and/or
maintenance point-of-view. So. IMHO: Great work!

Roger.
--
** ***@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
TLC123
2018-09-24 01:52:36 UTC
Permalink
Looks very nice.
There is still space to further clarify the first four though.

-o [ --o ] arg out-file
-d [ --d ] arg deps-file
-D [ --D ] arg var=val
-m [ --m ] arg makefile



--
Sent from: http://forum.openscad.org/
nop head
2018-09-24 12:17:35 UTC
Permalink
How about this:

Usage: openscad.exe [options] file.scad
Allowed options:
-o [ --o ] arg out_file -output a file instead of running the GUI,
the
file extension specifies the type: stl, off, amf,
csg,
dxf, svg, png, echo, ast, term
-D [ --D ] arg var=val -pre-define variables
-d [ --d ] arg deps_file -generate a dependency file for make
-m [ --m ] arg make_cmd -runs make_cmd file if file is missing
-h [ --help ] print this help message and exit
-v [ --version ] print the version
--info print information about the build process
--csglimit arg if exporting a png image, stop rendering at the
given
number of CSG elements
--camera arg camera parameters when exporting png:
translate_x,y,z,rot_x,y,z,dist or
eye_x,y,z,center_x,y,z
--autocenter adjust camera to look at object center
--viewall adjust camera to fit object
--imgsize arg =width,height for exporting png
--render arg if exporting a png image, do a full geometry
evaluation
--preview arg if exporting a png image, do an OpenCSG(default) or
ThrownTogether preview
--projection arg (o)rtho or (p)erspective when exporting png
--colorscheme arg colorscheme Cornfield | Sunset | Metallic |
Starnight |
BeforeDawn | Nature | DeepOcean
-p [ --p ] arg customizer parameter file
-P [ --P ] arg customizer parameter set
-s [ --s ] arg stl-file deprecated, use -o
-x [ --x ] arg dxf-file deprecated, use -o
--enable arg enable experimental features
--debug arg special debug info
-q [ --quiet ] quiet mode (don't print anything *except* errors)

The list of colour schemes need to be generated programmatically as well
because it inevitable doesn't match those in the menu.
Post by TLC123
Looks very nice.
There is still space to further clarify the first four though.
-o [ --o ] arg out-file
-d [ --d ] arg deps-file
-D [ --D ] arg var=val
-m [ --m ] arg makefile
--
Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-24 13:19:11 UTC
Permalink
Re-ordered to put more obscure options later and color scheme list
generated programmatically.

Usage: openscad.exe [options] file.scad
Allowed options:
-o [ --o ] arg out_file -output a file instead of running the GUI,
the
file extension specifies the type: stl, off, amf,
csg,
dxf, svg, png, echo, ast, term, nef3, nefdbg
-D [ --D ] arg var=val -pre-define variables
-p [ --p ] arg customizer parameter file
-P [ --P ] arg customizer parameter set
-h [ --help ] print this help message and exit
-v [ --version ] print the version
--camera arg camera parameters when exporting png:
translate_x,y,z,rot_x,y,z,dist or
eye_x,y,z,center_x,y,z
--autocenter adjust camera to look at object center
--viewall adjust camera to fit object
--imgsize arg =width,height for exporting png
--render arg if exporting a png image, do a full geometry
evaluation
--preview arg if exporting a png image, do an OpenCSG(default) or
ThrownTogether preview
--projection arg (o)rtho or (p)erspective when exporting png
--colorscheme arg colorscheme: Cornfield | Metallic | Sunset |
Starnight
| BeforeDawn | Nature | DeepOcean | Solarized |
Tomorrow | Tomorrow Night | Monotone
--csglimit arg if exporting a png image, stop rendering at the
given
number of CSG elements
-d [ --d ] arg deps_file -generate a dependency file for make
-m [ --m ] arg make_cmd -runs make_cmd file if file is missing
--enable arg enable experimental features
--info print information about the build process
--debug arg special debug info
-q [ --quiet ] quiet mode (don't print anything *except* errors)
-s [ --s ] arg stl-file deprecated, use -o
-x [ --x ] arg dxf-file deprecated, use -o
Post by nop head
Usage: openscad.exe [options] file.scad
-o [ --o ] arg out_file -output a file instead of running the
GUI, the
file extension specifies the type: stl, off, amf,
csg,
dxf, svg, png, echo, ast, term
-D [ --D ] arg var=val -pre-define variables
-d [ --d ] arg deps_file -generate a dependency file for make
-m [ --m ] arg make_cmd -runs make_cmd file if file is missing
-h [ --help ] print this help message and exit
-v [ --version ] print the version
--info print information about the build process
--csglimit arg if exporting a png image, stop rendering at the
given
number of CSG elements
translate_x,y,z,rot_x,y,z,dist or
eye_x,y,z,center_x,y,z
--autocenter adjust camera to look at object center
--viewall adjust camera to fit object
--imgsize arg =width,height for exporting png
--render arg if exporting a png image, do a full geometry
evaluation
--preview arg if exporting a png image, do an OpenCSG(default) or
ThrownTogether preview
--projection arg (o)rtho or (p)erspective when exporting png
--colorscheme arg colorscheme Cornfield | Sunset | Metallic |
Starnight |
BeforeDawn | Nature | DeepOcean
-p [ --p ] arg customizer parameter file
-P [ --P ] arg customizer parameter set
-s [ --s ] arg stl-file deprecated, use -o
-x [ --x ] arg dxf-file deprecated, use -o
--enable arg enable experimental features
--debug arg special debug info
-q [ --quiet ] quiet mode (don't print anything *except* errors)
The list of colour schemes need to be generated programmatically as well
because it inevitable doesn't match those in the menu.
Post by TLC123
Looks very nice.
There is still space to further clarify the first four though.
-o [ --o ] arg out-file
-d [ --d ] arg deps-file
-D [ --D ] arg var=val
-m [ --m ] arg makefile
--
Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Rogier Wolff
2018-09-24 13:24:44 UTC
Permalink
Post by nop head
--colorscheme arg colorscheme: Cornfield | Metallic | Sunset |
Starnight
Would it be possible to print a "*" next to the currently selected
colorscheme? That would normally be the default one, but it should be
the "currently selected" that is tagged to accomodate configurations
where say an environment variable changes the default.

Roger.
--
** ***@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
nop head
2018-09-24 13:39:09 UTC
Permalink
Yes, easy, but I have found that a side effect of accessing the ColorMap
class early is to make the GUI lock up at the splash screen.
Post by Rogier Wolff
Post by nop head
--colorscheme arg colorscheme: Cornfield | Metallic | Sunset |
Starnight
Would it be possible to print a "*" next to the currently selected
colorscheme? That would normally be the default one, but it should be
the "currently selected" that is tagged to accomodate configurations
where say an environment variable changes the default.
Roger.
--
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Rogier Wolff
2018-09-24 13:59:11 UTC
Permalink
Post by nop head
Yes, easy, but I have found that a side effect of accessing the ColorMap
class early is to make the GUI lock up at the splash screen.
So... Not easy then. :-)

Roger.
--
** ***@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
nop head
2018-09-24 14:03:43 UTC
Permalink
The problem is moving this code from cmdline() to main() because ColorMap
needs application path to registered.

#ifdef OPENSCAD_QTGUI
QCoreApplication app(argc, argv);
const std::string application_path =
QCoreApplication::instance()->applicationDirPath().toLocal8Bit().constData();
#else
const std::string application_path =
fs::absolute(boost::filesystem::path(argv[0]).parent_path()).generic_string();
#endif

Having two QT app instances seems to be a problem, no surprise there! Is
there a reason for preferring the QT version? The boost version produces
the same path on my system so using that solves the problem.
Post by nop head
Yes, easy, but I have found that a side effect of accessing the ColorMap
class early is to make the GUI lock up at the splash screen.
Post by Rogier Wolff
Post by nop head
--colorscheme arg colorscheme: Cornfield | Metallic | Sunset |
Starnight
Would it be possible to print a "*" next to the currently selected
colorscheme? That would normally be the default one, but it should be
the "currently selected" that is tagged to accomodate configurations
where say an environment variable changes the default.
Roger.
--
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-24 16:13:13 UTC
Permalink
Actually there is no currently selected colourscheme when using the command
line. The default is hard coded to cornfield, regardless of what is
selected in the GUI.
Post by nop head
The problem is moving this code from cmdline() to main() because ColorMap
needs application path to registered.
#ifdef OPENSCAD_QTGUI
QCoreApplication app(argc, argv);
const std::string application_path = QCoreApplication::instance()->
applicationDirPath().toLocal8Bit().constData();
#else
filesystem::path(argv[0]).parent_path()).generic_string();
#endif
Having two QT app instances seems to be a problem, no surprise there! Is
there a reason for preferring the QT version? The boost version produces
the same path on my system so using that solves the problem.
Post by nop head
Yes, easy, but I have found that a side effect of accessing the ColorMap
class early is to make the GUI lock up at the splash screen.
Post by Rogier Wolff
Post by nop head
--colorscheme arg colorscheme: Cornfield | Metallic | Sunset |
Starnight
Would it be possible to print a "*" next to the currently selected
colorscheme? That would normally be the default one, but it should be
the "currently selected" that is tagged to accomodate configurations
where say an environment variable changes the default.
Roger.
--
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233
**
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Torsten Paul
2018-09-24 17:28:01 UTC
Permalink
Post by nop head
Having two QT app instances seems to be a problem, no surprise there!
Is there a reason for preferring the QT version? The boost version
produces the same path on my system so using that solves the problem.
The current code might be just for legacy reasons, but there are various
issues with boost on Windows regarding hard-links and non-ascii path.
I don't know if the toLocal8Bit() from Qt is better, but it might actually
help in those cases. Otherwise it would be nicer to just have a single
way to determine the path.

The command line help change looks very nice. I think that using the
generated version is much better as this pretty much removes the risk
of information missing in the output in case of future changes to the
options.

ciao,
Torsten.
nop head
2018-09-24 18:27:36 UTC
Permalink
The way it currently works is if it runs the GUI then it gets the
application path from the OpenSCADApp instance. If it runs the command line
version it instantiates a QCoreApplication app and uses that. Only if it is
compiled without QT does it use the boost version.

To get the color schemes in the command line description it needs the app
path before it has processed the command line. I bodged it by always
creating a QCoreApplicationapp on the heap, using it to get the app path
and then deleting it. That seems to fix the problem and still uses QT if
compiled with QT.

#ifdef OPENSCAD_QTGUI
QCoreApplication *app = new QCoreApplication(argc, argv);
const std::string application_path =
QCoreApplication::instance()->applicationDirPath().toLocal8Bit().constData();
delete app;
#else
const std::string application_path =
fs::absolute(boost::filesystem::path(argv[0]).parent_path()).generic_string();
#endif
PlatformUtils::registerApplicationPath(application_path);

Can anybody see a problem with this hack?
Post by Torsten Paul
Post by nop head
Having two QT app instances seems to be a problem, no surprise there!
Is there a reason for preferring the QT version? The boost version
produces the same path on my system so using that solves the problem.
The current code might be just for legacy reasons, but there are various
issues with boost on Windows regarding hard-links and non-ascii path.
I don't know if the toLocal8Bit() from Qt is better, but it might actually
help in those cases. Otherwise it would be nicer to just have a single
way to determine the path.
The command line help change looks very nice. I think that using the
generated version is much better as this pretty much removes the risk
of information missing in the output in case of future changes to the
options.
ciao,
Torsten.
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-24 18:29:51 UTC
Permalink
Actually QCoreApplication::applicationDirPath() is static so I don't need
an instance.
Post by nop head
The way it currently works is if it runs the GUI then it gets the
application path from the OpenSCADApp instance. If it runs the command line
version it instantiates a QCoreApplication app and uses that. Only if it is
compiled without QT does it use the boost version.
To get the color schemes in the command line description it needs the app
path before it has processed the command line. I bodged it by always
creating a QCoreApplicationapp on the heap, using it to get the app path
and then deleting it. That seems to fix the problem and still uses QT if
compiled with QT.
#ifdef OPENSCAD_QTGUI
QCoreApplication *app = new QCoreApplication(argc, argv);
const std::string application_path = QCoreApplication::instance()->
applicationDirPath().toLocal8Bit().constData();
delete app;
#else
filesystem::path(argv[0]).parent_path()).generic_string();
#endif
PlatformUtils::registerApplicationPath(application_path);
Can anybody see a problem with this hack?
Post by Torsten Paul
Post by nop head
Having two QT app instances seems to be a problem, no surprise there!
Is there a reason for preferring the QT version? The boost version
produces the same path on my system so using that solves the problem.
The current code might be just for legacy reasons, but there are various
issues with boost on Windows regarding hard-links and non-ascii path.
I don't know if the toLocal8Bit() from Qt is better, but it might actually
help in those cases. Otherwise it would be nicer to just have a single
way to determine the path.
The command line help change looks very nice. I think that using the
generated version is much better as this pretty much removes the risk
of information missing in the output in case of future changes to the
options.
ciao,
Torsten.
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-24 18:33:44 UTC
Permalink
#ifdef OPENSCAD_QTGUI
const std::string application_path =
QCoreApplication::applicationDirPath().toLocal8Bit().constData();
#else
const std::string application_path =
fs::absolute(boost::filesystem::path(argv[0]).parent_path()).generic_string();
#endif
PlatformUtils::registerApplicationPath(application_path);

Much nicer!
Post by nop head
Actually QCoreApplication::applicationDirPath() is static so I don't need
an instance.
Post by nop head
The way it currently works is if it runs the GUI then it gets the
application path from the OpenSCADApp instance. If it runs the command line
version it instantiates a QCoreApplication app and uses that. Only if it is
compiled without QT does it use the boost version.
To get the color schemes in the command line description it needs the app
path before it has processed the command line. I bodged it by always
creating a QCoreApplicationapp on the heap, using it to get the app path
and then deleting it. That seems to fix the problem and still uses QT if
compiled with QT.
#ifdef OPENSCAD_QTGUI
QCoreApplication *app = new QCoreApplication(argc, argv);
const std::string application_path = QCoreApplication::instance()->
applicationDirPath().toLocal8Bit().constData();
delete app;
#else
const std::string application_path = fs::absolute(boost::filesystem
::path(argv[0]).parent_path()).generic_string();
#endif
PlatformUtils::registerApplicationPath(application_path);
Can anybody see a problem with this hack?
Post by Torsten Paul
Post by nop head
Having two QT app instances seems to be a problem, no surprise there!
Is there a reason for preferring the QT version? The boost version
produces the same path on my system so using that solves the problem.
The current code might be just for legacy reasons, but there are various
issues with boost on Windows regarding hard-links and non-ascii path.
I don't know if the toLocal8Bit() from Qt is better, but it might actually
help in those cases. Otherwise it would be nicer to just have a single
way to determine the path.
The command line help change looks very nice. I think that using the
generated version is much better as this pretty much removes the risk
of information missing in the output in case of future changes to the
options.
ciao,
Torsten.
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-24 19:10:08 UTC
Permalink
A bit more re-ordering, some blank line separators and a list of
experimental features available. Anybody got any suggestions before I make
a PR.

Usage: openscad.exe [options] file.scad
Allowed options:
-o [ --o ] arg out_file -output a file instead of running the GUI,
the
file extension specifies the type: stl, off, amf,
csg,
dxf, svg, png, echo, ast, term, nef3, nefdbg
-D [ --D ] arg var=val -pre-define variables
-p [ --p ] arg customizer parameter file
-P [ --P ] arg customizer parameter set
--enable arg enable experimental features: assert | echo |
lc-each |
lc-else | lc-for-c | amf-import | svg-import |
customizer
-h [ --help ] print this help message and exit
-v [ --version ] print the version

--camera arg camera parameters when exporting png:
translate_x,y,z,rot_x,y,z,dist or
eye_x,y,z,center_x,y,z
--autocenter adjust camera to look at object center
--viewall adjust camera to fit object
--imgsize arg =width,height for exporting png
--render arg if exporting a png image, do a full geometry
evaluation
--preview arg if exporting a png image, do an OpenCSG(default) or
ThrownTogether preview
--projection arg (o)rtho or (p)erspective when exporting png
--colorscheme arg colorscheme: *Cornfield | Metallic | Sunset |
Starnight
| BeforeDawn | Nature | DeepOcean | Solarized |
Tomorrow | Tomorrow Night | Monotone
--csglimit arg if exporting a png image, stop rendering at the
given
number of CSG elements

-d [ --d ] arg deps_file -generate a dependency file for make
-m [ --m ] arg make_cmd -runs make_cmd file if file is missing
--info print information about the build process
--debug arg special debug info
-q [ --quiet ] quiet mode (don't print anything *except* errors)
-s [ --s ] arg stl-file deprecated, use -o
-x [ --x ] arg dxf-file deprecated, use -o
Post by nop head
#ifdef OPENSCAD_QTGUI
applicationDirPath().toLocal8Bit().constData();
#else
filesystem::path(argv[0]).parent_path()).generic_string();
#endif
PlatformUtils::registerApplicationPath(application_path);
Much nicer!
Post by nop head
Actually QCoreApplication::applicationDirPath() is static so I don't
need an instance.
Post by nop head
The way it currently works is if it runs the GUI then it gets the
application path from the OpenSCADApp instance. If it runs the command line
version it instantiates a QCoreApplication app and uses that. Only if it is
compiled without QT does it use the boost version.
To get the color schemes in the command line description it needs the
app path before it has processed the command line. I bodged it by always
creating a QCoreApplicationapp on the heap, using it to get the app path
and then deleting it. That seems to fix the problem and still uses QT if
compiled with QT.
#ifdef OPENSCAD_QTGUI
QCoreApplication *app = new QCoreApplication(argc, argv);
const std::string application_path = QCoreApplication::instance()->
applicationDirPath().toLocal8Bit().constData();
delete app;
#else
const std::string application_path = fs::absolute(boost::filesystem
::path(argv[0]).parent_path()).generic_string();
#endif
PlatformUtils::registerApplicationPath(application_path);
Can anybody see a problem with this hack?
Post by Torsten Paul
Post by nop head
Having two QT app instances seems to be a problem, no surprise there!
Is there a reason for preferring the QT version? The boost version
produces the same path on my system so using that solves the problem.
The current code might be just for legacy reasons, but there are
various
issues with boost on Windows regarding hard-links and non-ascii path.
I don't know if the toLocal8Bit() from Qt is better, but it might actually
help in those cases. Otherwise it would be nicer to just have a single
way to determine the path.
The command line help change looks very nice. I think that using the
generated version is much better as this pretty much removes the risk
of information missing in the output in case of future changes to the
options.
ciao,
Torsten.
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
doug moen
2018-09-24 19:23:00 UTC
Permalink
const std::string application_path = fs::absolute(boost::
filesystem::path(argv[0]).parent_path()).generic_string();

This code won't work. Suppose that you git clone the OpenSCAD repository,
build it, and install it in some place like /usr/local/bin. Then, when you
type 'openscad' from a bash prompt, then argv[0] will just be the string
"openscad", with no directory component. application_path should be set to
"/usr/local/bin", but this code won't return the correct directory.

I have a function called 'progdir()' which computes the application
directory, portable between Linux and MacOS. However, I've never tested my
code on Windows. You can have the code if you want it. progdir() works by
searching the PATH environment variable, when necessary, to determine the
application path.

How important is it for OpenSCAD to work correctly if it is built without
linking to Qt?
Post by nop head
#ifdef OPENSCAD_QTGUI
applicationDirPath().toLocal8Bit().constData();
#else
filesystem::path(argv[0]).parent_path()).generic_string();
#endif
PlatformUtils::registerApplicationPath(application_path);
Much nicer!
Post by nop head
Actually QCoreApplication::applicationDirPath() is static so I don't
need an instance.
Post by nop head
The way it currently works is if it runs the GUI then it gets the
application path from the OpenSCADApp instance. If it runs the command line
version it instantiates a QCoreApplication app and uses that. Only if it is
compiled without QT does it use the boost version.
To get the color schemes in the command line description it needs the
app path before it has processed the command line. I bodged it by always
creating a QCoreApplicationapp on the heap, using it to get the app path
and then deleting it. That seems to fix the problem and still uses QT if
compiled with QT.
#ifdef OPENSCAD_QTGUI
QCoreApplication *app = new QCoreApplication(argc, argv);
const std::string application_path = QCoreApplication::instance()->
applicationDirPath().toLocal8Bit().constData();
delete app;
#else
const std::string application_path = fs::absolute(boost::filesystem
::path(argv[0]).parent_path()).generic_string();
#endif
PlatformUtils::registerApplicationPath(application_path);
Can anybody see a problem with this hack?
Post by Torsten Paul
Post by nop head
Having two QT app instances seems to be a problem, no surprise there!
Is there a reason for preferring the QT version? The boost version
produces the same path on my system so using that solves the problem.
The current code might be just for legacy reasons, but there are
various
issues with boost on Windows regarding hard-links and non-ascii path.
I don't know if the toLocal8Bit() from Qt is better, but it might actually
help in those cases. Otherwise it would be nicer to just have a single
way to determine the path.
The command line help change looks very nice. I think that using the
generated version is much better as this pretty much removes the risk
of information missing in the output in case of future changes to the
options.
ciao,
Torsten.
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-24 19:45:10 UTC
Permalink
I think argv[0] is the full path of the executable on Windows, regardless
of what you type, but on Linux it is just what you typed. Does your code
cope with it being a full path like
C:/msys64/home/ChrisP/openscad/release/openscad.exe?
Post by nop head
const std::string application_path = fs::absolute(boost::filesystem
::path(argv[0]).parent_path()).generic_string();
This code won't work. Suppose that you git clone the OpenSCAD repository,
build it, and install it in some place like /usr/local/bin. Then, when you
type 'openscad' from a bash prompt, then argv[0] will just be the string
"openscad", with no directory component. application_path should be set to
"/usr/local/bin", but this code won't return the correct directory.
I have a function called 'progdir()' which computes the application
directory, portable between Linux and MacOS. However, I've never tested my
code on Windows. You can have the code if you want it. progdir() works by
searching the PATH environment variable, when necessary, to determine the
application path.
How important is it for OpenSCAD to work correctly if it is built without
linking to Qt?
Post by nop head
#ifdef OPENSCAD_QTGUI
const std::string application_path = QCoreApplication::applicationD
irPath().toLocal8Bit().constData();
#else
const std::string application_path = fs::absolute(boost::filesystem
::path(argv[0]).parent_path()).generic_string();
#endif
PlatformUtils::registerApplicationPath(application_path);
Much nicer!
Post by nop head
Actually QCoreApplication::applicationDirPath() is static so I don't
need an instance.
Post by nop head
The way it currently works is if it runs the GUI then it gets the
application path from the OpenSCADApp instance. If it runs the command line
version it instantiates a QCoreApplication app and uses that. Only if it is
compiled without QT does it use the boost version.
To get the color schemes in the command line description it needs the
app path before it has processed the command line. I bodged it by always
creating a QCoreApplicationapp on the heap, using it to get the app path
and then deleting it. That seems to fix the problem and still uses QT if
compiled with QT.
#ifdef OPENSCAD_QTGUI
QCoreApplication *app = new QCoreApplication(argc, argv);
const std::string application_path = QCoreApplication::instance()->
applicationDirPath().toLocal8Bit().constData();
delete app;
#else
const std::string application_path = fs::absolute(boost::filesystem
::path(argv[0]).parent_path()).generic_string();
#endif
PlatformUtils::registerApplicationPath(application_path);
Can anybody see a problem with this hack?
Post by Torsten Paul
Post by nop head
Having two QT app instances seems to be a problem, no surprise there!
Is there a reason for preferring the QT version? The boost version
produces the same path on my system so using that solves the problem.
The current code might be just for legacy reasons, but there are
various
issues with boost on Windows regarding hard-links and non-ascii path.
I don't know if the toLocal8Bit() from Qt is better, but it might actually
help in those cases. Otherwise it would be nicer to just have a single
way to determine the path.
The command line help change looks very nice. I think that using the
generated version is much better as this pretty much removes the risk
of information missing in the output in case of future changes to the
options.
ciao,
Torsten.
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
doug moen
2018-09-24 20:25:15 UTC
Permalink
Okay, here is my code. It's based on boost::filesystem, which OpenSCAD
already uses. It also uses my custom curv::Exception class, but you can
easily replace that part.

I think the only part of this that won't work on Windows is the part where
it splits the PATH variable at ':' characters. I think that should be a ';'
character on Windows, but I don't have a Windows dev environment to test
on. The licence can be replaced by GPL2, but keep the copyright notice.

Actually, here's another possible Windows dependency. If 'openscad.exe'
exists in the current directory, and you type 'openscad', then what
happens? If the existence of openscad.exe in the current directory
overrides the PATH search on Windows, and if argv[0] is set to "openscad"
in that case, then extra code would be required.

// Copyright 2016-2018 Doug Moen
// Licensed under the Apache License, version 2.0
// See https://www.apache.org/licenses/LICENSE-2.0

extern "C" {
#include <stdlib.h>
#include <string.h>
}
#include <libcurv/exception.h>
#include "progdir.h"
namespace fs = boost::filesystem;

/*
* Compute the absolute pathname of the directory
* containing the program executable.
* The storage for the result string is dynamically allocated.
* argv0 is argv[0] of the argv passed to main().
* ,,, Unix specific, right now.
*/
fs::path
progdir(const char *argv0)
{
fs::path cmd(argv0);

if (cmd.is_absolute())
return cmd.parent_path();

if (cmd.has_parent_path())
return fs::current_path() / cmd.parent_path();

const char* PATH = getenv("PATH");
if (PATH == NULL) {
throw curv::Exception_Base(curv::stringify(
"Can't determine directory of program ", argv0,
": PATH not defined"));
}

const char* p = PATH;
const char* pend = PATH + strlen(PATH);
while (p < pend) {
const char* q = strchr(p, ':');
if (q == nullptr)
q = pend;
fs::path file(p, q);
file /= argv0;
if (fs::exists(fs::status(file)))
return file.parent_path();
p = (q < pend ? q + 1 : pend);
}

throw curv::Exception_Base(curv::stringify(
"Can't determine directory of program ", argv0,
": can't find ", argv0, " in $PATH"));
}
Post by nop head
I think argv[0] is the full path of the executable on Windows, regardless
of what you type, but on Linux it is just what you typed. Does your code
cope with it being a full path like C:/msys64/home/ChrisP/
openscad/release/openscad.exe?
Post by nop head
const std::string application_path = fs::absolute(boost::filesystem
::path(argv[0]).parent_path()).generic_string();
This code won't work. Suppose that you git clone the OpenSCAD repository,
build it, and install it in some place like /usr/local/bin. Then, when you
type 'openscad' from a bash prompt, then argv[0] will just be the string
"openscad", with no directory component. application_path should be set to
"/usr/local/bin", but this code won't return the correct directory.
I have a function called 'progdir()' which computes the application
directory, portable between Linux and MacOS. However, I've never tested my
code on Windows. You can have the code if you want it. progdir() works by
searching the PATH environment variable, when necessary, to determine the
application path.
How important is it for OpenSCAD to work correctly if it is built without
linking to Qt?
Post by nop head
#ifdef OPENSCAD_QTGUI
const std::string application_path = QCoreApplication::applicationD
irPath().toLocal8Bit().constData();
#else
const std::string application_path = fs::absolute(boost::filesystem
::path(argv[0]).parent_path()).generic_string();
#endif
PlatformUtils::registerApplicationPath(application_path);
Much nicer!
Post by nop head
Actually QCoreApplication::applicationDirPath() is static so I don't
need an instance.
Post by nop head
The way it currently works is if it runs the GUI then it gets the
application path from the OpenSCADApp instance. If it runs the command line
version it instantiates a QCoreApplication app and uses that. Only if it is
compiled without QT does it use the boost version.
To get the color schemes in the command line description it needs the
app path before it has processed the command line. I bodged it by always
creating a QCoreApplicationapp on the heap, using it to get the app path
and then deleting it. That seems to fix the problem and still uses QT if
compiled with QT.
#ifdef OPENSCAD_QTGUI
QCoreApplication *app = new QCoreApplication(argc, argv);
const std::string application_path = QCoreApplication::instance()->
applicationDirPath().toLocal8Bit().constData();
delete app;
#else
const std::string application_path = fs::absolute(boost::filesystem
::path(argv[0]).parent_path()).generic_string();
#endif
PlatformUtils::registerApplicationPath(application_path);
Can anybody see a problem with this hack?
Post by Torsten Paul
Post by nop head
Having two QT app instances seems to be a problem, no surprise there!
Is there a reason for preferring the QT version? The boost version
produces the same path on my system so using that solves the problem.
The current code might be just for legacy reasons, but there are
various
issues with boost on Windows regarding hard-links and non-ascii path.
I don't know if the toLocal8Bit() from Qt is better, but it might actually
help in those cases. Otherwise it would be nicer to just have a single
way to determine the path.
The command line help change looks very nice. I think that using the
generated version is much better as this pretty much removes the risk
of information missing in the output in case of future changes to the
options.
ciao,
Torsten.
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Torsten Paul
2018-09-24 21:32:21 UTC
Permalink
Just a note on licensing, OpenSCAD code requires to be GPL2+,
including the "or (at your option) any later version" clause.
Otherwise it would not be possible to distribute OpenSCAD
anymore.

ciao,
Torsten.
doug moen
2018-09-24 21:37:32 UTC
Permalink
You can relicense this particular code with any open source licence you
wish. GPL2+ is fine, I didn't intend to exclude that.
Post by Torsten Paul
Just a note on licensing, OpenSCAD code requires to be GPL2+,
including the "or (at your option) any later version" clause.
Otherwise it would not be possible to distribute OpenSCAD
anymore.
ciao,
Torsten.
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Torsten Paul
2018-09-24 21:43:41 UTC
Permalink
Post by doug moen
You can relicense this particular code with any open source
licence you wish. GPL2+ is fine, I didn't intend to exclude
that.
Great, thanks, as (due to CGAL) the final application is GPL3+
anyway, it would work with Apache-2.0, I think. Having both
options is even better :-).

ciao,
Torsten.
nop head
2018-09-24 23:19:28 UTC
Permalink
If 'openscad.exe' exists in the current directory, and you type
'openscad', then what happens?
Win7 cmd.exe runs it. MSYS2's bash doesn't run unless you prepend ./

I wrote a win32 console program in a very old version of Visual studio and
found argv[0] is what you type, like Unix when run from CMD.EXE. However if
I run it in MSYS2's bash it is always the full path regardless. Also when
launched from the Desktop GUI then it is always the full path.

So when a program is run from CMD I think you have to look in the current
directory and then the path.
Post by doug moen
You can relicense this particular code with any open source
licence you wish. GPL2+ is fine, I didn't intend to exclude
that.
Great, thanks, as (due to CGAL) the final application is GPL3+
anyway, it would work with Apache-2.0, I think. Having both
options is even better :-).
ciao,
Torsten.
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Marius Kintel
2018-09-15 23:55:21 UTC
Permalink
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
nop head
2018-09-16 10:00:24 UTC
Permalink
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?
Post by nop head
Post by nop head
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.
$ 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
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-16 10:56:59 UTC
Permalink
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.
Post by nop head
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?
Post by nop head
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.
$ TEST_GENERATE=1 ctest -R <test regex>
https://github.com/openscad/openscad/blob/master/doc/testing.txt
-Marius
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-16 12:28:02 UTC
Permalink
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.
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.
Post by nop head
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?
Post by nop head
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.
$ TEST_GENERATE=1 ctest -R <test regex>
https://github.com/openscad/openscad/blob/master/doc/testing.txt
-Marius
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head
2018-09-16 12:37:35 UTC
Permalink
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.
Post by nop head
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.
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.
Post by nop head
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?
Post by nop head
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.
$ TEST_GENERATE=1 ctest -R <test regex>
https://github.com/openscad/openscad/blob/master/doc/testing.txt
-Marius
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Marius Kintel
2018-09-16 13:25:27 UTC
Permalink
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
Loading...