[OpenSCAD] Light source and default camera position different on command line

nop head nop.head at gmail.com
Sun Sep 23 06:44:39 EDT 2018


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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.openscad.org
>>> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>> >
>>> > _______________________________________________
>>> > OpenSCAD mailing list
>>> > Discuss at lists.openscad.org
>>> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> Discuss at lists.openscad.org
>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180923/345b3db1/attachment.html>


More information about the Discuss mailing list