discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Confusing behaviour from 'surface'

SL
Steve Lelievre
Wed, Sep 25, 2024 1:09 AM

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 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
LM
Leonard Martin Struttmann
Wed, Sep 25, 2024 3:07 AM

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 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 >
JB
Jordan Brown
Wed, Sep 25, 2024 8:01 PM

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.

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.
SL
Steve Lelievre
Wed, Sep 25, 2024 8:08 PM

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.

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. > >
MM
Michael Marx (spintel)
Thu, Sep 26, 2024 1:37 AM

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.

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.