I am using surface to load png images. There are a couple of ways that
the results are not as I expected based on the wikibooks user manual. I
have distilled the problematic images down to a simple 3 colour
checkerboard file, test.png inserted below, with two white squares as
rgb 255, 255, 255, one gray as rgb 127, 127, 127, one black as rgb 0,0,0.
Now that I know what's going on, I can see easy ways to circumvent these
two problems. However, because it took me a fairly long time to figure
out why my models weren't shaped as I expected, I'm interested to know
if the problems are bugs or documentation flaws.
Cheers,
Steve
test.png
Problem 1: using the single statement surface("test.png") produces a
shape with maximum z-value of 100 and minium of -1, whereas the
documentation tells me the image's colours will be mapped in the range 0
to 100. It seems that OpenSCAD has perhaps added a base layer/footprint
below the entire shape.
Why does this happen? Is it a necessary/intended behaviour that perhaps
ought to be mentioned in the documentation?
Problem 1 screenshot
Problem 2: using the single statement surface("test.png", invert = true)
gives a shape that is entirely below the z = 0 plane. The documentation
says that the invert parameter "inverts how the color values of imported
images are translated into height values". To me, that wording means the
z values should be calculated using the complement in 100 of the value
obtained from the imported pixel (height = 100 - imported). The heights
would then be in the range 100 to 0, so the shape would still be above
the z = 0 plane.
Again, is actually OpenSCAD carrying out intended behaviour? If so,
should the documentation state that the entire shape is displaced
downwards by the invert=true setting?
Problem 2 screenshot
I observed the same issue this past week. It is inconvenient. However, in
my particular use case this time, I was able to difference that footprint
out. Would be nice if it did not happen, though.
On Tue, Sep 24, 2024, 8:10 PM Steve Lelievre via Discuss <
discuss@lists.openscad.org> wrote:
I am using surface to load png images. There are a couple of ways that the
results are not as I expected based on the wikibooks user manual. I have
distilled the problematic images down to a simple 3 colour checkerboard
file, test.png inserted below, with two white squares as rgb 255, 255, 255,
one gray as rgb 127, 127, 127, one black as rgb 0,0,0.
Now that I know what's going on, I can see easy ways to circumvent these
two problems. However, because it took me a fairly long time to figure out
why my models weren't shaped as I expected, I'm interested to know if the
problems are bugs or documentation flaws.
Cheers,
Steve
test.png
Problem 1: using the single statement surface("test.png") produces a shape
with maximum z-value of 100 and minium of -1, whereas the documentation
tells me the image's colours will be mapped in the range 0 to 100. It seems
that OpenSCAD has perhaps added a base layer/footprint below the entire
shape.
Why does this happen? Is it a necessary/intended behaviour that perhaps
ought to be mentioned in the documentation?
Problem 1 screenshot
Problem 2: using the single statement surface("test.png", invert = true)
gives a shape that is entirely below the z = 0 plane. The documentation
says that the invert parameter "inverts how the color values of imported
images are translated into height values". To me, that wording means the z
values should be calculated using the complement in 100 of the value
obtained from the imported pixel (height = 100 - imported). The heights
would then be in the range 100 to 0, so the shape would still be above the
z = 0 plane.
Again, is actually OpenSCAD carrying out intended behaviour? If so, should
the documentation state that the entire shape is displaced downwards by the
invert=true setting?
Problem 2 screenshot
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I don't have anything before 2021.01 to test, but I think the answer has
to be that it's been that way for a long time and whether or not it was
deliberate behavior in the past, it's the behavior now and the fact
that it's not adequately explained is a documentation bug.
Sounds fair.
I’ll have a go at editing the Wiki book.
On Wed, 25 Sep 2024 at 13:01, Jordan Brown openscad@jordan.maileater.net
wrote:
I don't have anything before 2021.01 to test, but I think the answer has
to be that it's been that way for a long time and whether or not it was
deliberate behavior in the past, it's the behavior now and the fact that
it's not adequately explained is a documentation bug.
Behaves the same in 2015.03-2
From: Jordan Brown via Discuss [mailto:discuss@lists.openscad.org]
Sent: Thu, 26 Sep 2024 06:02
To: OpenSCAD general discussion Mailing-list
Cc: Steve Lelievre; Jordan Brown
Subject: [OpenSCAD] Re: Confusing behaviour from 'surface'
I don't have anything before 2021.01 to test, but I think the answer has to be that it's been that way for a long time and whether or not it was deliberate behavior in the past, it's the behavior now and the fact that it's not adequately explained is a documentation bug.