Roger.

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 <R.E.Wolff@bitwizard.nl> 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. > > -- > ** R.E.Wolff@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. >

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.

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 <nop.head@gmail.com> 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. > >

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 <nop.head@gmail.com> 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 <nop.head@gmail.com> 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 > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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 <kintel@kintel.net> 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 <nop.head@gmail.com> 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 <nop.head@gmail.com> 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 > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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 <thehans@gmail.com> wrote: > The default imagemagick arguments can be seen here: > 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 > On Sat, Sep 22, 2018 at 12:03 PM Marius Kintel <kintel@kintel.net> 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 <nop.head@gmail.com> 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 <nop.head@gmail.com> 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 > > Discuss@lists.openscad.org > > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > > > _______________________________________________ > > OpenSCAD mailing list > > Discuss@lists.openscad.org > > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

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 <nop.head@gmail.com> 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 <thehans@gmail.com> wrote: > >> The default imagemagick arguments can be seen here: >> 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 >> On Sat, Sep 22, 2018 at 12:03 PM Marius Kintel <kintel@kintel.net> 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 <nop.head@gmail.com> 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 <nop.head@gmail.com> 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 >> > Discuss@lists.openscad.org >> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> > >> > _______________________________________________ >> > OpenSCAD mailing list >> > Discuss@lists.openscad.org >> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> > >

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 <nop.head@gmail.com> 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 <nop.head@gmail.com> 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 <thehans@gmail.com> wrote: >> >>> The default imagemagick arguments can be seen here: >>> 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 >>> On Sat, Sep 22, 2018 at 12:03 PM Marius Kintel <kintel@kintel.net> >>> 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 <nop.head@gmail.com> 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 <nop.head@gmail.com> 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 >>> > Discuss@lists.openscad.org >>> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> > >>> > _______________________________________________ >>> > OpenSCAD mailing list >>> > Discuss@lists.openscad.org >>> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >> >> >

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 <nop.head@gmail.com> 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 <nop.head@gmail.com> 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/op >> enscad/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 <nop.head@gmail.com> 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 <thehans@gmail.com> wrote: >>> >>>> The default imagemagick arguments can be seen here: >>>> 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 >>>> On Sat, Sep 22, 2018 at 12:03 PM Marius Kintel <kintel@kintel.net> >>>> 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 <nop.head@gmail.com> 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 <nop.head@gmail.com> 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 >>>> > Discuss@lists.openscad.org >>>> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> > >>>> > _______________________________________________ >>>> > OpenSCAD mailing list >>>> > Discuss@lists.openscad.org >>>> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>> >>> >> >

Roger. 

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. -- ** R.E.Wolff@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.