User Poll: What do you want to see from OpenSCAD development?
On 2019-11-10 08:25, Serge wrote:
- Complete rewrite of the language. Make it true OOP and easy to code
That would be AngelCAD. https://arnholm.github.io/angelcad-docs/ . When
starting with OpenSCAD, I had a similar reaction to the extensive
discussions of language quirks instead of modelling capabilities. For a
script based modeller I thought it would be more interesting to use and
extend an existing language with CSG modelling capabilities rather than
invent a new language. It could be done using Python, but I chose
AngelScript because of the easy and direct integration with C++, plus it
is a full blown OOP language that is 100% embedded in the application
just like the OpenSCAD language.
- easy objects alignment in 3D
A good start in this area is to introduce and use bounding boxes.
As I have mentioned elsewhere I think the focus should be on making things
easy and attractive for a newbie, and for occasional users, without
interfering with traditional users.
To my mind that means that it should be possible to build most models with a
GUI front-end - such as GraphScad, Blockscad or the ClikScad that I have
created and am using for my own work. I'm not saying that the OpenSCAD
development team should "drop everything" and build a GUI front end - it may
be perfectly sufficient to endorse and encourage the use of an existing
front-end.
For the sorts of things I have wanted to create with my 3D printer the
existing OpenSCAD has all the capability that I require. and I have not been
aware of any bugs or crashes.
IMHO the idea of a complete rewrite is nonsense - a huge amount of wasted
time with no improvement whatever on the output of anyone's 3D printer.
...R
--
Sent from: http://forum.openscad.org/
thehans wrote
What do you feel is the most important aspect to focus on, or would
have the biggest impact to your experience using OpenSCAD:
- Stability, squash more bugs in general
- Optimize existing code, make OpenSCAD faster
- Addition of new features
- More / improved documentation
- All of the above should be balanced equally
- Nothing, I am content
- Something else not mentioned
If you have a specific issue in mind related to your choice, please
describe and link to it if there is an existing github issue.
With a focus on Developer Resources it should be the top three, 1) generally
a priority, then 2) & 3) balanced.
-
I really think there is a gremlin in the core with various CGAL errors.
The latest being https://github.com/openscad/openscad/issues/3117 -
as OpenSCAD usage gets more sophisticated, as users get more experience
(and use new features), then performance becomes a bigger hindrance. -
There are various axis of change, there should always be room for
progressive tweaks and usage optimisation (+1 to linear_extrude height=
anomaly) but with the Developers available, isn't it basically only going to
change in directions particular Developers re willing to spend time on. Are
we able to do something other than Bountysource to attract Developers?
https://www.bountysource.com/teams/openscad -
Documentation can enhanced by others. Perhaps we need a documentation
ToDo? -
I got an email, someone added $50 (=$300) to the Bountysource for
https://www.bountysource.com/issues/32262436-color-material-and-part
something I've thought is holding back OpenSCAD usage beyond typical
FDM/FFF.
I also have sympathy for the laser cutters..."1D" or is it 1.5D?
Admin - email* me if you need anything, or if I've done something stupid...
- click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Sent from: http://forum.openscad.org/
On Sun, Nov 10, 2019, at 2:47 AM, Jordan Brown wrote:
If I had to pick a single set of things that I'd like to see improvement on, it would be the handling of what are currently considered "errors" in the model - non-2-manifolds[*], ... Those are all easy traps for the novice to fall into and not immediately obvious.
There's no intuitive reason why this model is a problem:
cube(1);
translate([1,1,0]) cube(1);
The specific problem being referenced here is that if you have two polyhedra that don't intersect (with a non-zero intersection volume), but they touch at a vertex or touch at an edge, then you can't represent that in an STL file, because the polygon mesh is not 2-manifold.
This restriction is a problem for users, because it means that shapes are not closed under union. You can take two valid shapes (cubes in the above example), union them together, and the result is not considered valid.
This limitation really only exists because of the STL file format.
The limitation doesn't exist in CGAL, which is the library used by OpenSCAD to compute unions, intersections and differences. CGAL provides a Nef Polyhedron data structure which is closed under the union operation, and which can represent the union of two cubes shown above.
This limitation doesn't exist in the 3MF file format, which explicitly supports these kinds of models.
This statement might be surprising or controversial. The way it works is: 3MF uses a different mesh representation than STL. In 3MF, there is an array of points, each point has a numeric ID. Then there is a separate array of triangles: each triangle is represented by 3 point IDs, which are indexes into the point array. In a "non-manifold Nef Polyhedron" (like the 2 cubes in the example), there are 2 or more disjoint volumes that touch at one or more vertices. These "shared vertices" must be duplicated in the 3MF points array, so that each disjoint volume refers to the same shared vertices using distinct point IDs. Only then do you have a valid 3MF representation. The 3MF standard discusses this in section 4.1.3: "The producer SHOULD NOT include duplicate vertices unless coalescing duplicates would create non-manifold edges."
As far as I can tell, CGAL provides the necessary APIs that could be used to export a non-manifold Nef Polyhedron to a 3MF file, without creating an invalid 3MF file. But the current 3MF export code isn't written that way, and doesn't support this case. So the problem is fixable, it's not PhD thesis level of difficulty.
Beyond that, I'd like to see better integration between CAD programs like OpenSCAD and slicers. I'd like you to be able to change a design in OpenSCAD and "refresh" the slicer so that the old model is replaced by the new. Some aspects of that are easy: retaining translation, rotation, and scaling; maybe retaining print settings. Some are harder, like arranging that the model is on the print bed even when its lowest point moved up or down. Some are probably nearly impossible, like retaining support designs. Probably this is mostly on the slicer, but maybe not.
Along the same lines of integration with slicers, it would be nice to be able to incorporate slicer controls into the model definition, so that you don't have to have both the .scad file and a separate file that sets up the slicer. Perhaps, for instance, there could be annotations that you could add in OpenSCAD that the slicer would read. Start with rotation, translation, and scaling, so that you can be looking at the object in its "use" orientation in OpenSCAD, but it would automatically adjust to its "print" orientation in the slicer. Continue with, e.g., slice thickness. This would address some of the "refresh" functionality desired above. People with mills instead of 3D printers might be interested in similar functionality to allow cut descriptions to be embedded in the model design.
The 3MF file format can hold slicer settings. I haven't researched this, but something of what you ask for might be possible with 3MF.
Regardless of file format limitations, non manifold objects cannot exist in
reality, so I think it should be an error to make one and users should be
educated.
Two cubes cannot share a zero width edge. They either overlap by at least
one atom or are separate. It is no coincidence that STL can represents all
physically realisable objects.
On Mon, 11 Nov 2019 at 04:17, Doug Moen doug@moens.org wrote:
On Sun, Nov 10, 2019, at 2:47 AM, Jordan Brown wrote:
If I had to pick a single set of things that I'd like to see improvement
on, it would be the handling of what are currently considered "errors" in
the model - non-2-manifolds[*], ... Those are all easy traps for the
novice to fall into and not immediately obvious.
There's no intuitive reason why this model is a problem:
cube(1);
translate([1,1,0]) cube(1);
The specific problem being referenced here is that if you have two
polyhedra that don't intersect (with a non-zero intersection volume), but
they touch at a vertex or touch at an edge, then you can't represent that
in an STL file, because the polygon mesh is not 2-manifold.
This restriction is a problem for users, because it means that shapes are
not closed under union. You can take two valid shapes (cubes in the above
example), union them together, and the result is not considered valid.
This limitation really only exists because of the STL file format.
The limitation doesn't exist in CGAL, which is the library used by
OpenSCAD to compute unions, intersections and differences. CGAL provides a
Nef Polyhedron data structure which is closed under the union operation,
and which can represent the union of two cubes shown above.
This limitation doesn't exist in the 3MF file format, which explicitly
supports these kinds of models.
This statement might be surprising or controversial. The way it works is:
3MF uses a different mesh representation than STL. In 3MF, there is an
array of points, each point has a numeric ID. Then there is a separate
array of triangles: each triangle is represented by 3 point IDs, which are
indexes into the point array. In a "non-manifold Nef Polyhedron" (like the
2 cubes in the example), there are 2 or more disjoint volumes that touch at
one or more vertices. These "shared vertices" must be duplicated in the 3MF
points array, so that each disjoint volume refers to the same shared
vertices using distinct point IDs. Only then do you have a valid 3MF
representation. The 3MF standard discusses this in section 4.1.3: "The
producer SHOULD NOT include duplicate vertices unless coalescing duplicates
would create non-manifold edges."
As far as I can tell, CGAL provides the necessary APIs that could be used
to export a non-manifold Nef Polyhedron to a 3MF file, without creating an
invalid 3MF file. But the current 3MF export code isn't written that way,
and doesn't support this case. So the problem is fixable, it's not PhD
thesis level of difficulty.
Beyond that, I'd like to see better integration between CAD programs like
OpenSCAD and slicers. I'd like you to be able to change a design in
OpenSCAD and "refresh" the slicer so that the old model is replaced by the
new. Some aspects of that are easy: retaining translation, rotation, and
scaling; maybe retaining print settings. Some are harder, like arranging
that the model is on the print bed even when its lowest point moved up or
down. Some are probably nearly impossible, like retaining support
designs. Probably this is mostly on the slicer, but maybe not.
Along the same lines of integration with slicers, it would be nice to be
able to incorporate slicer controls into the model definition, so that you
don't have to have both the .scad file and a separate file that sets up the
slicer. Perhaps, for instance, there could be annotations that you could
add in OpenSCAD that the slicer would read. Start with rotation,
translation, and scaling, so that you can be looking at the object in its
"use" orientation in OpenSCAD, but it would automatically adjust to its
"print" orientation in the slicer. Continue with, e.g., slice thickness.
This would address some of the "refresh" functionality desired above.
People with mills instead of 3D printers might be interested in similar
functionality to allow cut descriptions to be embedded in the model design.
The 3MF file format can hold slicer settings. I haven't researched this,
but something of what you ask for might be possible with 3MF.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Mon, 11 Nov 2019 at 04:17, Doug Moen doug@moens.org wrote:
The specific problem being referenced here is that if you have two
polyhedra that don't intersect (with a non-zero intersection volume), but
they touch at a vertex or touch at an edge, then you can't represent that
in an STL file, because the polygon mesh is not 2-manifold.
Sorry but STL file format can represent objects (in a broad sense) that are
not 2-manifolds. As a soup of triangles, STL file format can represent the
faces of the two cubes sharing just an edge and even flaps. What STL cannot
represent is its topology as an aggregate of 2-manifolds like 3MF seems to
do.
I don't know the specification of 3MF but if it is able to represent the
following:
cube(10);
translate([5,5,0]) cube(10);
not as an union but as an aggregate of two cubes (the same way it would
represent if the intersect only in an edge), then we may have troubles
trying to print it because slicers seems to be non consistent in their way
to interpret that aggregate. A long time ago I have done a test how
different slicers interpret such aggregate by writing an STL file that
represent it. And I have found two distinct interpretations: in the former,
the union was produced; in the later, the common points of the two cubes
were off the resulting object. Perhaps now they had converged to a common
interpretation by using the same rule to recognize what points are inside
the object.
On 11 Nov 2019 at 07:34, nop head nop.head@gmail.com wrote:
Two cubes cannot share a zero width edge. They either overlap by at least
one atom or are separate. It is no coincidence that STL can represents all
physically realisable objects.
The STL file format is able to represent two cubes sharing a zero width
edge. To do it yourself, join the two STL files (keeping only one header
and one tail) representing each cube. The 2-manifold concept is not a
physical one but a mathematical abstraction so not necessarily able to be
physically realizable.
Stability. Sometimes, it just locks or quits. Closely related: More specific
error messages for syntax errors.
Editor features. Specifically intellisense.
2D objects (line, point), for laser cutting.
--
Sent from: http://forum.openscad.org/
On Mon, Nov 11, 2019, at 7:33 AM, nop head wrote:
Regardless of file format limitations, non manifold objects cannot exist in reality, so I think it should be an error to make one and users should be educated.
Two cubes cannot share a zero width edge. They either overlap by at least one atom or are separate. It is no coincidence that STL can represents all physically realisable objects.
I disagree! 3MF is a file format for 3D printing. It was designed by a group of technical experts from 3D printer companies (like 3D systems) and 3D service providers (like Shapeways). The 3MF standard goes into great detail explaining what is and is not a valid mesh, and it provides instructions on how slicers should interpret valid 3MF meshes. It is an impressive document, obviously written by people who understand 3D printing.
So it's hard to understand your belief that valid 3MF meshes are not "physically realizable". 3MF meshes are 3D printable, so how can it simultaneously be true that they aren't "physically realizable"?
OpenSCAD should be able to import, process and export any valid 3MF mesh, including meshes that would not be valid if converted to STL format. We can't do that today, but it is a useful goal to have for the future.
I have a Prusa i3 at home, and I was inspired to start this conversation after reading that 3MF is now the preferred file format at Prusa. This is because:
- 3MF is an open standard (Unlike AMF. You have to pay money to read the AMF standard.)
- 3MF is unambiguous. There are rules that determine what is a valid mesh. Given a valid mesh, there are rules on how to interpret it for slicing. AMF (says Prusa) is ambiguous.
- 3MF files are significantly more compact than STL files.
- They can represent multi-colour and multi-material models (important if you have the Prusa multi-material unit). Unlike STL.
- They can store slicer configuration which describes how to slce this particular model. Unlike STL.
PrusaSlicer can save config changes back to the original 3MF file.
So I'd like to see better 3MF support in the future.
Hi Ronaldo.
The STL file format is ambiguous. There is no formal written standard. Different slicers interpret the same STL file in different ways.
OpenSCAD tries to work around this ambiguity by restricting its output to an unambigous subset of STL, which is 2-manifold, watertight, and non-self-intersecting.
The 3MF standard is unambigous. There are rules for what constitutes a valid mesh, and there are rules for how a slicer should interpret a valid mesh. Since it is very difficult, in general, to avoid generating meshes that are free from self-intersection, 3MF even has rules for how a slicer should interpret self-intersection.
3MF meshes are required to be 2-manifold, but this means something subtly different from what it means in OpenSCAD. An STL mesh is just a list of triangles, where each triangle is 3 vertices, and each vertex is 3 numbers. In 3MF, there is a level of indirection, as I said before. There is a vertex list, which assigns a number (a vertex id) to each vertex, and there is a list of triangles, where each triangle is 3 vertex IDs. In 3MF, the 2-manifold restriction is defined in terms of vertex IDs. It is legal in some cases for two distinct vertex IDs to have the same coordinates. This loophole exists so that you can represent 2 cubes sharing an edge.
Doug Moen.
On Mon, Nov 11, 2019, at 12:32 PM, Ronaldo Persiano wrote:
On Mon, 11 Nov 2019 at 04:17, Doug Moen doug@moens.org wrote:
__
The specific problem being referenced here is that if you have two polyhedra that don't intersect (with a non-zero intersection volume), but they touch at a vertex or touch at an edge, then you can't represent that in an STL file, because the polygon mesh is not 2-manifold.
Sorry but STL file format can represent objects (in a broad sense) that are not 2-manifolds. As a soup of triangles, STL file format can represent the faces of the two cubes sharing just an edge and even flaps. What STL cannot represent is its topology as an aggregate of 2-manifolds like 3MF seems to do.
I don't know the specification of 3MF but if it is able to represent the following:
cube(10);
translate([5,5,0]) cube(10);
not as an union but as an aggregate of two cubes (the same way it would represent if the intersect only in an edge), then we may have troubles trying to print it because slicers seems to be non consistent in their way to interpret that aggregate. A long time ago I have done a test how different slicers interpret such aggregate by writing an STL file that represent it. And I have found two distinct interpretations: in the former, the union was produced; in the later, the common points of the two cubes were off the resulting object. Perhaps now they had converged to a common interpretation by using the same rule to recognize what points are inside the object.
On 11 Nov 2019 at 07:34, nop head nop.head@gmail.com wrote:
Two cubes cannot share a zero width edge. They either overlap by at least one atom or are separate. It is no coincidence that STL can represents all physically realisable objects.
The STL file format is able to represent two cubes sharing a zero width edge. To do it yourself, join the two STL files (keeping only one header and one tail) representing each cube. The 2-manifold concept is not a physical one but a mathematical abstraction so not necessarily able to be physically realizable.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
3MF meshes are 3D printable, so how can it simultaneously be true that
they aren't "physically realizable"?
Just because a 3D printer spits something out doesn't mean it produces an
object that is not 2 manifold. It will either be joined with a finite
thickness or be separated. There will not be a shared edge as there is no
physical meaning to that. The boundary of a read 3D object will always be
2-mainfold.
On Mon, 11 Nov 2019 at 15:07, Doug Moen doug@moens.org wrote:
Hi Ronaldo.
The STL file format is ambiguous. There is no formal written standard.
Different slicers interpret the same STL file in different ways.
OpenSCAD tries to work around this ambiguity by restricting its output to
an unambigous subset of STL, which is 2-manifold, watertight, and
non-self-intersecting.
The 3MF standard is unambigous. There are rules for what constitutes a
valid mesh, and there are rules for how a slicer should interpret a valid
mesh. Since it is very difficult, in general, to avoid generating meshes
that are free from self-intersection, 3MF even has rules for how a slicer
should interpret self-intersection.
3MF meshes are required to be 2-manifold, but this means something subtly
different from what it means in OpenSCAD. An STL mesh is just a list of
triangles, where each triangle is 3 vertices, and each vertex is 3 numbers.
In 3MF, there is a level of indirection, as I said before. There is a
vertex list, which assigns a number (a vertex id) to each vertex, and there
is a list of triangles, where each triangle is 3 vertex IDs. In 3MF, the
2-manifold restriction is defined in terms of vertex IDs. It is legal in
some cases for two distinct vertex IDs to have the same coordinates. This
loophole exists so that you can represent 2 cubes sharing an edge.
Doug Moen.
On Mon, Nov 11, 2019, at 12:32 PM, Ronaldo Persiano wrote:
On Mon, 11 Nov 2019 at 04:17, Doug Moen doug@moens.org wrote:
The specific problem being referenced here is that if you have two
polyhedra that don't intersect (with a non-zero intersection volume), but
they touch at a vertex or touch at an edge, then you can't represent that
in an STL file, because the polygon mesh is not 2-manifold.
Sorry but STL file format can represent objects (in a broad sense) that
are not 2-manifolds. As a soup of triangles, STL file format can represent
the faces of the two cubes sharing just an edge and even flaps. What STL
cannot represent is its topology as an aggregate of 2-manifolds like 3MF
seems to do.
I don't know the specification of 3MF but if it is able to represent the
following:
cube(10);
translate([5,5,0]) cube(10);
not as an union but as an aggregate of two cubes (the same way it would
represent if the intersect only in an edge), then we may have troubles
trying to print it because slicers seems to be non consistent in their way
to interpret that aggregate. A long time ago I have done a test how
different slicers interpret such aggregate by writing an STL file that
represent it. And I have found two distinct interpretations: in the former,
the union was produced; in the later, the common points of the two cubes
were off the resulting object. Perhaps now they had converged to a common
interpretation by using the same rule to recognize what points are inside
the object.
On 11 Nov 2019 at 07:34, nop head nop.head@gmail.com wrote:
Two cubes cannot share a zero width edge. They either overlap by at least
one atom or are separate. It is no coincidence that STL can represents all
physically realisable objects.
The STL file format is able to represent two cubes sharing a zero width
edge. To do it yourself, join the two STL files (keeping only one header
and one tail) representing each cube. The 2-manifold concept is not a
physical one but a mathematical abstraction so not necessarily able to be
physically realizable.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org