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: