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:

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:

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

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:whmean]", "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:

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:

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:

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:

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:

On Sun, Sep 23, 2018 at 12:44:42PM +0100, nop head wrote:

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.

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 torleif.ceder@gmail.com wrote:

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

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

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.

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

Yes, easy, but I have found that a side effect of accessing the ColorMap
class early is to make the GUI lock up at the splash screen.

On 24 September 2018 at 14:24, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:

On Mon, Sep 24, 2018 at 02:39:09PM +0100, nop head wrote:

So... Not easy then. :-)

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.

The problem is moving this code from cmdline() to main() because ColorMap
needs application path to registered.

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

Having two QT app instances seems to be a problem, no surprise there! Is
there a reason for preferring the QT version? The boost version produces
the same path on my system so using that solves the problem.

On 24 September 2018 at 14:39, nop head nop.head@gmail.com wrote:

Actually there is no currently selected colourscheme when using the command
line. The default is hard coded to cornfield, regardless of what is
selected in the GUI.

On 24 September 2018 at 15:03, nop head nop.head@gmail.com wrote:

On 09/24/2018 04:03 PM, nop head wrote:

The current code might be just for legacy reasons, but there are various
issues with boost on Windows regarding hard-links and non-ascii path.
I don't know if the toLocal8Bit() from Qt is better, but it might actually
help in those cases. Otherwise it would be nicer to just have a single
way to determine the path.

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

ciao,
Torsten.

The way it currently works is if it runs the GUI then it gets the
application path from the OpenSCADApp instance. If it runs the command line
version it instantiates a QCoreApplication app and uses that. Only if it is
compiled without QT does it use the boost version.

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

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

Can anybody see a problem with this hack?

On 24 September 2018 at 18:28, Torsten Paul Torsten.Paul@gmx.de wrote: