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

nop head nop.head at gmail.com
Sat Sep 22 15:00:00 EDT 2018

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/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 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/20180922/2faeef7b/attachment.html>

More information about the Discuss mailing list