Light source and default camera position different on command line

classic Classic list List threaded Threaded
56 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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

nophead
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.




On 17 September 2018 at 08:40, nop head <[hidden email]> wrote:
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 <[hidden email]> wrote:
On 9/15/2018 5:34 AM, nop head wrote:
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

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

nophead
I 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.

On 18 September 2018 at 08:27, nop head <[hidden email]> wrote:
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.




On 17 September 2018 at 08:40, nop head <[hidden email]> wrote:
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 <[hidden email]> wrote:
On 9/15/2018 5:34 AM, nop head wrote:
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

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

nophead
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.



On 19 September 2018 at 12:37, nop head <[hidden email]> wrote:
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.

On 18 September 2018 at 08:27, nop head <[hidden email]> wrote:
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.




On 17 September 2018 at 08:40, nop head <[hidden email]> wrote:
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 <[hidden email]> wrote:
On 9/15/2018 5:34 AM, nop head wrote:
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

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

nophead
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?

On 19 September 2018 at 13:38, nop head <[hidden email]> wrote:
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.



On 19 September 2018 at 12:37, nop head <[hidden email]> wrote:
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.

On 18 September 2018 at 08:27, nop head <[hidden email]> wrote:
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.




On 17 September 2018 at 08:40, nop head <[hidden email]> wrote:
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 <[hidden email]> wrote:
On 9/15/2018 5:34 AM, nop head wrote:
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

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

thehans
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

On Wed, Sep 19, 2018 at 7:53 AM nop head <[hidden email]> wrote:
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?

On 19 September 2018 at 13:38, nop head <[hidden email]> wrote:
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.



On 19 September 2018 at 12:37, nop head <[hidden email]> wrote:
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.

On 18 September 2018 at 08:27, nop head <[hidden email]> wrote:
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.




On 17 September 2018 at 08:40, nop head <[hidden email]> wrote:
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 <[hidden email]> wrote:
On 9/15/2018 5:34 AM, nop head wrote:
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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

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

nophead
OK, Thanks. I will comment it out.

On 19 September 2018 at 21:02, Hans L <[hidden email]> wrote:
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

On Wed, Sep 19, 2018 at 7:53 AM nop head <[hidden email]> wrote:
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?

On 19 September 2018 at 13:38, nop head <[hidden email]> wrote:
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.



On 19 September 2018 at 12:37, nop head <[hidden email]> wrote:
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.

On 18 September 2018 at 08:27, nop head <[hidden email]> wrote:
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.




On 17 September 2018 at 08:40, nop head <[hidden email]> wrote:
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 <[hidden email]> wrote:
On 9/15/2018 5:34 AM, nop head wrote:
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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



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

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

nophead
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.

On 20 September 2018 at 09:10, Rogier Wolff <[hidden email]> wrote:
On Thu, Sep 20, 2018 at 08:38:15AM +0100, nop head wrote:
> 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.

--
** [hidden email] ** 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.


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

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

nophead
I 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

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

nophead
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?



On 21 September 2018 at 15:37, nop head <[hidden email]> wrote:
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

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

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.

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

On Sep 22, 2018, at 11:52, nop head <[hidden email]> wrote:

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?



On 21 September 2018 at 15:37, nop head <[hidden email]> wrote:
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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

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

thehans
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
On Sat, Sep 22, 2018 at 12:03 PM Marius Kintel <[hidden email]> wrote:

>
> 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
>
> On Sep 22, 2018, at 11:52, nop head <[hidden email]> wrote:
>
> 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?
>
>
>
> On 21 September 2018 at 15:37, nop head <[hidden email]> wrote:
>>
>> 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
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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

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

nophead
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?



On 22 September 2018 at 18:28, Hans L <[hidden email]> wrote:
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
On Sat, Sep 22, 2018 at 12:03 PM Marius Kintel <[hidden email]> wrote:
>
> 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
>
> On Sep 22, 2018, at 11:52, nop head <[hidden email]> wrote:
>
> 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?
>
>
>
> On 21 September 2018 at 15:37, nop head <[hidden email]> wrote:
>>
>> 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
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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


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

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

nophead
I 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?


On 22 September 2018 at 20:00, nop head <[hidden email]> wrote:
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?



On 22 September 2018 at 18:28, Hans L <[hidden email]> wrote:
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
On Sat, Sep 22, 2018 at 12:03 PM Marius Kintel <[hidden email]> wrote:
>
> 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
>
> On Sep 22, 2018, at 11:52, nop head <[hidden email]> wrote:
>
> 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?
>
>
>
> On 21 September 2018 at 15:37, nop head <[hidden email]> wrote:
>>
>> 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
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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



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

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

nophead
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.


On 23 September 2018 at 11:11, nop head <[hidden email]> wrote:
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?


On 22 September 2018 at 20:00, nop head <[hidden email]> wrote:
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?



On 22 September 2018 at 18:28, Hans L <[hidden email]> wrote:
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
On Sat, Sep 22, 2018 at 12:03 PM Marius Kintel <[hidden email]> wrote:
>
> 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
>
> On Sep 22, 2018, at 11:52, nop head <[hidden email]> wrote:
>
> 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?
>
>
>
> On 21 September 2018 at 15:37, nop head <[hidden email]> wrote:
>>
>> 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
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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




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

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

nophead
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?

On 23 September 2018 at 11:44, nop head <[hidden email]> wrote:
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.


On 23 September 2018 at 11:11, nop head <[hidden email]> wrote:
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?


On 22 September 2018 at 20:00, nop head <[hidden email]> wrote:
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?



On 22 September 2018 at 18:28, Hans L <[hidden email]> wrote:
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
On Sat, Sep 22, 2018 at 12:03 PM Marius Kintel <[hidden email]> wrote:
>
> 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
>
> On Sep 22, 2018, at 11:52, nop head <[hidden email]> wrote:
>
> 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?
>
>
>
> On 21 September 2018 at 15:37, nop head <[hidden email]> wrote:
>>
>> 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
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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





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

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

rew
On Sun, Sep 23, 2018 at 12:44:42PM +0100, nop head wrote:
> 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.

--
** [hidden email] ** 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.

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

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

TLC123
In reply to this post by nophead
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

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

nophead
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.

On 24 September 2018 at 02:52, TLC123 <[hidden email]> wrote:
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


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

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

nophead
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


On 24 September 2018 at 13:17, nop head <[hidden email]> wrote:
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.

On 24 September 2018 at 02:52, TLC123 <[hidden email]> wrote:
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



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

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

rew
On Mon, Sep 24, 2018 at 02:19:11PM +0100, nop head wrote:

>   --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.

--
** [hidden email] ** 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.

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