Colors and boolean operations

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Colors and boolean operations

JordanBrown
I was just trying to get the colors right on some of my models, and found that I hadn't properly understood how color interacts with intersection and difference, and the documentation doesn't say.  My mental model was completely wrong.

It seems like the rule is that a surface resulting from a boolean operation gets the color of the object that contributed that surface.

Thus, for instance, if you use difference() { something(); cylinder() } to drill a hole though something, the resulting hole is the color of the cylinder.  If you intersection() { cube(10); sphere(10); }, the flat parts will get the color of the cube while the curved parts get the color of the sphere.

Another way to look at it is that colors are painted onto surfaces - including negative surfaces - and are not at all properties of the volumes enclosed.

With the special case that the default is a different color for the subtrahend in difference().

For (better) completeness, I checked hull, minkowski, and resize.  They all seem to reset the color to the default.

I'd like to update the documentation to reflect this behavior.  Is what I say above reasonably correct?  Does anybody have anything to add?

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Colors and boolean operations

tp3
On 05.04.20 23:23, Jordan Brown wrote:
> I'd like to update the documentation to reflect this
> behavior.  Is what I say above reasonably correct?
>  Does anybody have anything to add?

The behavior is basically an artifact of the preview
algorithm, so it might even change when switching those
(I'm not sure about that).

So just documenting observed behavior is probably not
a good choice.

ciao,
  Torsten.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: Colors and boolean operations

adrianv
tp3 wrote

> On 05.04.20 23:23, Jordan Brown wrote:
>> I'd like to update the documentation to reflect this
>> behavior.  Is what I say above reasonably correct?
>>  Does anybody have anything to add?
>
> The behavior is basically an artifact of the preview
> algorithm, so it might even change when switching those
> (I'm not sure about that).
>
> So just documenting observed behavior is probably not
> a good choice.

This sort of issue has come up in the past, where the argument is made that
it's better to keep users guessing than to document the behavior "because it
might change".   It seems to me that for people trying to use OpenSCAD, it
is valuable to have documentation on what OpenSCAD actually does.  This idea
that we can't document its behavior because it might change just makes
everything harder on user who are trying to use it today, in its current
instantiation.  Programming environments change.  Then the fact of the
change gets (hopefully) gets documented, people fix their code, and life
goes on.   One could argue that any aspect of a programming language might
change someday, which would appear to be an argument for documenting
nothing!   I think it's much *easier* for people if the old behavior and
changed behavior are clearly documented than a mist of uncertainty.  If
there's an expectation that it might change, I suggest that it be documented
with a tag that "In version 19.05 colors are handled as follows.  This may
change in a later version."  





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Colors and boolean operations

tp3
On 06.04.20 00:50, adrianv wrote:
> This idea that we can't document its behavior because it might
> change just makes everything harder on user who are trying to
> use it today, in its current instantiation.

That is not what I said.

ciao,
  Torsten.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

New feature suggestion. Import PNG as background

boxcarmib
Probably lots of other issues that are higher priority, but I have thought for some time it would be useful to be able to import an image file as a useful guide to dimensioning objects from real life… this feature is available in illustrator and Inkscape and I think it would have utility in OpenSCAD as well. Don’t know how difficult it would be to implement, but I just offer it as a suggestion.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Colors and boolean operations

JordanBrown
In reply to this post by adrianv
On 4/5/2020 3:50 PM, adrianv wrote:
Programming environments change. Then the fact of the change gets (hopefully) gets documented, people fix their code, and life goes on.

Having worked on enterprise software[1] for the last 25 years, I'm very sympathetic to the need to maintain compatibility.  "People fix their code" plays quite poorly when the people involved have millions of lines of code and can't accept an upgrade until they've spent staff-years fixing and re-certifying their programs.  (Python 3.0 was released in 2008, and people are still converting software.  It looks like support for Python 2.x is finally being dropped this year, but that doesn't mean that it's dead.)

Documenting a behavior doesn't cast it in concrete, but if you've documented it then people will be justifiably upset if you then change it, especially for some invisible reason like "we're using a different library".  Left undocumented, the answer is that people shouldn't rely on the behavior, and if they do then it's on them.  One of the big rules, if you want to maintain compatibility, is not to document anything that you're not willing to commit to.  (Or mark it specially if it might change, but that doesn't work well.)

That said... OpenSCAD isn't the same class of product as Solaris or Python.  Projects aren't nearly as big.  I don't know how big other people's projects are, but mine is "only" ~9000 lines, and it's a hobby project, and if something goes slightly wrong somewhere in it I might never notice.  I'm sure there are some people using it for "mission critical" projects, but I expect that there are very few.  It's not a directly attackable program[3], so it's not like you need to stay at the bleeding edge to maintain security; if you have to stall upgrading for a year or two you're probably fine.  If there's a good reason for an incompatibility, I'd say it's OK.

In this particular case, I'd say that having colors and Boolean operations and *not* defining how the two interact is ... incomplete.  I'd say one should pick a definition and stick with it, unless a new definition comes along that is clearly better.  The current behavior[2] seems reasonable; if I were a developer I'd be willing to commit to it.

[1] https://en.wikipedia.org/wiki/Solaris_(operating_system) , https://www.oracle.com/storage/nas/
[2] Behavior of colors, that is.  Transparency appears to have problems.
[3] Which is not to say that it's not security-sensitive.  It's bad if a malicious OpenSCAD program can attack your system; people should be able to download OpenSCAD designs and execute them without fear.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Colors and boolean operations

nophead
The behaviour is that cut faces are the colour of the subtracted object but that doesn't make sense for 3D printing, so I always apply colour after all the boolean ops, so each solid is only ever one colour. If I want a surface to be a different colour, for example I recently made the machined face of my stepper motor model brighter, I add a thin object over the face. 

On Mon, 6 Apr 2020 at 00:53, Jordan Brown <[hidden email]> wrote:
On 4/5/2020 3:50 PM, adrianv wrote:
Programming environments change. Then the fact of the change gets (hopefully) gets documented, people fix their code, and life goes on.

Having worked on enterprise software[1] for the last 25 years, I'm very sympathetic to the need to maintain compatibility.  "People fix their code" plays quite poorly when the people involved have millions of lines of code and can't accept an upgrade until they've spent staff-years fixing and re-certifying their programs.  (Python 3.0 was released in 2008, and people are still converting software.  It looks like support for Python 2.x is finally being dropped this year, but that doesn't mean that it's dead.)

Documenting a behavior doesn't cast it in concrete, but if you've documented it then people will be justifiably upset if you then change it, especially for some invisible reason like "we're using a different library".  Left undocumented, the answer is that people shouldn't rely on the behavior, and if they do then it's on them.  One of the big rules, if you want to maintain compatibility, is not to document anything that you're not willing to commit to.  (Or mark it specially if it might change, but that doesn't work well.)

That said... OpenSCAD isn't the same class of product as Solaris or Python.  Projects aren't nearly as big.  I don't know how big other people's projects are, but mine is "only" ~9000 lines, and it's a hobby project, and if something goes slightly wrong somewhere in it I might never notice.  I'm sure there are some people using it for "mission critical" projects, but I expect that there are very few.  It's not a directly attackable program[3], so it's not like you need to stay at the bleeding edge to maintain security; if you have to stall upgrading for a year or two you're probably fine.  If there's a good reason for an incompatibility, I'd say it's OK.

In this particular case, I'd say that having colors and Boolean operations and *not* defining how the two interact is ... incomplete.  I'd say one should pick a definition and stick with it, unless a new definition comes along that is clearly better.  The current behavior[2] seems reasonable; if I were a developer I'd be willing to commit to it.

[1] https://en.wikipedia.org/wiki/Solaris_(operating_system) , https://www.oracle.com/storage/nas/
[2] Behavior of colors, that is.  Transparency appears to have problems.
[3] Which is not to say that it's not security-sensitive.  It's bad if a malicious OpenSCAD program can attack your system; people should be able to download OpenSCAD designs and execute them without fear.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Colors and boolean operations

cacb
On 2020-04-06 09:48, nop head wrote:
> The behaviour is that cut faces are the colour of the subtracted
> object but that doesn't make sense for 3D printing, so I always apply
> colour after all the boolean ops, so each solid is only ever one
> colour. If I want a surface to be a different colour, for example I
> recently made the machined face of my stepper motor model brighter, I
> add a thin object over the face.

Has anyone mentioned that colour is irrelevant for STL files?

Carsten Arnholm

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Colors and boolean operations

Ladislav Vaiz

> Has anyone mentioned that colour is irrelevant for STL files?

But not for 3MF!
Would be great to have one file for multimaterial print.

Lada

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: New feature suggestion. Import PNG as background

khackbarth
In reply to this post by boxcarmib
I love this suggestion!  I create designs for keyguards that aid individuals with disabilities in using their tablets.  I'd love to be able to import a screenshot of the tablet directly into OpenSCAD to verify the fit of the keyguard.  As it is now, I have to export a PNG of the design from OpenSCAD, import it into PowerPoint, go through the painful process in PP of cropping/resizing the image and removing the background, and then overlay the result on an imported version of the screenshot.

-----Original Message-----
From: Hugo Jackson <[hidden email]>
Sent: Sunday, April 5, 2020 5:03 PM
To: OpenSCAD general discussion <[hidden email]>
Subject: [OpenSCAD] New feature suggestion. Import PNG as background

Probably lots of other issues that are higher priority, but I have thought for some time it would be useful to be able to import an image file as a useful guide to dimensioning objects from real life… this feature is available in illustrator and Inkscape and I think it would have utility in OpenSCAD as well. Don’t know how difficult it would be to implement, but I just offer it as a suggestion.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Colors and boolean operations

JordanBrown
In reply to this post by nophead
On 4/6/2020 12:48 AM, nop head wrote:
The behaviour is that cut faces are the colour of the subtracted object

I think that's consistent with what I said.  (Remembering that the goal here is to make sure that I understand well enough to write some new documentation.)

but that doesn't make sense for 3D printing, so I always apply colour after all the boolean ops, so each solid is only ever one colour.

My 3DP stuff has different faces that are different colors.  I use a magic postprocessing technology called "paint" :-)

If I want a surface to be a different colour, for example I recently made the machined face of my stepper motor model brighter, I add a thin object over the face.

Yeah, I was thinking about that, or about using difference or intersection to cut away a thin slice.  I haven't had to do it yet, because mostly the objects I'm modeling are not painted and so any difference in color reflects an underlying difference in material and usually a geometric boundary, so using conventional objects is natural.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Colors and boolean operations

JordanBrown
In reply to this post by cacb
On 4/6/2020 1:02 AM, [hidden email] wrote:
Has anyone mentioned that colour is irrelevant for STL files?

Indeed it is.  But STL files are not the only form of output.  Color is good for visualization.  I admit that I do most of my modeling in the basic gold and apply color afterward, but it really does make it easier to look at and say "yes, that looks right".


vs

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Colors and boolean operations

doug.moen
On 4/6/2020 1:02 AM, [hidden email] wrote:
Has anyone mentioned that colour is irrelevant for STL files?

The more modern mesh formats allow you to specify colour information for full colour 3D printing. 3MF and OBJ allow to you specify a 2D image that is texture mapped onto the surface of a mesh. The code for texture mapping is difficult to implement, so I haven't tried that. X3D and VRML allow you to apply colour to either faces or vertices. That was much easier to implement, so I added a full colour X3D export facility to Curv (which is my post-OpenSCAD 3D modelling language), and I've used 2 different 3D printing service providers to print full colour models. Also, if you load the model into meshlab, it displays the colours.

The old technology was a full colour sandstone, printed on a Z-Corp printer, but the output was fragile and the colours a bit washed out. The new technology is the HP full colour jet fusion 3D printer. This prints full colour nylon, which is indestructible, and the colours are brighter, and it's also cheaper. You can use X3D or VRML formats with these service providers.

There's no inherent reason why OpenSCAD could not support these output formats as well, since OpenSCAD already has a means to specify and preview colour models.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Colors and boolean operations

OpenSCAD mailing list-2
Color will be more important for 3D printing as the availability of 4 color printing becomes more common.
There is a $1200 3D printer that appears to be able to print thousands of colors using CMYK.

Like the old days when printing on paper moved from spot colors to CMYK.

Ron
On 2020-04-06 5:20 p.m., Doug Moen wrote:
On 4/6/2020 1:02 AM, [hidden email] wrote:
Has anyone mentioned that colour is irrelevant for STL files?

The more modern mesh formats allow you to specify colour information for full colour 3D printing. 3MF and OBJ allow to you specify a 2D image that is texture mapped onto the surface of a mesh. The code for texture mapping is difficult to implement, so I haven't tried that. X3D and VRML allow you to apply colour to either faces or vertices. That was much easier to implement, so I added a full colour X3D export facility to Curv (which is my post-OpenSCAD 3D modelling language), and I've used 2 different 3D printing service providers to print full colour models. Also, if you load the model into meshlab, it displays the colours.

The old technology was a full colour sandstone, printed on a Z-Corp printer, but the output was fragile and the colours a bit washed out. The new technology is the HP full colour jet fusion 3D printer. This prints full colour nylon, which is indestructible, and the colours are brighter, and it's also cheaper. You can use X3D or VRML formats with these service providers.

There's no inherent reason why OpenSCAD could not support these output formats as well, since OpenSCAD already has a means to specify and preview colour models.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

-- 
Ron Wheeler
Artifact Software
438-345-3369
[hidden email]

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Colors and boolean operations

JordanBrown
In reply to this post by doug.moen
On 4/6/2020 2:20 PM, Doug Moen wrote:
There's no inherent reason why OpenSCAD could not support these output formats as well, since OpenSCAD already has a means to specify and preview colour models.

Well, kind of... and this ties into my questions about the definition of the behavior of color and boolean operators, and the reason that Torsten doesn't want to nail them down.

For rendering, you only need to color the faces.

For printing, you need to color the volume.  If you union two shapes of different colors, you need to define what color the overlapping volume gets.  For intersection, the color of the whole thing is in question.  Difference is the only easy one, since the negative objects don't yield any volume of their own.  Minkowski?  Hull?

I'm not saying that the definitions need to be tricky - maybe it's "first wins" - but the current face-centric behavior isn't enough, and probably isn't even compatible.

---

BTW, I thought that with coloring faces union was easy, but I was wrong: I forgot the case of shared faces.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Colors and boolean operations

doug.moen
On Mon, Apr 6, 2020, at 11:47 PM, Jordan Brown wrote:
On 4/6/2020 2:20 PM, Doug Moen wrote:
There's no inherent reason why OpenSCAD could not support these output formats as well, since OpenSCAD already has a means to specify and preview colour models.

Well, kind of... and this ties into my questions about the definition of the behavior of color and boolean operators, and the reason that Torsten doesn't want to nail them down.

For rendering, you only need to color the faces.

For printing, you need to color the volume.  If you union two shapes of different colors, you need to define what color the overlapping volume gets.  For intersection, the color of the whole thing is in question.  Difference is the only easy one, since the negative objects don't yield any volume of their own.  Minkowski?  Hull?

I'm not saying that the definitions need to be tricky - maybe it's "first wins" - but the current face-centric behavior isn't enough, and probably isn't even compatible.

If you are building colour support properly and correctly for a 3D printing CAD program, then I agree you should be colouring volumes. That's what I did in Curv*. And I've submitted a proposal on how to do this in OpenSCAD. But it's a big architectural change.

My point is that there is already a bunch of OpenSCAD code in the wild where people use the existing `color` command to colour faces. And users have created some pretty elaborate coloured models. For example, see Nop Head's work. If we decide to change how face colouring works, then all this existing code will break. I don't think we want to do that.

What this existing OpenSCAD code is doing is colouring faces (without any regard to volumes). As I pointed out, there are already mesh file formats that let you directly specify face colours. And there is already support for printing these files in full colour on existing 3D printers. So it would be possible to export colour to an X3D or VRML file using OpenSCAD's existing face colouring model. And then you could take existing colour OpenSCAD models found on the internet, and print them in colour, without rewriting the code to use a brand new volume colouring system.

Doug Moen.

*How volume colouring works in Curv:

The union operator uses "painters algorithm": each successive shape in the union overwrites the colours of previous shapes in areas where they overlap. It makes perfect intuitive sense in 2D, and 3D works the same way.

The intersection operator preserves the colours in the first shape. The second shape, and any shapes after that, specify what to subtract from the first shape.

I tried other designs, but this is what ended up being the most useful and natural.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Colors and boolean operations

JordanBrown
On 4/6/2020 5:26 PM, Doug Moen wrote:
My point is that there is already a bunch of OpenSCAD code in the wild where people use the existing `color` command to colour faces. And users have created some pretty elaborate coloured models. For example, see Nop Head's work. If we decide to change how face colouring works, then all this existing code will break. I don't think we want to do that.

We surely want to avoid it if practical.  We might need a way to specify which of two behaviors you want.

What this existing OpenSCAD code is doing is colouring faces (without any regard to volumes). As I pointed out, there are already mesh file formats that let you directly specify face colours. And there is already support for printing these files in full colour on existing 3D printers. So it would be possible to export colour to an X3D or VRML file using OpenSCAD's existing face colouring model. And then you could take existing colour OpenSCAD models found on the internet, and print them in colour, without rewriting the code to use a brand new volume colouring system.

So if you have a cube with different colors on each of its faces, what does this existing tool chain do?

(That's a serious question:  I want to document color behavior, but I don't want to document it in a way that causes problems for full-color printing in the future.)


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Colors and boolean operations

doug.moen
On Tue, Apr 7, 2020, at 12:42 AM, Jordan Brown wrote:

What this existing OpenSCAD code is doing is colouring faces (without any regard to volumes). As I pointed out, there are already mesh file formats that let you directly specify face colours. And there is already support for printing these files in full colour on existing 3D printers. So it would be possible to export colour to an X3D or VRML file using OpenSCAD's existing face colouring model. And then you could take existing colour OpenSCAD models found on the internet, and print them in colour, without rewriting the code to use a brand new volume colouring system.

So if you have a cube with different colors on each of its faces, what does this existing tool chain do?

(That's a serious question:  I want to document color behavior, but I don't want to document it in a way that causes problems for full-color printing in the future.)


When you 3D print a mesh file that specifies surface colouring only (not volume colouring), then the slicing software arbitrarily figures out a way to apply colour so that the surface of the object looks the way you specified. You have no control over how colour is applied to material in the interior of the printed object, you are only controlling surface colour. As a corollary, this only works well for opaque materials.

When I do this, I typically create models with up to a million faces, so that I can create smooth colour gradients and other kinds of imagery on the surface of the model.

The following image gives an idea of what I'm talking about:



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Colors and boolean operations

OpenSCAD mailing list-2
In reply to this post by doug.moen
There are lots of examples where software has defined previously undefined behavior and made developers change their applications.

That is what Release Notes are for.

It is more forgivable to define some behavior that was not previously defined than it is to change a previously documented behavior.
You can look at almost any mature, successful software project and find a release that caused some grief for early adopters by changing previously documented functionality.
Search "Java deprecated" if you doubt this.

The main thing is to make the software better so that the grief to existing users who have "imagined" a spec where none existed or followed a path that needs to be abandoned, is worthwhile in terms of the long term value of the project. If you can provide a script conversion to help upgrade existing designs, that is really helpfull.

Ron


On 2020-04-06 8:26 p.m., Doug Moen wrote:
On Mon, Apr 6, 2020, at 11:47 PM, Jordan Brown wrote:
On 4/6/2020 2:20 PM, Doug Moen wrote:
There's no inherent reason why OpenSCAD could not support these output formats as well, since OpenSCAD already has a means to specify and preview colour models.

Well, kind of... and this ties into my questions about the definition of the behavior of color and boolean operators, and the reason that Torsten doesn't want to nail them down.

For rendering, you only need to color the faces.

For printing, you need to color the volume.  If you union two shapes of different colors, you need to define what color the overlapping volume gets.  For intersection, the color of the whole thing is in question.  Difference is the only easy one, since the negative objects don't yield any volume of their own.  Minkowski?  Hull?

I'm not saying that the definitions need to be tricky - maybe it's "first wins" - but the current face-centric behavior isn't enough, and probably isn't even compatible.

If you are building colour support properly and correctly for a 3D printing CAD program, then I agree you should be colouring volumes. That's what I did in Curv*. And I've submitted a proposal on how to do this in OpenSCAD. But it's a big architectural change.

My point is that there is already a bunch of OpenSCAD code in the wild where people use the existing `color` command to colour faces. And users have created some pretty elaborate coloured models. For example, see Nop Head's work. If we decide to change how face colouring works, then all this existing code will break. I don't think we want to do that.

What this existing OpenSCAD code is doing is colouring faces (without any regard to volumes). As I pointed out, there are already mesh file formats that let you directly specify face colours. And there is already support for printing these files in full colour on existing 3D printers. So it would be possible to export colour to an X3D or VRML file using OpenSCAD's existing face colouring model. And then you could take existing colour OpenSCAD models found on the internet, and print them in colour, without rewriting the code to use a brand new volume colouring system.

Doug Moen.

*How volume colouring works in Curv:

The union operator uses "painters algorithm": each successive shape in the union overwrites the colours of previous shapes in areas where they overlap. It makes perfect intuitive sense in 2D, and 3D works the same way.

The intersection operator preserves the colours in the first shape. The second shape, and any shapes after that, specify what to subtract from the first shape.

I tried other designs, but this is what ended up being the most useful and natural.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

-- 
Ron Wheeler
Artifact Software
438-345-3369
[hidden email]

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Colors and boolean operations

adrianv
OpenSCAD mailing list-2 wrote

> There are lots of examples where software has defined previously
> undefined behavior and made developers change their applications.
>
> That is what Release Notes are for.
>
> It is more forgivable to define some behavior that was not previously
> defined than it is to change a previously documented behavior.
> You can look at almost any mature, successful software project and find
> a release that caused some grief for early adopters by changing
> previously documented functionality.

Yeah, well, we had four years between the current release and the last one,
I believe?   So the software isn't exactly in a rapid state of change.  

Also the "manual" is a wiki that anybody can write to, not exactly a
specification.  This is a little different than the situation with Java or
Python.  And I think a larger fraction of OpenSCAD's behavior is not
described in the manual.  So it's unclear whether one should assume that
observed behavior will stay the same or that it might change, but in at
least some cases (e.g. this question of colors) you have to write code that
makes use of the existing behavior because....that's what OpenSCAD does.  
If you don't document existing behavior then if it does change later,
someone with a some broken code will have no clue how to fix it because they
won't have any reference that indicates what the old behavior was.





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
123