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

nop head nop.head at gmail.com
Sun Sep 23 06:11:36 EDT 2018


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/9b8e5f72/attachment.html>


More information about the Discuss mailing list