On my slicer, when |i open a file, it lwwks for several types of files,
STL, being one of them. Look at the extension, google them and you will
discover you are not the first :-)

fre. 10. sep. 2021 14.00 skrev Rogier Wolff R.E.Wolff@bitwizard.nl:

On Friday 10 September 2021 08:03:18 Michael Möller wrote:

I use cura, which can make multiple copies or even several different
parts by re-arranging them on the build plate. Such would be usefull in
production because it would bypass the several minute warmup and
recalibration times when doing it in series.  I tried it, once, got so
much stringing even with a 3mm retraction on my prusa mk3s direct drive,
the neither part was useable.

cura's changes are for the duration of that power up of cura, So I don't
have to redo them to restart a job. And you can make them permanent even
over a reboot.

Cheers, Gene Heskett

"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.

• Louis D. Brandeis
  Genes Web page http://geneslinuxbox.net:6309/gene

On 10.09.21 11:36, Rogier Wolff wrote:

Slic3r had something like that for AMF. But that format is dead,
so it's unlikely to be added to AMF on OpenSCAD side.

3MF does support that too I think but I'm not sure regarding
support on side of slicers for annotations.

OpenSCAD does not have any support for annotations yet, that would
be a very interesting addition.

ciao,
Torsten.

Ok, here's a weird workaround....

In OpenSCAD, create text that contains your annotation.  Do not
place/attach it to any existing part, have the text just floating in the
air.

Place it in one of several ways:

• Make the attributes text thinner than a layer so that it gets deleted when sliced.
  You'll have to play aroud to see if this will work.

• Below the Z-0 plane if your slicer shows that and it doesn't mess with your workflow
  (I'm using chitubox for my resin prints and this would be visible but would also mess with my workflow as adding supports forces the entire model up above Z=0.)

• Outside the printable volume of your printer.  i.e. All the way to the left.  Possibly create super thin lines pointing to the text, but make the lines so thin they will slice to 0.  So, like, thinner than a layer.

• Create the attributes as a seperate STL and name it something like "filenameATTRIBUTES.stl" and load it alongside your object.
  I THINK, but have never tried, that you can set something up so that the attributes model will be generated and saved automatically as a seperate file when you compile.
  If not, add a "GENERATE_ATTRIBUTES" variable at the top of your file, and start the body with an "IF GENERATE_ATTRIBUTES=true" check and either create the attributes model or the real model based on that.  Compile twice, switching this flag, and save each model.

I use PrusaSlicer, which stores this kind of information in a 3MF file.
https://blog.prusaprinters.org/3mf-file-format-and-why-its-great_30986/

This blog post contains ample information about why 3MF is a much better format than STL. 3MF has annotations, and it also eliminates ambiguities in STL concerning self-intersection, and waterproof meshes that are considered ambiguous because they aren't "manifold".

Doug Moen.

On Fri, Sep 10, 2021, at 9:25 AM, Torsten Paul wrote:

Hi Rogier,

I'm not sure why this would be better than the existing filing system.
You can create a folder or directory or cabinet (whatever terminology
your os prefers) and give it the name of your project. Then save each
stl in that folder. You can have meaningful name/tags/whatever in the
file name, up to a few hundred characters in some instances. If you want
more info, then save a plain text file, or a qr code if you wish. When
you want to slice it, then call in whatever files you want. If there are
tags that you can put inside the file, along with its y,y,z info, - does
slic3r read that, unless it reads 3mf files, or similar. I don't think
it can look for 'comments' embedded in stl files. You can add
information,  or comments, to the g-code, once sliced, and the printer
reacts to that.  So, I think, if essential, then with a a bit of an
effort, then you could read/display text associated with an stl, but
getting a slicer to act on that text, could be tricky. But, more
difficult would be marking that point on the original stl file.

On 10/09/2021 10:36, Rogier Wolff wrote:

lør. 11. sep. 2021 23.02 skrev Jordan Brown openscad@jordan.maileater.net:

That is a surface attribute, so what everything inside should be, is
ambigous, especially where they intersect. (I have a dual head printer and
am aware of workarounds and further problems)

The infill is more interesting, for me at least, to specify that this
module/primitive should have infill "high" and the other only
"medium"/"light".  Some way of specifying "priority" where they overlap is
needed.

I have the impression that some slicers allow you to specify a volumetric
region of your model with specific infill, but see that more of a
post-render-patch solution.

Anyhow, we need a new "standard" file format, but seems long time comming
into mainstream.

On 9/11/2021 3:52 PM, Michael Möller wrote:

It is today an attribute of the surfaces.  But is that truly right?

It sure seems to me that it would be best, in the long run, for it to be
a volumetric attribute, with rules about what that means for the various
operations.  I would not want to have to invent a different mechanism to
support multicolor printing.

IMHO,

As far as OpenSCAD goes, it is surface as you dont see the "insides" of a
F5 render, but a 3D printer only prints "insides" (with one side of the
outer shell being the surface,  so to speak.) Further, a STL file is only
infinitly thin triangles defing the surface/boundary. In an intersection
between two "solids", which object defines the properties of the middle?

I'll gladly admit it's a mess, defenition wise. A standard will make an
arbitary decision, but it would be an nonambigous standard one can refer to
or work around/with.

søn. 12. sep. 2021 01.12 skrev Jordan Brown openscad@jordan.maileater.net:

On 9/11/2021 4:34 PM, Michael Möller wrote:

All of that can be viewed as implementation detail.

Indeed.  And in a union, what defines the properties of the common volume?

But one can standardize an answer for those questions, and we should. 
The obvious fundamental answers are "first wins" and "last wins".

The result will necessarily be incompatible with current F5 behavior,
because current F5 behavior produces multi-color objects for
intersection and difference.  But current F5 behavior is undocumented,
deliberately so - I started, a while back, to document it, and was told
"no, we don't want to commit to that, because we might want to do
something different".

In a choice between preserving compatibility for an undocumented and
mildly obscure case, and defining straightforward support for
multi-color printing, I know which way I'd go.

On Sat, Sep 11, 2021 at 09:02:12PM +0000, Jordan Brown wrote:

Ohh. Nice!

So this means I can do:

module infill (v=100)
{
annotate("Metadata/Slic3r_PE.config", "fill_density", str (v, "%"))
children ();
}

p=12;
for (i=[1:1:10])
translate ([ip, 0,0]) infill (i10) cube (10);

This would allow me to test different infill settings in one printjob.
Also note that with just the "annotate" primitive, a simple include
can make things "userfriendly".

Now if the slicer can already handle the per-object infill setting,
that would be nice. If not, I would really recommend that we just
start outputting that option and make it "their fault" for not being
able to handle it....

But even just the "infill" tag that provides a default for the slicer
is nice. People are "sharing" STL files of things they make, but I
consider those "intermedate files". I keep and backup the .scad files
the STLs can be regenerated.

So in my current project an infill of 5% works nice. Adding that tag
to the object in openscad would mean that in the future when I go back
to this project, I don't need to figure this out again.

On the slicer of course I could save the current config under the name
of this project, so that I can go back to these settings later on. But
in my experience my skills in configuring the slicer slowly improve,
so next time I'll have found and improved a generic setting that
improves all prints and going back to what I used last year is not an
option.

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

On Sat, Sep 11, 2021, at 8:15 PM, Jordan Brown wrote:

Curv is a volumetric solid modelling language, where colour is applied to each point in the interior of a solid, as well as on the surface. I use it for colour 3D printing. After some experimentation, I settled on what felt like the most natural model:

In a union, the last shape in the union wins (for determining colours in the result). For unioning a list of 2D shapes, this means that each successive shape appears to be "painted" on top of previous shapes.

In an intersection, the first shape in the intersection wins. Successive shapes after the first do not contribute any colour to the result, they are only used for subtracting their volumes from the first shape argument.

So I would recommend this design for a future version of OpenSCAD that supports colour printing.

Why not the first shape for union as well?  I most often start with the
main body of an object and then union on the twiddly bits. For example a
case panel with added screw pillars.

[image: image.png]

It would seem a bit odd having to colour the last pillar.

On Sun, 12 Sept 2021 at 10:01, Doug Moen doug@moens.org wrote:

In 3D, with full colour objects that have volumetric colour, the only difference between "first wins" and "last wins" in a union is the colour of the points inside the shape. The surface colours are the same in both cases, so you don't see any visible difference in a model like this (where all the shapes are opaque).

That's why I focussed on the 2D case in deciding what design feels most natural. In 2D graphics APIs, it is most common that the last shape you painted on the canvas is the one that "wins", just like applying brush strokes to a canvas in a physical painting.

Doug Moen.

On Sun, Sep 12, 2021, at 6:06 AM, nop head wrote:

On 9/12/2021 6:15 AM, Doug Moen wrote:

And in particular, the points inside the intersection of the two
objects, where it's not totally obvious which one should win.

I'd been thinking about union and intersection, and I agree that the two
rules you suggest (for union, last wins; for intersection, first wins)
individually produce the most obvious results.  I'm unhappy with the
fact that they have different rules, but maybe the obviousness argument
is compelling there.

Comments on other operations:

projection - heck if I know, in particular if there are two different
colors stacked in Z.

linear_extrude, rotate_extrude - seems like the 2D colors should
propagate into the third dimension.

offset (of two different-colored regions) - don't know.  Maybe
offset(A,B) is equivalent to union (offset(A), offset(B)), so that B's
color wins in the new overlap.  But I don't know whether offset(A,B) is
really equal to union(offset(A), offset(B)).

hull() - don't know.  Probably either first-wins or last-wins.  Or maybe
input colors are ignored.

minkowski() - maybe last-wins.  Or maybe the volume added matches the
object that added it, so that minkowski(A,B) has A in its original color
and anything additional in B.

Note that union(A,B) where A and B are different colors would still
produce one object, from an OpenSCAD child POV.  It would only be
considered to be multiple objects when exported to a multi-color-capable
format.

On 9/11/2021 11:31 PM, Rogier Wolff wrote:

Maybe.  I'm just working from looking at the file, not from looking at a
spec, but the file that includes fill_density appears to be project-global.

Indeed if we were to do something like this it should be capable of
doing either project-global attributes or object-specific attributes (or
even finer-grain than that, maybe).  Exactly what that would look like I
don't know.  Maybe there are two different calls for project-global
attributes and object-specific attributes, or maybe specifying an
attribute without any children makes it global.  (Which would be
convenient, but inelegant.)

Absolutely.  People who don't share their CAD files are closed-source.

Well, yeah, but that's just as much a problem if your settings are in
your OpenSCAD source file as if they are in your slicer-specific project
file.

But, in theory, if slicers could learn to accept the same attributes,
for at least some subset, it would make it easier to move from one
slicer to another.

On 9/12/2021 6:15 AM, Doug Moen wrote:

I agreed with you, but on reflection I think you might be mis-stating
something here.  I expect that you understand it correctly, but wrote
something a little wrong.

For nophead's case where the two colors are the same, agreed, there's no
difference.

But when you have the union of two different colors, there's ambiguity
not only in the interior but also at any shared surfaces.

union() {
    color("red") cube(10);
    color("blue") cube(10);
}

And today F5 will give you Z-fighting there.

On Sun, Sep 12, 2021 at 10:19:38PM +0000, Jordan Brown wrote:

When microsoft decides they want to add a feature to the
spreadsheet-import of Word. And that feature requires work on both
sides, they just tell a bunch of people to go and do the work on each
side.

With Open source it's not that simple. So to get to the point where
openscad can specify the infill of each separate object, and for that
to get printed that way we need support both in openscad and in the
slicer.

What we can't do is to tell the slicer guys to go build that at the
same time as that the openscad side is working on outputting the data
with the objects.

What I propose is that openscad starts being able to handle such
attributes internally, then output them with the export.

Now if the 3MF standard does not specify that you can add "infill" to
"object instances", that's too bad. The 3MF standard uses XML, that
language is meant to be extensible in that you can add tags that
readers can ignore. I expect that you can find a place to add the
"infill=30%" to an object instance where readers will accept it and
continue.

Now it is simply that the slicer guys haven't implemented a useful
feature! They are ignoring information that is presented to them!
Now they can see immediate benefits to implementing the feature.

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

On Mon, Sep 13, 2021 at 03:53:42PM +0000, Jordan Brown wrote:

Yeah, A mix would be most powerful: "See it, works, we're doing
it right, you're doing it right... But you don't support ... "

I was thinking that tagging the attributes on objects would be a
fundamental operation on openscad. But I just realized: Actually a
color is just such an attribute. It's just that the other attributes
can probably be ignored when rendering.

The thing is... the F5 render uses the color, but F6 loses them. That
might be a challenge to get the datastructures involved in the F6
render to keep the attributes.

Thinking about what namespace to use is useful, but could be postponed
until we're at the point that stuff is going to be put into files....
But preparations will never hurt.

IF we were to output openscad-infill: 30% then it will be difficult
for us to convince slicer teams to start interpreting them. They then
would also need to support fusion-infill freeCAD-infill
solidworks-infill autocad-infill etc etc. That's hopeless.

maybe a configurable prefix would allow for max flexibility (but
suggested default: None). That would allow users to get out of a
namespace collision on their own.

I think the most powerful way forward would be to just implement the
first and THEN say: "look we can propagate infill", do you agree
we should put it there?, what else would be useful?, etc.

Roger

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

I'm not sure what the 'ideal' solution would be, and one thing for sure,
whatever arises will not be ideal. Already dozens of 3d file formates
available. I would think that the best way forward would be to export
instead of stl, as perhaps 3mf or some other file standard which can
carry attributes, then hope that the slicer guys will implement that. If
Other 3d design programs use the same format, then we are in with a
chance. However, it could well be a case of backing the wrong horse, and
I expect that by the time that was working, there would be some other
preferred format.

Fundamentally, i wonder why, for many of us, we need to store the
information within the openscad file/3d file, if we have the control of
the slicing process. Perhaps we want to change colour part way up a tall
print, say. Not much of a problem, unless precision is wanted, but 3d
printing at the diy  level, is not exactly precise.

here are three examples

/ example 1
color("blue")cube (20);
translate([0,0,15])color("red")cube(20);

// example 2
translate([30,0.0]){
    color("blue")cube ([20,20,15]);
    translate([0,0,15])color("red")cube(20);
}

// example 3
translate([60,0.0]){
   cube ([20,20,35]);
//!! color("red")([0,0,15]);
}

you can often change colour, in any fdm printer, for example, by having
two stl files, and place them on top of each other. in the slicer.
However example 1, looks ok'ish in openscad, but once the blue is
printed, a bit of a problem will occur in printing the red   We would
have to make sure that the translate terminated the height of the blue,
or the red cube was shorter..

example 2 is doable, but possibly not the way it would be naturally
drawn in openscad

example 3, is what I'm more inclined towards -  parse the scad file,
pull out the //?? then  parse the g-code, calculate the xyz location and
do whatever is necessary, provided it is just code insertion in the the
gcode.

That will work, relatively easy for basic stuff, colour changes, insert
magnets/whatever. However it would be too much for me to think about if
the orientation/scale was changed in the slicer.

These examples are trivial, for a few changes it is easy enough to do it
manually, (tedious scrolling through thousands of lines of g-code) but I
think they show the sort of fun that can be had with what we have
available now.

Best wishes,

Ray

On 14/09/2021 07:01, Rogier Wolff wrote:

There is more than just colour (though it is a simple example). But
the first come or last come solution is obvious.

Just a "top of my head" list of other attributes:

• Infill
• Infill-pattern
• Layer height (needed where vertical detail is critical, but skippable
  where not - Slic3r tries to do this automagically)
• Support (meaning this module is manual support structure - for a
  multihead with soluble plastic)
• notSupport (hint to the slicer, don't do support beneath this - also
  implied for modules maked Support)
• Extra "quality" (basically asking a FDM slicer to go slower)
• ... and colour.

Colour or Support only makes sense for a multi head 3D printer. I have a
hard time thinking how/where/when a "pause" attribute would propage from
the OpenSCAD through the slicer and to the Gcode, but it might be a good
search string  for manual fiddling. Which leaves the most famous catch all

• the Comment (which invariably gets misused for things not in the
  standard).

If all parameters are keyword=text style, then only these few keywords need
"standardizing". Slicer variations become the headache of the OpenSCAD
owner (one slicer expects a 1-100% for infill, another expects a 0.1 - 1.0)

This is the wrong forum to ask - we're all OpenSCAD users and happy, but
how much of 3D print originates from OpenSCAD? 360Fusion, Blender, and so
on also generate files for printing - what have they tried to implement?
(NB:
https://all3dp.com/1/best-free-3d-printing-software-3d-printer-program/#section-3d-modeling-software
does not mention OpenSCAD) Easier to hitch onto someone else format (Open,
not proprietary! of course)

Hmmm... maybe I should do some reading/googling... more informed
suggestions might be better (and a new mail thread). We should rather
discuss the user requirements : what are we trying to solve? (The
OriginalPost had a point ... lost my copy) Then we can worry about how that
might be represented, and lastly one can discuss if it is OpenSCAD or the
slicer that should handle conflicting volumes and how that might be.

I really want sections of my models to have seperate infill values, I
really want some parts marked "non-critical", I have a two head; I want
easy colour (head1/head2) or manual support that the slicer knows is
support. Ah, well, I manage.

Msquare

On Tue, 14 Sept 2021 at 13:57, Ray West raywest@raywest.com wrote:

On 9/13/2021 11:01 PM, Rogier Wolff wrote:

Absolutely.  Today, F6 of this program

union() {
    color("red") cube(5);
    color("blue") sphere(5);
}

produces a single object.  With full color support, it would need to
produce, in some sense, two objects, a red one and a blue one.  Probably
it would be sort of equivalent to

color("red") difference() {
    cube(5);
    sphere(5);
}
color("blue") sphere(5);

except that from an OpenSCAD perspective it would still be a single child.

And that would have to propagate through all of the geometry processing,
so that

union() {
    union() {
        color("red") cube(5);
        color("blue") sphere(5);
    }
    color("green") cylinder(h=5,d=7);
}

would produce:

• A green cylinder.
• A blue sphere, less the cylinder.
• A red cube, less the cylinder and the sphere.

Not totally hopeless, but certainly suboptimal.  For something
relatively generic like this, those slicers could have a simple list of
aliases.  What would be hard would be if each CAD program had a subtly
different interpretation of the value.

And of course the flip side, where the slicer teams each have their own
attributes, would be poor for the CAD teams; every CAD program would
have to support prusa-infill, cura-infill, simplify-infill, et cetera.

Ideal would be if the 3MF Consortium managed a shared attribute
definition list.

Is anybody here already a member of the 3MF Consortium?

My transitional idea (before any real standardization) would be to have
a mechanism that can supply any name and any value, so that OpenSCAD per
se doesn't have to know about the attributes available.

On 9/14/2021 4:56 AM, Ray West wrote:

One might hope that we could come up with language and
geometry-processing features that are generic enough that their results
can be exported into any reasonable format.

Because then there are two distinct parts of the project that have to be
kept in sync.

Sure.  Or change the color of the text atop a card - and be able to
change the thickness of the card with the customizer and have the color
change track it.

Or any number of other variations, if you have a multi-extruder printer.

I don't know about anybody else's work, but only the most trivial of my
projects are amenable to external processing.  Figuring out where a
particular subcomponent is in the final object, or even what shape it
is, would require executing the OpenSCAD program.

You could do better by having an alternate mode for the OpenSCAD program
that would echo() slicing information.  You'd still need to figure out
how to post-process that output into configuration input for the
slicer.  Also, OpenSCAD modules don't naturally know the transformation
they are embedded in, so may not be able to easily emit the information
needed.

On Tue, Sep 14, 2021 at 04:37:36PM +0000, Jordan Brown wrote:

I think we should desing this from a language-point-of-view. Consider
3MF as a language, and what would be useful and "neat" (*) to have in
that language.

I think discussions with "authorities" would go easier and quicker
once there is a proof-of-concept demo available.

In my example of setting the infill for a specific project,
infill (5) mainobject ();

would suffice. No subobjects having such attributes and complex mixing
of said attributes....

The problem that triggered this for me was a case where I need to set
printing order. Again:
printing_priority (1) translate ([ 0,  0]) mainojbect ();
printing_priority (2) translate ([60,  20]) mainojbect ();
printing_priority (3) translate ([ 0, 100]) mainojbect ();
printing_priority (4) translate ([60, 110]) mainojbect ();

No mixing trouble.

Some simple inheritance rules "for now" with clear documentation
stating that this is temporary could be a workaround. So when you
union a red cube and a blue sphere, the resulting union would be red.
First attribute of a type is used, later ones ignored. (union a red
cube and a 10% infill sphere, you get a red 10% infill union).

Roger. 

(*) Neat, not as in "cool! I like that" but neat, as in regular with
the rest.

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

On 9/14/2021 10:24 AM, Rogier Wolff wrote:

https://docs.microsoft.com/en-us/windows-hardware/drivers/3dprint/output-keywords#42-job3ddensity

One has to wonder why they only allowed five levels (0, 10, 25, 50, 100)
rather than just letting you specify a fraction.

I don't understand the schema well enough to know whether you can apply
this attribute separately to different objects in the file.

Hi,

Cura slicer can import and export 3MF format files, i guess to the same
standard as some software handles dxf files. I expect slic3r and it's
forks do the same, or will do. Already you can vary the density of
infill in a slicer, by using support blockers, afaik. It is merely a
question of communicating the descriptions from openscad to the slicer,
the mechanics are almost there.

All this would be avoided if resin printing, no infill, no colour, no
size worth speaking of. It is easy to calculate one level of infill, and
one pattern, at least to start with, and in the real world five levels
are probably good enough, but what fill pattern, what skin thickness, etc?

Openscad, gcode and klipper commands are all plain text, so very easy to
check what is going on, and where. If you want all the information in
one file, it is possible to write a shell to combine them as one file,
and split them up as needed, but the danger of too much in one file, all
in one place, is in a year's time, when the filament is no longer made,
you have to start over. - granularity is important. All I would need to
keep, is the scad file, with its comments. Not sure if it is worth it
for me to change my cnc gcode editing software to automate the editing
of these 3d printing files.

I've tested the idea of using comments in openscad, and can get good
enough positions in the g-code file, for what I need, (but I've never
needed it, so far) so testing on a couple of encapsulated 5mm nuts in a
20 mm cube, I can pull out the following comments from my openscad file

//?? insert(5mm nut flat)([10,10,6.5])
//?? insert(5mm nut vertical){[6,6, 14.8])

and in the g code, somewhere after z 6.5 I put 'rw_insert 5mm nut flat'
and after z 14.5 put 'rw_insert 5mm nut vertical' (or I could put the
text exactly as after the //??)

When the g-code is read into the printer, then my Klipper gcode macro,
picks out the 'rw_insert' and displays the message  'insert 5mm nut
vertical'  on my pc (with a confirmation of the actual coordinates wrt
the bed), or phone and on the printer lcd display, sounds a beeper,
pauses the print, moves the head away. When I've put in the 5mm nut, I
send 'resume' and it carries on.  Or, it could drive a pick and place
robot arm. Not sure if placing magnets, and using a steel printer nozzle
would work, so well, however.

It would be very similar for colour change e.g. //??
color("red")([25,35,10]) say, generating g-code  rw_color "red" being
caught by a macro in the printer and doing whatever.

For changing infill, then if the region was specified in openscad, by
xyz's, then the gcode could be pulled apart in that area, not so easy,
but certainly doable (not sure I'd want to do it, tho'.).

I really do not need openscad to get more complex than it is. I am
concerned about the set up of 3MF, it is likely to be worse than dxf,
after all, autodesk is involved.

Best wishes,

Ray

On 14/09/2021 19:33, Jordan Brown wrote:

On Tue, Sep 14, 2021, at 9:40 AM, Michael Möller wrote:

I think you are talking about consumer grade FDM printers, which do multi-colour prints by switching between different coloured filaments. But if you use a service provider like ShapeWays for printing, then there are multiple technologies for full colour printing, where you have full CMYK control over the colour at each print position.

I dunno, maybe this is considered out of scope for OpenSCAD. One of the reasons I created my own OpenSCAD-like language was to do full colour printing like this. For output, I use file formats that support vertex colouring (where you specify a separate colour for each vertex in the model). 3MF is one of the file formats that supports vertex colouring.

Here's an example of a print that I created using Curv, exported as coloured vertexes, and printed using Shapeways: