User Poll: What do you want to see from OpenSCAD development?

classic Classic list List threaded Threaded
101 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: User Poll: What do you want to see from OpenSCAD development?

nophead
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 <[hidden email]> 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
[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: User Poll: What do you want to see from OpenSCAD development?

Ronaldo
On Mon, 11 Nov 2019 at 04:17, Doug Moen <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: User Poll: What do you want to see from OpenSCAD development?

Troberg
In reply to this post by thehans
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/

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

Re: User Poll: What do you want to see from OpenSCAD development?

doug.moen
In reply to this post by nophead
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.

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

Re: User Poll: What do you want to see from OpenSCAD development?

doug.moen
In reply to this post by Ronaldo
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 <[hidden email]> 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 <[hidden email]> 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
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: User Poll: What do you want to see from OpenSCAD development?

nophead
>  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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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


_______________________________________________
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: User Poll: What do you want to see from OpenSCAD development?

cacb
In reply to this post by doug.moen
On 2019-11-11 05:15, Doug Moen wrote:
> On Sun, Nov 10, 2019, at 2:47 AM, Jordan Brown wrote:
>>> 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.

Actually, this is not correct. STL as such has no issues representing
such a thing. STL has no shared vertices or edges at all, every vertex
is duplicated for each triangle, and there are no explicit edges. The
problem is not representing such a thing in STL, the problem is
interpreting it consistently by OpenSCAD or any other program reading
it.

An STL file is a "polygon soup", it is simply a set of totally
disconnected triangles with zero shared topology. Such topology must be
guessed at by the program reading it, by comparing coordinates. This is
totally different from most other formats such as OBJ, OFF, AMF or 3MF
where the topology is explicitly represented.

For this reason, STL is particularly unsuitable for sharing models
between CAD applications. A slicer program is more forgiving so that
works better with STL.

> 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.

No, this is not true. STL has no issues representing this case or any
other case, it does not care about non-manifoldness. It is not STL that
complains in this case, this issue is totally unrelated to STL.

The warning that the model is not 2-manifold can be considered false
alarm in some cases, whether it is a problem or not depends on the
intended use of the model. There is nothing wrong topologically with two
cubes sharing an edge in this way, it just happens to not be 2-manifold.

Manifoldness in this context means "how many times an edge is shared
between adjacent faces". An edge is the topological connection between 2
vertices. For a clean, closed volume every edge is used twice, hence it
is 2-manifold. In this case there are 2 volumes sharing an edge, so that
edge becomes 4-manifold as it is referenced by 4 faces.

But manifoldness is totally irrelevant in the STL file format, you can
write this file to STL without any issue. You can also write a single
triangle to an STL without any issue, there is no volume in that case.
The problem with STL is not that it is limited or restrictive, the
problem with STL is that there are no rules at all, so interpretation of
it becomes a problem.

> This limitation doesn't exist in the 3MF file format, which explicitly
> supports these kinds of models.

Any of STL, OBJ, OFF, AMF will of course support such a model. It is not
a question of file format.

> This statement might be surprising or controversial. The way it works
> is: 3MF uses a different mesh representation than STL.

As does OBJ, OFF and AMF. All of them use the kind of topology you
describe below.

> 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."

Not duplicating the vertices is what is causing the edge to be
4-manifold. If 3MF require all edges to be 2-manifold, it is 3MF that is
extra restrictive.

> 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 that seems to violate the rule you just referred to?

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: User Poll: What do you want to see from OpenSCAD development?

jang0
In reply to this post by thehans
I would like that OpenSCAD have a "technical draft" focus, the aim of a
technical draft is to facilitate the comunication between the person that
design a part and the people that manufacture it; in this sense developers
can implement specialized functions like those: create iso A, iso E
projectios, dimensioning drawings, create title blocks, etc. Already some
users implemented that; nevertheless there are not so polish functions and
overcomplicate the process of make a draft. In example doesn't take into
account hidden lines or geometry and take a lot of extra work compared to a
GUI technical draft software.
An advantage of OpenSCAD compared to those software is that you can avoid
"mouse" usage; this is very usefull with work that require long designing
periods that harm your wrist. Will be very helpfull if we could create
"professional" technical drafts too.



--
Sent from: http://forum.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: User Poll: What do you want to see from OpenSCAD development?

SarahC

I'd love the "thrown together" option to display holes, and intersecting polygons.
Very useful for STL file imports.

Would it be possible to fix intersecting polygons, zero volume polygons and holes in OpenSCAD's import?
It sounds difficult - but would make including existing models so much easier.

On Tue, 12 Nov 2019 at 01:30, jang0 <[hidden email]> wrote:
I would like that OpenSCAD have a "technical draft" focus, the aim of a
technical draft is to facilitate the comunication between the person that
design a part and the people that manufacture it; in this sense developers
can implement specialized functions like those: create iso A, iso E
projectios, dimensioning drawings, create title blocks, etc. Already some
users implemented that; nevertheless there are not so polish functions and
overcomplicate the process of make a draft. In example doesn't take into
account hidden lines or geometry and take a lot of extra work compared to a
GUI technical draft software.
An advantage of OpenSCAD compared to those software is that you can avoid
"mouse" usage; this is very usefull with work that require long designing
periods that harm your wrist. Will be very helpfull if we could create
"professional" technical drafts too.



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

_______________________________________________
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: User Poll: What do you want to see from OpenSCAD development?

OpenSCAD mailing list-2
In reply to this post by thehans
Aspect 3:

My wish would be for an exportable 2D view (in SVG) of an elevation (xy
or yz or zx or definable) profile that preserved the colours of the
model as seen in preview mode.

I believe someone could write a coloured plane to CAM-GCode package from
such an image for routing, milling or laser work. I hesitate to say it
would be simple only for the fact I would certainly not find it simple,
but others could find it easier? Certainly, if possible, it could
release a lot more of OpenSCAD goodness into these other worlds (eg via
Inkscape+add-ons).

It would also be handy for documentation and trial fit purposes.

Rob

On 10/11/19 9:22 am, Hans L wrote:

> Hi everyone,
>
> I wanted to get some input and have a bit of discussion from users
> here, regarding what they would most like to see from current or
> near-future OpenSCAD development.
>
> What do you feel is the most important aspect to focus on, or would
> have the biggest impact to your experience using OpenSCAD:
>
> 1) Stability, squash more bugs in general
> 2) Optimize existing code, make OpenSCAD faster
> 3) Addition of new features
> 4) More / improved documentation
> 5) All of the above should be balanced equally
> 6) Nothing, I am content
> 7) 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.
>
> Disclaimer: I am not a project owner for OpenSCAD, I just contribute
> code when / where I can.  So this poll is not "official", just created
> out of my personal curiosity. There is no guarantee that I or other
> volunteer developers will directly address any issues raised here.
>
> Happy modeling,
> Hans Loeblich
>
> _______________________________________________
> 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: User Poll: What do you want to see from OpenSCAD development?

JordanBrown
In reply to this post by nophead
On 11/10/2019 11:33 PM, 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.

While that's mathematically true, in practical reality it's not.

In practical reality I can jam two cubes edge-to-edge and get something that sure looks like a shared zero-width edge.  Is it really?  It might be separated by just a little, or down at the atomic level the two might interpenetrate just a little.  Who cares?  When the printer is spitting out 0.4mm plastic with a resolution best measured in fractions of a millimeter, there's no practical difference between a separation of one micrometer, zero, and an overlap of one micrometer.  The printer can't represent any of them accurately, so it doesn't matter what it does.

If I have
cube(100);
translate([0,0,100]) cube(50);
translate([50,50,100]) cube(50);
it's clear that the two upper cubes are attached to the lower cube, and it doesn't matter whether they're attached to each other.  There is no practical reason why it should be different from
cube(100);
translate([0,0,100]) cube(50.001);
translate([50,50,100]) cube(50);

or

cube(100);
translate([0,0,100]) cube(49.999);
translate([50,50,100]) cube(50);

... and yet it is.

I would say that it would be correct in any of those cases for the printer to draw a continuous line across the joint, or to not draw a continuous line across the joint.  The joint is below its extrusion width and so exactly what it should do is not well-defined.  (In fact, it should probably be a user option what to do with volumes that are below half the extrusion width - either round them out of existence, or say that every volume deserves to be represented, if only as a single extrusion.

2D programs deal with hairlines all the time; this seems like the same case.



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

Re: User Poll: What do you want to see from OpenSCAD development?

Steven Dick
In reply to this post by SarahC
Openscad is not a mesh editor.  You might be able to do simple things like fixing round off errors  during import (which is an eternal problem with STLs since every vertex is listed separately for every instance of every edge) ,  but fixing problems like holes and intersecting polygons is the job of a mesh editor like blender or meshlab.  Use the right tool for the right job.

Zero size polygons are similar to round off errors.  Some holes and cracks are not real and are caused by the importer not recognizing two instances of the same edge due to round off errors, and I can see the importer fixing these, but a real hole  or intersecting faces from a malformed mesh is much harder to fix.

On Mon, Nov 11, 2019 at 9:38 PM Sarah Cartwright <[hidden email]> wrote:

I'd love the "thrown together" option to display holes, and intersecting polygons.
Very useful for STL file imports.

Would it be possible to fix intersecting polygons, zero volume polygons and holes in OpenSCAD's import?
It sounds difficult - but would make including existing models so much easier.
 

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

Re: User Poll: What do you want to see from OpenSCAD development?

mister.koz

My suggestions:
1. Have a way of integrating custom libraries at the openscad level, i currently do "import(../../../project/projectfile.scad)" and it's a little tedious, a basic library path like the Arduino app has would be cool
2. make it so exports can retain colours (or colors if you wish) - may not be feasible for the current export formats
3. make the default features overrideable like in normal OO - for example the default center value is "center=false" it would be really nice to be able to say something like:
module square($params) {
  params[center] = true;
  default_square($params)
}
4. Create some kinda scheduler for the command line that runs multiple processes across threads - i currently do this with my own python code and it saves me heaps of rendering time to use all 12 vcpu's :)

On Tue, 12 Nov 2019 at 15:50, Steven Dick <[hidden email]> wrote:
Openscad is not a mesh editor.  You might be able to do simple things like fixing round off errors  during import (which is an eternal problem with STLs since every vertex is listed separately for every instance of every edge) ,  but fixing problems like holes and intersecting polygons is the job of a mesh editor like blender or meshlab.  Use the right tool for the right job.

Zero size polygons are similar to round off errors.  Some holes and cracks are not real and are caused by the importer not recognizing two instances of the same edge due to round off errors, and I can see the importer fixing these, but a real hole  or intersecting faces from a malformed mesh is much harder to fix.

On Mon, Nov 11, 2019 at 9:38 PM Sarah Cartwright <[hidden email]> wrote:

I'd love the "thrown together" option to display holes, and intersecting polygons.
Very useful for STL file imports.

Would it be possible to fix intersecting polygons, zero volume polygons and holes in OpenSCAD's import?
It sounds difficult - but would make including existing models so much easier.
 
_______________________________________________
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: User Poll: What do you want to see from OpenSCAD development?

MichaelAtOz
Administrator
In reply to this post by JordanBrown
JordanBrown wrote

> On 11/10/2019 11:33 PM, 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.
>
> While that's mathematically true, in practical reality it's not.
>
> In practical reality I can jam two cubes edge-to-edge and get something
> that sure looks like a shared zero-width edge.  Is it really? 

Nothing is certain https://en.wikipedia.org/wiki/Uncertainty_principle the
edge is a waveform, electron orbits are also waveforms, so who can tell...
Unless you have:

> Heisenberg compensators remove uncertainty from the subatomic
> measurements, making transporter travel feasible. Further technology
> involved in transportation include a computer pattern buffer to enable a
> degree of leeway in the process. When asked "How does the Heisenberg
> compensator work?" by Time magazine, Star Trek technical adviser Michael
> Okuda responded: "It works very well, thank you."





-----
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/

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

Re: User Poll: What do you want to see from OpenSCAD development?

nophead
In reply to this post by mister.koz
Adam,
   OpenSCAD looks at the OPENSCADPATH environment variable for places to find libraries.

Jordon,

Since all real objects are 2-manifold I don't see why OpenSCAD needs to be able to handle non-manifold designs. What advantage is it?

If you want to print two cubes next to each then leave a small gap. They will then get two separate perimeters. If you want to print two cubes that are joined overlap them by your printers minimum wall width. Your model then represents what  you want your printer to print. If you export two cubes sharing an edge who knows what the printer will do? It is much better to give an error as soon as possible to avoid creating a model that can't be printed. Yes the printer may print something but it won't match the physically impossible model.

In answer to the original question. I don't find OpenSCAD limiting for creating my designs at the moment. What I would like to see is module literals to match function literals and a dict / record type. That would tidy up my code.

A faster geometry engine like Carve looks like it would transform OpenSCAD as a faster union would allow 3D Minkowski to be fast and that would allow 3D rounding to be practical.

On Tue, 12 Nov 2019 at 05:25, Adam Purdie <[hidden email]> wrote:

My suggestions:
1. Have a way of integrating custom libraries at the openscad level, i currently do "import(../../../project/projectfile.scad)" and it's a little tedious, a basic library path like the Arduino app has would be cool
2. make it so exports can retain colours (or colors if you wish) - may not be feasible for the current export formats
3. make the default features overrideable like in normal OO - for example the default center value is "center=false" it would be really nice to be able to say something like:
module square($params) {
  params[center] = true;
  default_square($params)
}
4. Create some kinda scheduler for the command line that runs multiple processes across threads - i currently do this with my own python code and it saves me heaps of rendering time to use all 12 vcpu's :)

On Tue, 12 Nov 2019 at 15:50, Steven Dick <[hidden email]> wrote:
Openscad is not a mesh editor.  You might be able to do simple things like fixing round off errors  during import (which is an eternal problem with STLs since every vertex is listed separately for every instance of every edge) ,  but fixing problems like holes and intersecting polygons is the job of a mesh editor like blender or meshlab.  Use the right tool for the right job.

Zero size polygons are similar to round off errors.  Some holes and cracks are not real and are caused by the importer not recognizing two instances of the same edge due to round off errors, and I can see the importer fixing these, but a real hole  or intersecting faces from a malformed mesh is much harder to fix.

On Mon, Nov 11, 2019 at 9:38 PM Sarah Cartwright <[hidden email]> wrote:

I'd love the "thrown together" option to display holes, and intersecting polygons.
Very useful for STL file imports.

Would it be possible to fix intersecting polygons, zero volume polygons and holes in OpenSCAD's import?
It sounds difficult - but would make including existing models so much easier.
 
_______________________________________________
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

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

Re: User Poll: What do you want to see from OpenSCAD development?

cacb
On 2019-11-12 08:19, nop head wrote:
> A faster geometry engine like Carve looks like it would transform
> OpenSCAD as a faster union would allow 3D Minkowski to be fast and
> that would allow 3D rounding to be practical.

Carve does not have "native" support for 3D Minkowski, but I have
implemented 3D Minkowski on top of Carve, taking advantage of
multithreading for fast unions.

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: User Poll: What do you want to see from OpenSCAD development?

mister.koz
In reply to this post by nophead
Thanks @nop head :)

On Tue, 12 Nov 2019 at 18:20, nop head <[hidden email]> wrote:
Adam,
   OpenSCAD looks at the OPENSCADPATH environment variable for places to find libraries.

Jordon,

Since all real objects are 2-manifold I don't see why OpenSCAD needs to be able to handle non-manifold designs. What advantage is it?

If you want to print two cubes next to each then leave a small gap. They will then get two separate perimeters. If you want to print two cubes that are joined overlap them by your printers minimum wall width. Your model then represents what  you want your printer to print. If you export two cubes sharing an edge who knows what the printer will do? It is much better to give an error as soon as possible to avoid creating a model that can't be printed. Yes the printer may print something but it won't match the physically impossible model.

In answer to the original question. I don't find OpenSCAD limiting for creating my designs at the moment. What I would like to see is module literals to match function literals and a dict / record type. That would tidy up my code.

A faster geometry engine like Carve looks like it would transform OpenSCAD as a faster union would allow 3D Minkowski to be fast and that would allow 3D rounding to be practical.

On Tue, 12 Nov 2019 at 05:25, Adam Purdie <[hidden email]> wrote:

My suggestions:
1. Have a way of integrating custom libraries at the openscad level, i currently do "import(../../../project/projectfile.scad)" and it's a little tedious, a basic library path like the Arduino app has would be cool
2. make it so exports can retain colours (or colors if you wish) - may not be feasible for the current export formats
3. make the default features overrideable like in normal OO - for example the default center value is "center=false" it would be really nice to be able to say something like:
module square($params) {
  params[center] = true;
  default_square($params)
}
4. Create some kinda scheduler for the command line that runs multiple processes across threads - i currently do this with my own python code and it saves me heaps of rendering time to use all 12 vcpu's :)

On Tue, 12 Nov 2019 at 15:50, Steven Dick <[hidden email]> wrote:
Openscad is not a mesh editor.  You might be able to do simple things like fixing round off errors  during import (which is an eternal problem with STLs since every vertex is listed separately for every instance of every edge) ,  but fixing problems like holes and intersecting polygons is the job of a mesh editor like blender or meshlab.  Use the right tool for the right job.

Zero size polygons are similar to round off errors.  Some holes and cracks are not real and are caused by the importer not recognizing two instances of the same edge due to round off errors, and I can see the importer fixing these, but a real hole  or intersecting faces from a malformed mesh is much harder to fix.

On Mon, Nov 11, 2019 at 9:38 PM Sarah Cartwright <[hidden email]> wrote:

I'd love the "thrown together" option to display holes, and intersecting polygons.
Very useful for STL file imports.

Would it be possible to fix intersecting polygons, zero volume polygons and holes in OpenSCAD's import?
It sounds difficult - but would make including existing models so much easier.
 
_______________________________________________
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
_______________________________________________
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: User Poll: What do you want to see from OpenSCAD development?

David Eccles (gringer)
In reply to this post by thehans
#3 [Addition of new features]

I'd like to see a function that returns the points that would be encoded in
a rendered version of its children. For 2D objects, this would return a
[2Dpoints, paths] result; for 3D objects a [3Dpoints, faces] result, as used
in the polygon & polyhedron functions respectively.

Assuming this function were called "points", then
"polygon(points(2Dconstruction))" should produce an identical result to
"render(2Dconstruction)", and likewise "polyhedron(points(3Dconstruction))"
should produce an identical result to render(3Dconstruction).

Such a function would substantially simplify the code required for extruding
an arbitrarily complex 2D object along a path, implementing a 3D offset /
inset, and probably a lot of other things.



--
Sent from: http://forum.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: User Poll: What do you want to see from OpenSCAD development?

nophead
There is already a PR for extruding arbitrary 2D objects along a path, without needing to get at the coordinates. You can also do 3D inset with Minkowski, the only problem being it is very slow in CGAL.

On Tue, 12 Nov 2019 at 10:15, David Eccles (gringer) <[hidden email]> wrote:
#3 [Addition of new features]

I'd like to see a function that returns the points that would be encoded in
a rendered version of its children. For 2D objects, this would return a
[2Dpoints, paths] result; for 3D objects a [3Dpoints, faces] result, as used
in the polygon & polyhedron functions respectively.

Assuming this function were called "points", then
"polygon(points(2Dconstruction))" should produce an identical result to
"render(2Dconstruction)", and likewise "polyhedron(points(3Dconstruction))"
should produce an identical result to render(3Dconstruction).

Such a function would substantially simplify the code required for extruding
an arbitrarily complex 2D object along a path, implementing a 3D offset /
inset, and probably a lot of other things.



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

_______________________________________________
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: User Poll: What do you want to see from OpenSCAD development?

Parkinbot
In reply to this post by nophead
Besides namespaces and at least a shift to OOP (overloading of modules and
functions, classes instead of use-files) I would like to see some means to
documentation and reflection in OpenSCAD.

1. the current snapshot has some sort of code complete for built-in
keywords. This could be extended to all modules, functions, variables
visible with respect to the scope. I think especially getting hints about
the signatures of modules and functions defined in libraries would be very
useful and avoid many of the new warnings about wrong parameters typos and
so on.

2. syntax for including a help system e.g.
  a)  //* myfunction() - this is the documentation of myfunction with HTML
allowed *//  
  b)  help ("myfunction", "myfile.scad") to output documentation in the
console window. An attribute like "showcode=true" could also list the
definition of myfunction()

3. links to source code in warnings and errors

4. expected signatures of malused functions and modules in warnings and
errors





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

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