Colors and boolean operations
On 07.04.20 16:52, Ron Wheeler via Discuss wrote:
If accessing hidden implementation details becomes a
common practice needed by many users of an API, then
the parts of the implementation that are needed should
be formally exposed in the API and documented.
Agreed, and that's what happens. The type test functions
are a good example.
Not really the case that I was talking about.
My point is really about an accidental misunderstanding
of the API resulting from an unintended behavior that
violates the intention of the API and is not documented
officially but has crept into the folklore of the user
community.
I don't follow. It just makes it harder to change/fix,
but otherwise the issue is the same. Extra promotion
of the unintended use does not seem useful, instead
a deprecation warning might be the only way forward.
ciao,
Torsten.
Going back to the colors thing, the question here is whether the current
behavior is what we want it to be. If it is then great, we can document
it and consider it to be a requirement for future changes. If it isn't
then we shouldn't document it, or we should document it with big caveats.
My biggest concern is the "face coloring" vs "volume coloring"
question. The current face coloring behavior is quite convenient, but
isn't compatible with truly correct handling of multicolor 3D printing.
(And, it occurs to me, for multi-material printing. There should
perhaps be another color-like property for material selection,
orthogonal to color.)
Should we leave it undocumented? Should we explicitly document it as
undefined? Should we document it with a caveat that it's likely to
change? Should we document it and plan to require a switch in the
future to support volume coloring?
On 4/7/2020 5:58 AM, Ron Wheeler via Discuss wrote:
Isn't "observed behavior that is not part of the designed
functionality" the actual definition of a bug.
No (and in a different way than Torsten mentioned). Often there will be
cases that are formally undefined behavior, where the observed behavior
is something that you might want to rely on. For instance, in
JavaScript the order of enumeration of the elements of an object is
formally undefined, but in some implementations it is reliably the same
as the order that the elements were added. It's very easy to
accidentally depend on this behavior, or to deliberately depend on it
without realizing that it's not a designed-in feature.
Going back to the colors thing, the question here is whether the current
behavior is what we want it to be
Currently colour only shows in the preview. I think the side effect of the
OpenCSG algorithm that colour faces cannot be used for 3D printing because
OpenCSG only produces pixels. The generated geometry that is output to STL
files does not have access to these coloured faces. It would have access to
the color() value that is applied to 2D or 3D solids.
On Tue, 7 Apr 2020 at 19:20, Jordan Brown openscad@jordan.maileater.net
wrote:
On 4/7/2020 5:58 AM, Ron Wheeler via Discuss wrote:
Isn't "observed behavior that is not part of the designed functionality"
the actual definition of a bug.
No (and in a different way than Torsten mentioned). Often there will be
cases that are formally undefined behavior, where the observed behavior is
something that you might want to rely on. For instance, in JavaScript the
order of enumeration of the elements of an object is formally undefined,
but in some implementations it is reliably the same as the order that the
elements were added. It's very easy to accidentally depend on this
behavior, or to deliberately depend on it without realizing that it's not a
designed-in feature.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 07.04.20 20:19, Jordan Brown wrote:
Should we leave it undocumented? Should we explicitly
document it as undefined? Should we document it with a
caveat that it's likely to change? Should we document
it and plan to require a switch in the future to support
volume coloring?
I think something along the lines of what nophead suggested
earlier would be a good start.
It's probably quite important to highlight the differences
between preview (which always will have some kind of
restrictions depending on the algorithm used and can't
really do volumetric coloring as the information is simply
not there) and actual render (where color is currently not
implemented, but would be nice to have - in a clearly
defined behavior).
ciao,
Torsten.
On 4/7/2020 11:29 AM, nop head wrote:
Going back to the colors thing, the question here is whether the
current behavior is what we want it to be
Currently colour only shows in the preview. I think the side effect of
the OpenCSG algorithm that colour faces cannot be used for 3D printing
because OpenCSG only produces pixels. The generated geometry that is
output to STL files does not have access to these coloured faces. It
would have access to the color() value that is applied to 2D or 3D solids.
Sure, but (a) it seems like we would eventually like the "full render"
to be capable of exporting color information, and (b) at that point it
would be bad if preview and full render behaved differently.
Net, even though only preview supports color today, it seems ill-advised
to commit to behavior that we wouldn't want for full render.
Or maybe I'm not understanding your point.
On 4/7/2020 11:38 AM, Torsten Paul wrote:
I think something along the lines of what nophead suggested earlier
would be a good start.
So that would be "document with a caveat".
It's probably quite important to highlight the differences
between preview (which always will have some kind of
restrictions depending on the algorithm used and can't
really do volumetric coloring as the information is simply
not there) and actual render (where color is currently not
implemented, but would be nice to have - in a clearly
defined behavior).
The algorithm presumably won't just change on us. We could decide that
we have certain requirements for the algorithms, and won't accept
algorithms that don't meet those requirements. (As a perhaps-too-silly
example, we wouldn't accept an algorithm that didn't do hidden-line
removal.)
Perhaps we're only talking about what the primary, default, preview
algorithm does. We can certainly have other algorithms with other
behaviors (e.g. wireframe) available as secondary options, with
documented behaviors and restrictions.
I was going to say that I didn't see what difference volumetric coloring
would have on preview, but I realized a couple of cases where it could
matter. First, if you move your viewpoint inside an object, there's the
question of whether you see nothing, or see the inside of the faces.
Second, proper transparency support would presumably mean that for a
given transparency value, a thicker object would be less transparent
than a thinner one.
What I am saying is the current preview behaviour isn't what we want for
outputting coloured 3D objects. The way I colour my models is to apply
color() to the top level so each solid is unambiguously one colour. I avoid
the odd preview behaviour and if render ever outputs coloured 3D objects I
would expect it to honour the color() module. What happens when you union
two different colours won't affect my models because I always apply colour
after CSG ops.
So I avoid anything which might be undefined behaviour. If I ever get to
printing objects with material gradients in them I would need to do
something different and OpenSCAD would need a different colour model to
support it, however it could relatively easily apply colour() to exported
geometry where each solid is all one colour.
On Tue, 7 Apr 2020 at 20:27, Jordan Brown openscad@jordan.maileater.net
wrote:
On 4/7/2020 11:38 AM, Torsten Paul wrote:
I think something along the lines of what nophead suggested earlier would
be a good start.
So that would be "document with a caveat".
It's probably quite important to highlight the differences
between preview (which always will have some kind of
restrictions depending on the algorithm used and can't
really do volumetric coloring as the information is simply
not there) and actual render (where color is currently not
implemented, but would be nice to have - in a clearly
defined behavior).
The algorithm presumably won't just change on us. We could decide that we
have certain requirements for the algorithms, and won't accept algorithms
that don't meet those requirements. (As a perhaps-too-silly example, we
wouldn't accept an algorithm that didn't do hidden-line removal.)
Perhaps we're only talking about what the primary, default, preview
algorithm does. We can certainly have other algorithms with other
behaviors (e.g. wireframe) available as secondary options, with documented
behaviors and restrictions.
I was going to say that I didn't see what difference volumetric coloring
would have on preview, but I realized a couple of cases where it could
matter. First, if you move your viewpoint inside an object, there's the
question of whether you see nothing, or see the inside of the faces.
Second, proper transparency support would presumably mean that for a given
transparency value, a thicker object would be less transparent than a
thinner one.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 4/7/2020 1:05 PM, nop head wrote:
What I am saying is the current preview behaviour isn't what we want
for outputting coloured 3D objects.
That's a nice unambiguous statement. I interpret it to mean that
documentation should be somewhere between just saying "don't use these
two features together, results are expected to change" and "current
behavior is XXX but is expected to change".
The way I colour my models is to apply color() to the top level so
each solid is unambiguously one colour. I avoid the odd preview
behaviour and if render ever outputs coloured 3D objects I would
expect it to honour the color() module. What happens when you union
two different colours won't affect my models because I always apply
colour after CSG ops.
But you said that when you want a face that's a different color you
union on a thin sliver of the other color.
And yes, I would expect that a future colored-object render would honor
the color() module. (Whatever that means for the boolean cases.)
So I avoid anything which might be undefined behaviour. If I ever get
to printing objects with material gradients in them I would need to do
something different and OpenSCAD would need a different colour model
to support it, however it could relatively easily apply colour() to
exported geometry where each solid is all one colour.
Yes. (Give or take the boolean cases.)
You bring up an interesting point - eventually, it would be good to have
gradient support.
Speaking as a user (as opposed to somebody trying to figure out what to
document), I don't want to live with "each solid is one color". Most of
my models are single solids, but because they are models of real-world
objects I want to be able to "paint" them with different colors. The
barn model that I've shown is one example - that model is only three
solids, one of which you can't see from the outside. (It's the body of
the barn, the roof, and a loft.) I would be unhappy at not being able
to paint the various parts differently.
I'd call it a requirement that if you union two solids of different
colors, each face retains its original color. (Coincident faces can be
undefined behavior - and currently cause Z-fighting.)
Concrete proposal...
color(): The behavior of colors with respect to multi-object operations
is described under the documentation for the particular operation. (Do
I need to list them? Union, intersection, difference, hull, minkowski.
Resize and render merit special note. Any others?) Note that the
current behavior is to color faces only and the enclosed volumes are not
colored. The color() transformation itself discards the colors of its
children. Comment that colors currently only work for preview and not
for render, and therefore are not exported in 3D exports.
union(): Faces from each object retain their original color.
Coincident faces of different colors get undefined behavior.
intersection(): Undefined behavior, likely to change.
difference(): Undefined behavior, likely to change.
Note: for the following the current behavior is to discard color
information. It's hard to see how anybody could reasonably rely on
that, but just in case it seems best to define it as undefined
behavior. That also leaves a placeholder for defining the behavior in
the future.
hull(): Undefined behavior.
minkowski(): Undefined behavior.
resize(): Undefined behavior.
render(): Undefined behavior.
linear_extrude(): Undefined behavior.
rotate_extrude(): Undefined behavior.
I'll find some way to limit the UB - it's not going to crash or
anything, but we don't promise what color you'll get.
Note that UB allows for a future version that, for instance, preserves
color information across render().
What do people think?
For the UB cases, should I document the current behavior? My
inclination is "no".