Re: [OpenSCAD] Using CNC Machine OUTPUTS (How ?)
Rick,
there is not even a gleam of hope to get a G-code export for OpenSCAD.
G-code is very hardware-specific and a tool producing G-code needs to know a
lot about the target machine and the material. Moreover, OpenSCAD does (by
now) not include any color information into its output formats and I don't
see this in the next future.
There are several ways to get a color output. The common one used now by
multi-color FDM printers is to produce an STL for each color.
If you have a printer that can blend color, like one with a diamond hotend,
you will have to produce something like a VMRL description (wrl) and further
need a slicer or at least a post processor that will interpret the color
profile and include color definition commands into the G-code and in a
format the target hardware "understands". As slicing and color change might
be dependent, this is a quite complicated process and an implementation is
not at all straight forward. I am afraid, it will not be done by just
including just some Mxxx commands into the G-code sequence. I am currently
working out an true color system for FDM and can tell you, that you are just
scratching the tip of the iceberg with your venture and that OpenSCAD is not
at all the tool you will be heading for at the first place.
Rudolf
--
View this message in context: http://forum.openscad.org/Using-CNC-Machine-OUTPUTS-How-tp21653p21664.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
There is a pull request to get colour SVGs. I don't know why it didn't get
accepted but I will probably use if myself when I get my Glowforge laser
cutter.
On 9 June 2017 at 10:56, Parkinbot rudolf@parkinbot.com wrote:
Rick,
there is not even a gleam of hope to get a G-code export for OpenSCAD.
G-code is very hardware-specific and a tool producing G-code needs to know
a
lot about the target machine and the material. Moreover, OpenSCAD does (by
now) not include any color information into its output formats and I don't
see this in the next future.
There are several ways to get a color output. The common one used now by
multi-color FDM printers is to produce an STL for each color.
If you have a printer that can blend color, like one with a diamond hotend,
you will have to produce something like a VMRL description (wrl) and
further
need a slicer or at least a post processor that will interpret the color
profile and include color definition commands into the G-code and in a
format the target hardware "understands". As slicing and color change might
be dependent, this is a quite complicated process and an implementation is
not at all straight forward. I am afraid, it will not be done by just
including just some Mxxx commands into the G-code sequence. I am currently
working out an true color system for FDM and can tell you, that you are
just
scratching the tip of the iceberg with your venture and that OpenSCAD is
not
at all the tool you will be heading for at the first place.
Rudolf
--
View this message in context: http://forum.openscad.org/
Using-CNC-Machine-OUTPUTS-How-tp21653p21664.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
One other thing which might work, for some projects at least --- I've been
using METAPOST and OpenSCAD in concert --- I do the modeling in OpenSCAD,
and use an external file to load parameters, but in conjunction with that,
I write a matching METAPOST file which loads the same parameter file, and
instead creates a 2D cut file.
William
On Fri, Jun 9, 2017 at 6:33 AM, nop head nop.head@gmail.com wrote:
There is a pull request to get colour SVGs. I don't know why it didn't get
accepted but I will probably use if myself when I get my Glowforge laser
cutter.
On 9 June 2017 at 10:56, Parkinbot rudolf@parkinbot.com wrote:
Rick,
there is not even a gleam of hope to get a G-code export for OpenSCAD.
G-code is very hardware-specific and a tool producing G-code needs to
know a
lot about the target machine and the material. Moreover, OpenSCAD does (by
now) not include any color information into its output formats and I don't
see this in the next future.
There are several ways to get a color output. The common one used now by
multi-color FDM printers is to produce an STL for each color.
If you have a printer that can blend color, like one with a diamond
hotend,
you will have to produce something like a VMRL description (wrl) and
further
need a slicer or at least a post processor that will interpret the color
profile and include color definition commands into the G-code and in a
format the target hardware "understands". As slicing and color change
might
be dependent, this is a quite complicated process and an implementation is
not at all straight forward. I am afraid, it will not be done by just
including just some Mxxx commands into the G-code sequence. I am currently
working out an true color system for FDM and can tell you, that you are
just
scratching the tip of the iceberg with your venture and that OpenSCAD is
not
at all the tool you will be heading for at the first place.
Rudolf
--
View this message in context: http://forum.openscad.org/Usin
g-CNC-Machine-OUTPUTS-How-tp21653p21664.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
In the beginning I had the faint hope that it would be possible to write a
post processer that will be able to combine the color information contained
in the csg of a design with the resulting stl. It would contain some
function that calculates a color for each triangle given by the STL. I found
out that the result is not unique at least not well-defined and none is the
results that we get from F5 output.
Let's first see how OpenSCAD treats color in 2D (ok, there is no 2D in
OpenSCAD, but I mean something, that might be exported into SVG format)
{
color("green")circle(6);
color("red")square(10,center = true);
}
http://forum.openscad.org/file/n21668/color2d.png
now, which color results for the planes (and polygons) covered by both
objects? Green, red or even worse a mixture of both?
Second, let's look at a simple compound 3D object, which at the first glance
looks quite nice, at least from outside.
color("green")cube(10, center = true);
color("red")sphere(6);
http://forum.openscad.org/file/n21668/color3d.png
But, which coloring would you expect from the following code?
intersection()
{
color("red")sphere(6);
color("green")cube(10, center = true);
}
http://forum.openscad.org/file/n21668/color3d1.png
Is it the ordering of the operands that defines the color of the
intersection planes?
intersection()
{
color("green")cube(10, center = true);
color("red")sphere(6);
}
No. The ordering has no effect on the result.
Now the question: How would you define a tetraeder in OpenSCAD that consists
of a green, a yellow, a blue and a red triangle? Tricky, but not so
difficult - the tetraeder can be unioned by smaller tetraeders having these
colors. But would this approach be viable as general solution to
individually colorize the faces of more general objects?
--
View this message in context: http://forum.openscad.org/Using-CNC-Machine-OUTPUTS-How-tp21653p21668.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
This is a reply to Parkinbot, about applying colour to 3D objects.
I'm pretty happy with the colour model of the 3D solid modelling tool I am
developing (Curv).
Because it's a solid modelling tool intended for 3D printing, it uses a
volumetric colour model that assigns a colour to every point in the interior
of an object, not just to points on the surface. My eventual goal is to
create geometric models for printers like the RoVa 4D or the HP Jet Fusion,
which can control the colour of each voxel within a printed object. You
can't do this if you only have control over the colour of triangles on the
boundary of the solid.
Parkinbot wants to control the colour of triangles in an STL, which seems
like a different goal. If OpenSCAD is to export coloured 3D models, then
does it do solid/volumetric colouring, or does it do surface colouring? I
think this choice leads to different looking APIs.
In Curv, with its volumetric colour model,
- An expression like 'colour red (cube 10)' sets every geometric point
within the cube to red. - The union and intersection operators both give precedence to the colour of
the last shape in the argument list.
So,
union ( colour red (cube 10), colour green (sphere 6) )
and
union ( colour green (sphere 6), colour red (cube 10) )
give different results. They look the same from the outside:
http://forum.openscad.org/file/n21669/cubesphere1.png
but they look different when you cut them open:
http://forum.openscad.org/file/n21669/cubesphere2.png
http://forum.openscad.org/file/n21669/cubesphere3.png
In a Curv intersection, all of the colour comes from the last shape in the
argument list. (I used intersection to cut open the shapes in the above 2
images.)
In summary, these are the semantics I want for colour and colour export.
Other people may feel differently, depending on what they are trying to
accomplish.
--
View this message in context: http://forum.openscad.org/Using-CNC-Machine-OUTPUTS-How-tp21653p21669.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Doug,
it can make sense to either let the first or last operand of a boolean
operation define the common volume color. However, with respect to
difference() the first operand seems to be a more prominent candidate. But
please also note that Boolean operations will then lose their common
semantics, at least with respect to color. I'm not sure, whether this is a
good idea, as it can have unexpected results when complex boolean operations
are transformed into other boolean operations, or code is reused. Therefore
I'd prefer a more explicit definition of the common color via a parameter,
that can default to a specific color in the used color scheme.
union(color = "red", alpha .5){ ... }
While this can be a viable solution for material oriented coloring, as it is
used for multi-extruder printers, it covers only a (small) part of real
world needs. Texture mapping is the other use case that is larger,
especially when true color output devices will be more and more available.
OpenSCAD's design should at least not obstruct the entrance into this world,
howsoever it will be able to include it one day. The definition could be
done in the proposed way with one parameter referring to the image and a
second one defining the map.
--
View this message in context: http://forum.openscad.org/Using-CNC-Machine-OUTPUTS-How-tp21653p21670.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On Fri, Jun 09, 2017 at 10:21:21AM -0700, doug.moen wrote:
- The union and intersection operators both give precedence to the colour of
the last shape in the argument list.
That, IMHO is not ideal.
If I have a complicated object, composed of different sub-pieces
(Separate print jobs for my 3D printer, maybe because they move with
respect to each other) I often color them in bright colors to be able
to see what part belongs to which object.
Now, sometimes the inside is obscured. So I use an intersection with a
simple object like a cube or cylinder to cut somewhere where I want to
examine my object.
I would think that keeping the colors of the complicated object is
what I would like to happen. So I would like to set my help-object to
color=bland : give precedence to other colors.
I would in this case prefer to write my complicated object first. i.e.
to me it makes more sense to have the FIRST color dominate.
A union why does it need to be one color?
I often have
module box ()
{
union () {
color ("red") left ();
color ("blue") right ();
...
}
}
(often forget the union because that also does what I want...)
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
-- BitWizard writes Linux device drivers for any device you may have! --
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
I said:
The union and intersection operators both give precedence to the colour of
the last shape in the argument list.
Roger said:
That, IMHO is not ideal.
At first, I coded union and intersection to give precedence to the colour
of the first shape in the argument list.
Then, I went through a period where I was making 2-D pictures by building
up layers of coloured objects using union. At that time, it seemed more
natural to write code where the last shape in a union list was drawn "on
top", so I changed the order.
Right now, I'm working on a collection of 3D shapes where I construct
various space-filling lattice patterns (which are sometimes
multi-coloured), then crop them by intersecting them with another shape.
Right now, the "other shape" must appear as the first argument to
intersection. And it's just like Roger says, it would be more convenient
for that "other shape" to appear at the end.
Roger said:
I would in this case prefer to write my complicated object first. i.e.
to me it makes more sense to have the FIRST color dominate.
At this point, I suspect that the "natural order" depends on what you are
doing, and whatever convention I choose won't be the best in all
situations. So all I can do is pick a convention and stick with it.
Doug.
On 10 June 2017 at 06:21, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:
On Fri, Jun 09, 2017 at 10:21:21AM -0700, doug.moen wrote:
- The union and intersection operators both give precedence to the
colour of
the last shape in the argument list.
That, IMHO is not ideal.
If I have a complicated object, composed of different sub-pieces
(Separate print jobs for my 3D printer, maybe because they move with
respect to each other) I often color them in bright colors to be able
to see what part belongs to which object.
Now, sometimes the inside is obscured. So I use an intersection with a
simple object like a cube or cylinder to cut somewhere where I want to
examine my object.
I would think that keeping the colors of the complicated object is
what I would like to happen. So I would like to set my help-object to
color=bland : give precedence to other colors.
I would in this case prefer to write my complicated object first. i.e.
to me it makes more sense to have the FIRST color dominate.
A union why does it need to be one color?
I often have
module box ()
{
union () {
color ("red") left ();
color ("blue") right ();
...
}
}
(often forget the union because that also does what I want...)
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
-- BitWizard writes Linux device drivers for any device you may have! --
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Sat, Jun 10, 2017 at 11:03:10AM -0400, doug moen wrote:
At this point, I suspect that the "natural order" depends on what you are
doing, and whatever convention I choose won't be the best in all
situations. So all I can do is pick a convention and stick with it.
You're right. It depends. I didn't want to preach the one-and-only
right way of doing it. The idea was to trigger at least some thought
about this. If after some thought a decision is made. Great. I want to
prevent the situation where noone every took a decision e.g. "it is
also inconvenient for me, but in the implementation it turned out like
that. "
Have you ever looked into the NBD protocol? It was made extensible by
having a 128 byte "reserved block". Well, that never got used, the
protocol version needed to be upgraded because clients and servers
could never be sure the other side understood what they wanted. And
then this happened again! Sitting down for half an hour thinking about
such things helps enormously.
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
-- BitWizard writes Linux device drivers for any device you may have! --
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.