Model Not rendering, CGal error

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Model Not rendering, CGal error

FourthDr
Hi:

Seems my stl model has some error, because OpenSCAD won't render it. Preview is fine. But when I try to render or export it gives me this CGAL error. See attached stl. back_cover_no_stand-2.stl

*******
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation! Expr: e->incident_sface() != SFace_const_handle() File: /opt/mxe/usr/i686-w64-mingw32.static/include/CGAL/Nef_S2/SM_const_decorator.h Line: 326
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation! Expr: e->incident_sface() != SFace_const_handle() File: /opt/mxe/usr/i686-w64-mingw32.static/include/CGAL/Nef_S2/SM_const_decorator.h Line: 326
Geometries in cache: 52
Geometry cache size in bytes: 636256
CGAL Polyhedrons in cache: 32
CGAL cache size in bytes: 831776
Total rendering time: 0 hours, 0 minutes, 1 seconds
Rendering finished.
*******

Also, is there a good tool for fixing stl files? I have tried several of the major ones like netfabb but they don't always actually fix the file even though they say it is fixed.  And after being fixed the stl opens in my 3D printing software without a "not manifold" error. But when I want to use OpenSCAD to say puzzle a large piece into smaller parts it often still won't render or export.

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Model Not rendering, CGal error

FourthDr
Well, I tried a few random models that are manifold for thingivese and it seem any model that was not originally created inside of OpenSCAD will not render. I'm confused as to why that would be the case??
Reply | Threaded
Open this post in threaded view
|

Re: Model Not rendering, CGal error

nophead
I think OpenSCAD doesn't accept an STLs with very close vertices. I think it snaps them to a grid making close vertices coincident.

On 28 August 2017 at 09:04, FourthDr <[hidden email]> wrote:
Well, I tried a few random models that are manifold for thingivese and it
seem any model that was not originally created inside of OpenSCAD will not
render. I'm confused as to why that would be the case??



--
View this message in context: http://forum.openscad.org/Model-Not-rendering-CGal-error-tp22122p22132.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
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: Model Not rendering, CGal error

codifies
In reply to this post by FourthDr
This has been my experience exactly, where as I'd rather edit STL's with
openSCAD I increasingly find myself
using blender, which ain't great for mm perfect aligning of hole / objects!

Its a real shame something can't be done about the STL importer munging
vetices together, and indeed
I assume this is a bug because I can't see it being a feature!

This is one area where openSCAD has a particular weakness which is in
sharp contrast to the rest of the
package!

Chris


On 28/08/17 09:04, FourthDr wrote:

> Well, I tried a few random models that are manifold for thingivese and it
> seem any model that was not originally created inside of OpenSCAD will not
> render. I'm confused as to why that would be the case??
>
>
>
> --
> View this message in context: http://forum.openscad.org/Model-Not-rendering-CGal-error-tp22122p22132.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
>
> _______________________________________________
> 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: Model Not rendering, CGal error

cacb
On 28. aug. 2017 12:18, Mr C Camacho wrote:
> Its a real shame something can't be done about the STL importer munging
> vetices together, and indeed
> I assume this is a bug because I can't see it being a feature!
>
> This is one area where openSCAD has a particular weakness which is in
> sharp contrast to the rest of the
> package!
>
> Chris

OpenSCAD and other CAD programs use internal data structures with
explicit topology, i.e. it has explicit representation of which faces
connect to which vertices etc.

The STL format is one of the few file formats that does not contain such
topology information. An STL file is just a "soup" of disconnected
triangles.

To import from STL to OpenSCAD, the program has to make a guess at what
the topology should really be, i.e. how to "munge vertices together".
There is in fact no other way as long as you deal with STL. The guess is
really assuming coordinate tolerances.

If the STL file has (unstated) coordinate units sufficiently different
from the assumptions in OpenSCAD, you will indeed get "odd" results,
i.e. results that do not match your expectations. But no software can
read your mind so it is unable to adjust for such expectations.

To handle the problem better there are some possibilities:

One is to make sure the assumptions of the STL files to be imported at
least roughly match the assumptions in OpenSCAD. Easier said than done,
but without modifying the software this is what is required. I.e. use
millimeter coordinates and don't make the models unreasonably small.

Another possibility would be to be able to state in the import() command
what the coordinate tolerance in the STL file is supposed to be (such a
feature does not exist now). Still, it can be difficult to choose a good
tolerance value so it would not solve all cases, plus other side effects
tend to show up here.

A third option would be to also allow import of file formats with
explicit topology, and thus avoid making any coordinate tolerance
assumptions during import. Such formats include AMF, OBJ, OFF and more.
Then there would be absolutely no "munging" going on and it would work
the same in all programs.

In short, STL was not relly designed for exchanging models between CAD
applications. It is mostly ok as input to a slicer program, but as a
CAD-to-CAD exchange format it is poor, and prone to surprises when used
that way.

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: Model Not rendering, CGal error

nophead
I think it only goes wrong because OpenSCAD snaps to a grid. If it just read the floating point numbers without adjusting them it would work. You can't snap geometry blindly to a grid without breaking the topology.

On 28 August 2017 at 21:48, Carsten Arnholm <[hidden email]> wrote:
On 28. aug. 2017 12:18, Mr C Camacho wrote:
Its a real shame something can't be done about the STL importer munging vetices together, and indeed
I assume this is a bug because I can't see it being a feature!

This is one area where openSCAD has a particular weakness which is in sharp contrast to the rest of the
package!

Chris

OpenSCAD and other CAD programs use internal data structures with explicit topology, i.e. it has explicit representation of which faces connect to which vertices etc.

The STL format is one of the few file formats that does not contain such topology information. An STL file is just a "soup" of disconnected triangles.

To import from STL to OpenSCAD, the program has to make a guess at what the topology should really be, i.e. how to "munge vertices together". There is in fact no other way as long as you deal with STL. The guess is really assuming coordinate tolerances.

If the STL file has (unstated) coordinate units sufficiently different from the assumptions in OpenSCAD, you will indeed get "odd" results, i.e. results that do not match your expectations. But no software can read your mind so it is unable to adjust for such expectations.

To handle the problem better there are some possibilities:

One is to make sure the assumptions of the STL files to be imported at least roughly match the assumptions in OpenSCAD. Easier said than done, but without modifying the software this is what is required. I.e. use millimeter coordinates and don't make the models unreasonably small.

Another possibility would be to be able to state in the import() command what the coordinate tolerance in the STL file is supposed to be (such a feature does not exist now). Still, it can be difficult to choose a good tolerance value so it would not solve all cases, plus other side effects tend to show up here.

A third option would be to also allow import of file formats with explicit topology, and thus avoid making any coordinate tolerance assumptions during import. Such formats include AMF, OBJ, OFF and more. Then there would be absolutely no "munging" going on and it would work the same in all programs.

In short, STL was not relly designed for exchanging models between CAD applications. It is mostly ok as input to a slicer program, but as a CAD-to-CAD exchange format it is poor, and prone to surprises when used that way.

Carsten Arnholm


_______________________________________________
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: Model Not rendering, CGal error

RobWLakes
In reply to this post by cacb

Good question, and a very good answer.

I appreciate much hard work has been done on OpenSCAD already, and if the import "AMF, OBJ, OFF and more" was trivial it would be done by now.

Do you think this is likely to be added in the near future?

Thanks, Rob


On 29/08/17 06:48, Carsten Arnholm wrote:
On 28. aug. 2017 12:18, Mr C Camacho wrote:
Its a real shame something can't be done about the STL importer munging vetices together, and indeed
I assume this is a bug because I can't see it being a feature!

This is one area where openSCAD has a particular weakness which is in sharp contrast to the rest of the
package!

Chris

OpenSCAD and other CAD programs use internal data structures with explicit topology, i.e. it has explicit representation of which faces connect to which vertices etc.

The STL format is one of the few file formats that does not contain such topology information. An STL file is just a "soup" of disconnected triangles.

To import from STL to OpenSCAD, the program has to make a guess at what the topology should really be, i.e. how to "munge vertices together". There is in fact no other way as long as you deal with STL. The guess is really assuming coordinate tolerances.

If the STL file has (unstated) coordinate units sufficiently different from the assumptions in OpenSCAD, you will indeed get "odd" results, i.e. results that do not match your expectations. But no software can read your mind so it is unable to adjust for such expectations.

To handle the problem better there are some possibilities:

One is to make sure the assumptions of the STL files to be imported at least roughly match the assumptions in OpenSCAD. Easier said than done, but without modifying the software this is what is required. I.e. use millimeter coordinates and don't make the models unreasonably small.

Another possibility would be to be able to state in the import() command what the coordinate tolerance in the STL file is supposed to be (such a feature does not exist now). Still, it can be difficult to choose a good tolerance value so it would not solve all cases, plus other side effects tend to show up here.

A third option would be to also allow import of file formats with explicit topology, and thus avoid making any coordinate tolerance assumptions during import. Such formats include AMF, OBJ, OFF and more. Then there would be absolutely no "munging" going on and it would work the same in all programs.

In short, STL was not relly designed for exchanging models between CAD applications. It is mostly ok as input to a slicer program, but as a CAD-to-CAD exchange format it is poor, and prone to surprises when used that way.

Carsten Arnholm


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


--

Rob Ward
Lake Tyers Beach, 3909
Lake Tyers Beach Website
Ubuntu Mate - A great OS


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Rob W
Lake Tyers Beach,
Victoria, Australia
Reply | Threaded
Open this post in threaded view
|

Re: Model Not rendering, CGal error

cacb
On 2017-08-29 01:28, Rob Ward wrote:
> Good question, and a very good answer.
>
> I appreciate much hard work has been done on OpenSCAD already, and if
> the import "AMF, OBJ, OFF and more" was trivial it would be done by
> now.
>
> Do you think this is likely to be added in the near future?
>
> Thanks, Rob

On the last question, I am not an OpenSCAD developer so I cannot answer
for what will be added or when.

The assumption about what is trivial to import is in fact 180 degrees
wrong (no disrespect). It is STL import that is non-trivial for the
reasons given, and the opening posts in this thread are examples of
users experiencing the problems that can occur with it. Importing from a
format with given topology is trivial in comparison because no
coordinate assumptions are required.

I have developed a similar application that does AMF import (as
described at
https://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format ). I
have also done work on converting of STL files, so I know it from both
angles. It is STL that is non-trivial, for the reasons given.

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: Model Not rendering, CGal error

Ronaldo
In reply to this post by cacb
There are some aspects of this discussion that are not clear to me. It is clear that STL file format has no topology information however I don't see this as the main cause of troubles. In the Openscad polyhedron primitive, for instance, we have some topology information in the face list that is specified by vertex references and not vertex coordinates like in STL files. If I define a polyhedron with 5 faces of a cube (and 8 vertices) it could easily be discarded as a manifold, by just reading the face list, once there are some topological edges with only one adjacent face. Suppose now that I add the 6th cube face but refer its topological vertices as 4 new distinguished geometrical vertices as in the following:

verts = [ [0,0,0], [1,0,0], [1,1,0], [0,1,0],
          [0,0,1], [1,0,1], [1,1,1], [0,1,1],
          [1,1,0], [1,0,0], [1,0,1], [1,1,1] ];
          
faces = [ [0,1,2,3], [5,4,7,6], 
          [1,0,4,5], [3,2,6,7], 
          [0,3,7,4], 
          [8,9,10,11] ]; // instead of [2,1,5,6] ];
          
polyhedron(points=verts, faces=faces);

If we just look at the topological information of this polyhedron (its face list) we would say it is not a manifold because the topological edge [1,2], for instance, has just the first face incident to it. But if we take in account the vertex coordinate list it is clear that vertex 2 and 8 are geometrically identical ( and so are 1 and 9, 5 and 10, 6 and 11).

We have two main ways to consider the check of manifoldness for this case: either rely only on the topological information or also consider the geometrical information. In the former case, the above polyhedron would be considered as two separate (but not disjoint) manifold with boundary. In the later, it will be considered a manifold without boundary (a closed manifold).

Which way to choose is a design decision but any of them has its merits and demerits. In the former option, we will be in trouble if two topological vertices have the same geometry. In the later, we must compare vertex geometries to complete the topological model. In any case, self intersections in the object boundary geometry has to be considered and threshold are needed in the vertex coordinate comparisons.

In the current version of Openscad, the later option seems to be the choice as the following code may suggest.

d = epsilon*[1,1,1];

verts = [ [0,0,0], [1,0,0], [1,1,0], [0,1,0],
          [0,0,1], [1,0,1], [1,1,1], [0,1,1],
          [1,1,0]+d, [1,0,0]+d, [1,0,1]+d, [1,1,1]+d ];
          
faces = [ [0,1,2,3], [5,4,7,6], 
          [1,0,4,5], [3,2,6,7], 
          [0,3,7,4], 
          [8,9,10,11] ]; // instead of [2,1,5,6] ];
          
difference(){
    polyhedron(points=verts, faces=faces);
    translate([0.5,-0.5,-0.5]) cube(1);
}

If we set epsilon to some absolute value bellow 1e-08, CGAL will not complaint. With epsilon=1e-4, it does.

It seems to me that we cannot get rid of the geometrical information and all its burden to check manifold validity. Even when the topological information is part of the file like in AMF, the comparison of vertex geometries are unavoidable. Concluding, I don't think the missing topological information in STL files is the cause of troubles. The devil is in the floating point representation of the geometry.

2017-08-28 21:48 GMT+01:00 Carsten Arnholm <[hidden email]>:
On 28. aug. 2017 12:18, Mr C Camacho wrote:
Its a real shame something can't be done about the STL importer munging vetices together, and indeed
I assume this is a bug because I can't see it being a feature!

This is one area where openSCAD has a particular weakness which is in sharp contrast to the rest of the
package!

Chris

OpenSCAD and other CAD programs use internal data structures with explicit topology, i.e. it has explicit representation of which faces connect to which vertices etc.

The STL format is one of the few file formats that does not contain such topology information. An STL file is just a "soup" of disconnected triangles.

To import from STL to OpenSCAD, the program has to make a guess at what the topology should really be, i.e. how to "munge vertices together". There is in fact no other way as long as you deal with STL. The guess is really assuming coordinate tolerances.

If the STL file has (unstated) coordinate units sufficiently different from the assumptions in OpenSCAD, you will indeed get "odd" results, i.e. results that do not match your expectations. But no software can read your mind so it is unable to adjust for such expectations.

To handle the problem better there are some possibilities:

One is to make sure the assumptions of the STL files to be imported at least roughly match the assumptions in OpenSCAD. Easier said than done, but without modifying the software this is what is required. I.e. use millimeter coordinates and don't make the models unreasonably small.

Another possibility would be to be able to state in the import() command what the coordinate tolerance in the STL file is supposed to be (such a feature does not exist now). Still, it can be difficult to choose a good tolerance value so it would not solve all cases, plus other side effects tend to show up here.

A third option would be to also allow import of file formats with explicit topology, and thus avoid making any coordinate tolerance assumptions during import. Such formats include AMF, OBJ, OFF and more. Then there would be absolutely no "munging" going on and it would work the same in all programs.

In short, STL was not relly designed for exchanging models between CAD applications. It is mostly ok as input to a slicer program, but as a CAD-to-CAD exchange format it is poor, and prone to surprises when used that way.

Carsten Arnholm



_______________________________________________
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: Model Not rendering, CGal error

nophead
I don't think the problem has anything to do with STL or floating point. I think it is this: https://github.com/openscad/openscad/blob/0904a3b3a5b56b16bb423b177972468eeca775a9/src/grid.h

You can't snap vertices to a grid without risking breaking the topology when they are close compared to the grid size. If I import STLs from CAD systems that produce high resolution curves it breaks. Nothing wrong with the STL file, just vertices closer that the grid.

On 29 August 2017 at 12:45, Ronaldo Persiano <[hidden email]> wrote:
There are some aspects of this discussion that are not clear to me. It is clear that STL file format has no topology information however I don't see this as the main cause of troubles. In the Openscad polyhedron primitive, for instance, we have some topology information in the face list that is specified by vertex references and not vertex coordinates like in STL files. If I define a polyhedron with 5 faces of a cube (and 8 vertices) it could easily be discarded as a manifold, by just reading the face list, once there are some topological edges with only one adjacent face. Suppose now that I add the 6th cube face but refer its topological vertices as 4 new distinguished geometrical vertices as in the following:

verts = [ [0,0,0], [1,0,0], [1,1,0], [0,1,0],
          [0,0,1], [1,0,1], [1,1,1], [0,1,1],
          [1,1,0], [1,0,0], [1,0,1], [1,1,1] ];
          
faces = [ [0,1,2,3], [5,4,7,6], 
          [1,0,4,5], [3,2,6,7], 
          [0,3,7,4], 
          [8,9,10,11] ]; // instead of [2,1,5,6] ];
          
polyhedron(points=verts, faces=faces);

If we just look at the topological information of this polyhedron (its face list) we would say it is not a manifold because the topological edge [1,2], for instance, has just the first face incident to it. But if we take in account the vertex coordinate list it is clear that vertex 2 and 8 are geometrically identical ( and so are 1 and 9, 5 and 10, 6 and 11).

We have two main ways to consider the check of manifoldness for this case: either rely only on the topological information or also consider the geometrical information. In the former case, the above polyhedron would be considered as two separate (but not disjoint) manifold with boundary. In the later, it will be considered a manifold without boundary (a closed manifold).

Which way to choose is a design decision but any of them has its merits and demerits. In the former option, we will be in trouble if two topological vertices have the same geometry. In the later, we must compare vertex geometries to complete the topological model. In any case, self intersections in the object boundary geometry has to be considered and threshold are needed in the vertex coordinate comparisons.

In the current version of Openscad, the later option seems to be the choice as the following code may suggest.

d = epsilon*[1,1,1];

verts = [ [0,0,0], [1,0,0], [1,1,0], [0,1,0],
          [0,0,1], [1,0,1], [1,1,1], [0,1,1],
          [1,1,0]+d, [1,0,0]+d, [1,0,1]+d, [1,1,1]+d ];
          
faces = [ [0,1,2,3], [5,4,7,6], 
          [1,0,4,5], [3,2,6,7], 
          [0,3,7,4], 
          [8,9,10,11] ]; // instead of [2,1,5,6] ];
          
difference(){
    polyhedron(points=verts, faces=faces);
    translate([0.5,-0.5,-0.5]) cube(1);
}

If we set epsilon to some absolute value bellow 1e-08, CGAL will not complaint. With epsilon=1e-4, it does.

It seems to me that we cannot get rid of the geometrical information and all its burden to check manifold validity. Even when the topological information is part of the file like in AMF, the comparison of vertex geometries are unavoidable. Concluding, I don't think the missing topological information in STL files is the cause of troubles. The devil is in the floating point representation of the geometry.

2017-08-28 21:48 GMT+01:00 Carsten Arnholm <[hidden email]>:
On 28. aug. 2017 12:18, Mr C Camacho wrote:
Its a real shame something can't be done about the STL importer munging vetices together, and indeed
I assume this is a bug because I can't see it being a feature!

This is one area where openSCAD has a particular weakness which is in sharp contrast to the rest of the
package!

Chris

OpenSCAD and other CAD programs use internal data structures with explicit topology, i.e. it has explicit representation of which faces connect to which vertices etc.

The STL format is one of the few file formats that does not contain such topology information. An STL file is just a "soup" of disconnected triangles.

To import from STL to OpenSCAD, the program has to make a guess at what the topology should really be, i.e. how to "munge vertices together". There is in fact no other way as long as you deal with STL. The guess is really assuming coordinate tolerances.

If the STL file has (unstated) coordinate units sufficiently different from the assumptions in OpenSCAD, you will indeed get "odd" results, i.e. results that do not match your expectations. But no software can read your mind so it is unable to adjust for such expectations.

To handle the problem better there are some possibilities:

One is to make sure the assumptions of the STL files to be imported at least roughly match the assumptions in OpenSCAD. Easier said than done, but without modifying the software this is what is required. I.e. use millimeter coordinates and don't make the models unreasonably small.

Another possibility would be to be able to state in the import() command what the coordinate tolerance in the STL file is supposed to be (such a feature does not exist now). Still, it can be difficult to choose a good tolerance value so it would not solve all cases, plus other side effects tend to show up here.

A third option would be to also allow import of file formats with explicit topology, and thus avoid making any coordinate tolerance assumptions during import. Such formats include AMF, OBJ, OFF and more. Then there would be absolutely no "munging" going on and it would work the same in all programs.

In short, STL was not relly designed for exchanging models between CAD applications. It is mostly ok as input to a slicer program, but as a CAD-to-CAD exchange format it is poor, and prone to surprises when used that way.

Carsten Arnholm



_______________________________________________
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: Model Not rendering, CGal error

RobWLakes

I am not an expert here.... apologies where required... So what you are saying nop head, is the vertices of some STLs are close enough for a slicer to make a satisfactory model, but not reliable enough to be always be deconstructed to an unambiguous OpenSCAD topology (reverse engineered)?  In other words, the fact that OpenSCAD allows practical construction of STLs,  does not mean OpenSCAD can perfectly interpret every STL (even though it may be printable in practice), even some OpenSCAD exported STL's?

Rob


On 29/08/17 22:01, nop head wrote:
I don't think the problem has anything to do with STL or floating point. I think it is this: https://github.com/openscad/openscad/blob/0904a3b3a5b56b16bb423b177972468eeca775a9/src/grid.h

You can't snap vertices to a grid without risking breaking the topology when they are close compared to the grid size. If I import STLs from CAD systems that produce high resolution curves it breaks. Nothing wrong with the STL file, just vertices closer that the grid.

On 29 August 2017 at 12:45, Ronaldo Persiano <[hidden email]> wrote:
There are some aspects of this discussion that are not clear to me. It is clear that STL file format has no topology information however I don't see this as the main cause of troubles. In the Openscad polyhedron primitive, for instance, we have some topology information in the face list that is specified by vertex references and not vertex coordinates like in STL files. If I define a polyhedron with 5 faces of a cube (and 8 vertices) it could easily be discarded as a manifold, by just reading the face list, once there are some topological edges with only one adjacent face. Suppose now that I add the 6th cube face but refer its topological vertices as 4 new distinguished geometrical vertices as in the following:

verts = [ [0,0,0], [1,0,0], [1,1,0], [0,1,0],
          [0,0,1], [1,0,1], [1,1,1], [0,1,1],
          [1,1,0], [1,0,0], [1,0,1], [1,1,1] ];
          
faces = [ [0,1,2,3], [5,4,7,6], 
          [1,0,4,5], [3,2,6,7], 
          [0,3,7,4], 
          [8,9,10,11] ]; // instead of [2,1,5,6] ];
          
polyhedron(points=verts, faces=faces);

If we just look at the topological information of this polyhedron (its face list) we would say it is not a manifold because the topological edge [1,2], for instance, has just the first face incident to it. But if we take in account the vertex coordinate list it is clear that vertex 2 and 8 are geometrically identical ( and so are 1 and 9, 5 and 10, 6 and 11).

We have two main ways to consider the check of manifoldness for this case: either rely only on the topological information or also consider the geometrical information. In the former case, the above polyhedron would be considered as two separate (but not disjoint) manifold with boundary. In the later, it will be considered a manifold without boundary (a closed manifold).

Which way to choose is a design decision but any of them has its merits and demerits. In the former option, we will be in trouble if two topological vertices have the same geometry. In the later, we must compare vertex geometries to complete the topological model. In any case, self intersections in the object boundary geometry has to be considered and threshold are needed in the vertex coordinate comparisons.

In the current version of Openscad, the later option seems to be the choice as the following code may suggest.

d = epsilon*[1,1,1];

verts = [ [0,0,0], [1,0,0], [1,1,0], [0,1,0],
          [0,0,1], [1,0,1], [1,1,1], [0,1,1],
          [1,1,0]+d, [1,0,0]+d, [1,0,1]+d, [1,1,1]+d ];
          
faces = [ [0,1,2,3], [5,4,7,6], 
          [1,0,4,5], [3,2,6,7], 
          [0,3,7,4], 
          [8,9,10,11] ]; // instead of [2,1,5,6] ];
          
difference(){
    polyhedron(points=verts, faces=faces);
    translate([0.5,-0.5,-0.5]) cube(1);
}

If we set epsilon to some absolute value bellow 1e-08, CGAL will not complaint. With epsilon=1e-4, it does.

It seems to me that we cannot get rid of the geometrical information and all its burden to check manifold validity. Even when the topological information is part of the file like in AMF, the comparison of vertex geometries are unavoidable. Concluding, I don't think the missing topological information in STL files is the cause of troubles. The devil is in the floating point representation of the geometry.

2017-08-28 21:48 GMT+01:00 Carsten Arnholm <[hidden email]>:
On 28. aug. 2017 12:18, Mr C Camacho wrote:
Its a real shame something can't be done about the STL importer munging vetices together, and indeed
I assume this is a bug because I can't see it being a feature!

This is one area where openSCAD has a particular weakness which is in sharp contrast to the rest of the
package!

Chris

OpenSCAD and other CAD programs use internal data structures with explicit topology, i.e. it has explicit representation of which faces connect to which vertices etc.

The STL format is one of the few file formats that does not contain such topology information. An STL file is just a "soup" of disconnected triangles.

To import from STL to OpenSCAD, the program has to make a guess at what the topology should really be, i.e. how to "munge vertices together". There is in fact no other way as long as you deal with STL. The guess is really assuming coordinate tolerances.

If the STL file has (unstated) coordinate units sufficiently different from the assumptions in OpenSCAD, you will indeed get "odd" results, i.e. results that do not match your expectations. But no software can read your mind so it is unable to adjust for such expectations.

To handle the problem better there are some possibilities:

One is to make sure the assumptions of the STL files to be imported at least roughly match the assumptions in OpenSCAD. Easier said than done, but without modifying the software this is what is required. I.e. use millimeter coordinates and don't make the models unreasonably small.

Another possibility would be to be able to state in the import() command what the coordinate tolerance in the STL file is supposed to be (such a feature does not exist now). Still, it can be difficult to choose a good tolerance value so it would not solve all cases, plus other side effects tend to show up here.

A third option would be to also allow import of file formats with explicit topology, and thus avoid making any coordinate tolerance assumptions during import. Such formats include AMF, OBJ, OFF and more. Then there would be absolutely no "munging" going on and it would work the same in all programs.

In short, STL was not relly designed for exchanging models between CAD applications. It is mostly ok as input to a slicer program, but as a CAD-to-CAD exchange format it is poor, and prone to surprises when used that way.

Carsten Arnholm



_______________________________________________
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

--

Rob Ward
Lake Tyers Beach, 3909
Lake Tyers Beach Website
Ubuntu Mate - A great OS


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Rob W
Lake Tyers Beach,
Victoria, Australia
Reply | Threaded
Open this post in threaded view
|

Re: Model Not rendering, CGal error

cacb
In reply to this post by Ronaldo
On 2017-08-29 13:45, Ronaldo Persiano wrote:
> It seems to me that we cannot get rid of the geometrical information
> and all its burden to check manifold validity. Even when the
> topological information is part of the file like in AMF, the
> comparison of vertex geometries are unavoidable. Concluding, I don't
> think the missing topological information in STL files is the cause of
> troubles. The devil is in the floating point representation of the
> geometry.

You are talking about something else.

My point was exchanging 3d surface meshes between different CAD
applications in a non-ambiguous way, without having to make assumptions.

Whether the mesh has such things as non-manifoldness or duplicate
vertices (different vertices with identical coordinates) is a very
different question to the question of reliably exchanging models.
OpenSCAD may *disagree* or disallow such cases if it wishes to do so,
but at least it is possible to know what has been described. That is in
general not the case with STL.

Anyway, as long as these things are not recognized, the same issues will
occur again and again. I recommend giving it a thought though.

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: Model Not rendering, CGal error

codifies
In reply to this post by cacb
I must be misunderstanding something because especially the OBJ format
when I have written an importer
for games all you get is a "soup" of triangles...

On 28/08/17 21:48, Carsten Arnholm wrote:

> On 28. aug. 2017 12:18, Mr C Camacho wrote:
>> Its a real shame something can't be done about the STL importer
>> munging vetices together, and indeed
>> I assume this is a bug because I can't see it being a feature!
>>
>> This is one area where openSCAD has a particular weakness which is in
>> sharp contrast to the rest of the
>> package!
>>
>> Chris
>
> OpenSCAD and other CAD programs use internal data structures with
> explicit topology, i.e. it has explicit representation of which faces
> connect to which vertices etc.
>
> The STL format is one of the few file formats that does not contain
> such topology information. An STL file is just a "soup" of
> disconnected triangles.
>
> To import from STL to OpenSCAD, the program has to make a guess at
> what the topology should really be, i.e. how to "munge vertices
> together". There is in fact no other way as long as you deal with STL.
> The guess is really assuming coordinate tolerances.
>
> If the STL file has (unstated) coordinate units sufficiently different
> from the assumptions in OpenSCAD, you will indeed get "odd" results,
> i.e. results that do not match your expectations. But no software can
> read your mind so it is unable to adjust for such expectations.
>
> To handle the problem better there are some possibilities:
>
> One is to make sure the assumptions of the STL files to be imported at
> least roughly match the assumptions in OpenSCAD. Easier said than
> done, but without modifying the software this is what is required.
> I.e. use millimeter coordinates and don't make the models unreasonably
> small.
>
> Another possibility would be to be able to state in the import()
> command what the coordinate tolerance in the STL file is supposed to
> be (such a feature does not exist now). Still, it can be difficult to
> choose a good tolerance value so it would not solve all cases, plus
> other side effects tend to show up here.
>
> A third option would be to also allow import of file formats with
> explicit topology, and thus avoid making any coordinate tolerance
> assumptions during import. Such formats include AMF, OBJ, OFF and
> more. Then there would be absolutely no "munging" going on and it
> would work the same in all programs.
>
> In short, STL was not relly designed for exchanging models between CAD
> applications. It is mostly ok as input to a slicer program, but as a
> CAD-to-CAD exchange format it is poor, and prone to surprises when
> used that way.
>
> Carsten Arnholm
>
>
> _______________________________________________
> 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: Model Not rendering, CGal error

cacb
On 2017-08-29 15:41, Mr C Camacho wrote:
> I must be misunderstanding something because especially the OBJ format
> when I have written an importer
> for games all you get is a "soup" of triangles...

https://en.wikipedia.org/wiki/Wavefront_.obj_file#Vertex_Indices

Vertices
  v 0.123 0.234 0.345 1.0
  v ...

Faces
  f 214 27 29
  f ...

Example e.g. whistle.obj
  https://www.thingiverse.com/thing:1046/#files

Vertices are independent from faces. Faces refer to vertices, that is
the topology. It is not a soup of disconnected triangles when multiple
faces refer to the same vertex.

For graphics in games the topology is unimportant. For CAD it is
important.

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: Model Not rendering, CGal error

nophead
In reply to this post by RobWLakes


On 29 August 2017 at 13:43, Rob Ward <[hidden email]> wrote:

I am not an expert here.... apologies where required... So what you are saying nop head, is the vertices of some STLs are close enough for a slicer to make a satisfactory model, but not reliable enough to be always be deconstructed to an unambiguous OpenSCAD topology (reverse engineered)? 

Yes it is possible to have manifold STL files that a slicer would not have a problem with but OpenSCAD will.

If STLs contain manifold geometry, that is still manifold when represented as floats, then there is no problem recovering it unambiguously from the soup of triangles. I.e. as long as facet vertices with the same numerical value are coincident in the geometry no information is lost. If the geometry was non-manifold to start with, for example if it has self intersections like two cubes sharing an edge then STL is not a good way to represent it.
 

In other words, the fact that OpenSCAD allows practical construction of STLs,  does not mean OpenSCAD can perfectly interpret every STL (even though it may be printable in practice), even some OpenSCAD exported STL's?


My understanding is OpenSCAD cannot read perfectly constructed STL files if they have vertices closer than its internal grid. That is a bug.

OpenSCAD also does not always produce correct STL files because when it converts from greater precision to floating point some vertices can get truncated to the same value and merged. That is another bug but is fundamentally the same problem. You can't reduce the precision of the vertices of a mesh without ensuring that distinct vertices don't end up with identical truncated values.

 

Rob


On 29/08/17 22:01, nop head wrote:
I don't think the problem has anything to do with STL or floating point. I think it is this: https://github.com/openscad/openscad/blob/0904a3b3a5b56b16bb423b177972468eeca775a9/src/grid.h

You can't snap vertices to a grid without risking breaking the topology when they are close compared to the grid size. If I import STLs from CAD systems that produce high resolution curves it breaks. Nothing wrong with the STL file, just vertices closer that the grid.

On 29 August 2017 at 12:45, Ronaldo Persiano <[hidden email]> wrote:
There are some aspects of this discussion that are not clear to me. It is clear that STL file format has no topology information however I don't see this as the main cause of troubles. In the Openscad polyhedron primitive, for instance, we have some topology information in the face list that is specified by vertex references and not vertex coordinates like in STL files. If I define a polyhedron with 5 faces of a cube (and 8 vertices) it could easily be discarded as a manifold, by just reading the face list, once there are some topological edges with only one adjacent face. Suppose now that I add the 6th cube face but refer its topological vertices as 4 new distinguished geometrical vertices as in the following:

verts = [ [0,0,0], [1,0,0], [1,1,0], [0,1,0],
          [0,0,1], [1,0,1], [1,1,1], [0,1,1],
          [1,1,0], [1,0,0], [1,0,1], [1,1,1] ];
          
faces = [ [0,1,2,3], [5,4,7,6], 
          [1,0,4,5], [3,2,6,7], 
          [0,3,7,4], 
          [8,9,10,11] ]; // instead of [2,1,5,6] ];
          
polyhedron(points=verts, faces=faces);

If we just look at the topological information of this polyhedron (its face list) we would say it is not a manifold because the topological edge [1,2], for instance, has just the first face incident to it. But if we take in account the vertex coordinate list it is clear that vertex 2 and 8 are geometrically identical ( and so are 1 and 9, 5 and 10, 6 and 11).

We have two main ways to consider the check of manifoldness for this case: either rely only on the topological information or also consider the geometrical information. In the former case, the above polyhedron would be considered as two separate (but not disjoint) manifold with boundary. In the later, it will be considered a manifold without boundary (a closed manifold).

Which way to choose is a design decision but any of them has its merits and demerits. In the former option, we will be in trouble if two topological vertices have the same geometry. In the later, we must compare vertex geometries to complete the topological model. In any case, self intersections in the object boundary geometry has to be considered and threshold are needed in the vertex coordinate comparisons.

In the current version of Openscad, the later option seems to be the choice as the following code may suggest.

d = epsilon*[1,1,1];

verts = [ [0,0,0], [1,0,0], [1,1,0], [0,1,0],
          [0,0,1], [1,0,1], [1,1,1], [0,1,1],
          [1,1,0]+d, [1,0,0]+d, [1,0,1]+d, [1,1,1]+d ];
          
faces = [ [0,1,2,3], [5,4,7,6], 
          [1,0,4,5], [3,2,6,7], 
          [0,3,7,4], 
          [8,9,10,11] ]; // instead of [2,1,5,6] ];
          
difference(){
    polyhedron(points=verts, faces=faces);
    translate([0.5,-0.5,-0.5]) cube(1);
}

If we set epsilon to some absolute value bellow 1e-08, CGAL will not complaint. With epsilon=1e-4, it does.

It seems to me that we cannot get rid of the geometrical information and all its burden to check manifold validity. Even when the topological information is part of the file like in AMF, the comparison of vertex geometries are unavoidable. Concluding, I don't think the missing topological information in STL files is the cause of troubles. The devil is in the floating point representation of the geometry.

2017-08-28 21:48 GMT+01:00 Carsten Arnholm <[hidden email]>:
On 28. aug. 2017 12:18, Mr C Camacho wrote:
Its a real shame something can't be done about the STL importer munging vetices together, and indeed
I assume this is a bug because I can't see it being a feature!

This is one area where openSCAD has a particular weakness which is in sharp contrast to the rest of the
package!

Chris

OpenSCAD and other CAD programs use internal data structures with explicit topology, i.e. it has explicit representation of which faces connect to which vertices etc.

The STL format is one of the few file formats that does not contain such topology information. An STL file is just a "soup" of disconnected triangles.

To import from STL to OpenSCAD, the program has to make a guess at what the topology should really be, i.e. how to "munge vertices together". There is in fact no other way as long as you deal with STL. The guess is really assuming coordinate tolerances.

If the STL file has (unstated) coordinate units sufficiently different from the assumptions in OpenSCAD, you will indeed get "odd" results, i.e. results that do not match your expectations. But no software can read your mind so it is unable to adjust for such expectations.

To handle the problem better there are some possibilities:

One is to make sure the assumptions of the STL files to be imported at least roughly match the assumptions in OpenSCAD. Easier said than done, but without modifying the software this is what is required. I.e. use millimeter coordinates and don't make the models unreasonably small.

Another possibility would be to be able to state in the import() command what the coordinate tolerance in the STL file is supposed to be (such a feature does not exist now). Still, it can be difficult to choose a good tolerance value so it would not solve all cases, plus other side effects tend to show up here.

A third option would be to also allow import of file formats with explicit topology, and thus avoid making any coordinate tolerance assumptions during import. Such formats include AMF, OBJ, OFF and more. Then there would be absolutely no "munging" going on and it would work the same in all programs.

In short, STL was not relly designed for exchanging models between CAD applications. It is mostly ok as input to a slicer program, but as a CAD-to-CAD exchange format it is poor, and prone to surprises when used that way.

Carsten Arnholm



_______________________________________________
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

--

Rob Ward
Lake Tyers Beach, 3909
Lake Tyers Beach Website
Ubuntu Mate - A great OS


_______________________________________________
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: Model Not rendering, CGal error

codifies
In reply to this post by cacb
yes but quite often you end up with each face (of an OBJ) getting its
own vertices, even if really they should
be sharing vertices, so I'm not sure if an OBJ like this would be much
better than a STL ?


On 29/08/17 15:34, [hidden email] wrote:

> On 2017-08-29 15:41, Mr C Camacho wrote:
>> I must be misunderstanding something because especially the OBJ format
>> when I have written an importer
>> for games all you get is a "soup" of triangles...
>
> https://en.wikipedia.org/wiki/Wavefront_.obj_file#Vertex_Indices
>
> Vertices
>  v 0.123 0.234 0.345 1.0
>  v ...
>
> Faces
>  f 214 27 29
>  f ...
>
> Example e.g. whistle.obj
>  https://www.thingiverse.com/thing:1046/#files
>
> Vertices are independent from faces. Faces refer to vertices, that is
> the topology. It is not a soup of disconnected triangles when multiple
> faces refer to the same vertex.
>
> For graphics in games the topology is unimportant. For CAD it is
> important.
>
> Carsten Arnholm
>
>
>
>
>
>
> _______________________________________________
> 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: Model Not rendering, CGal error

cacb
On 29. aug. 2017 19:57, Mr C Camacho wrote:
 > yes but quite often you end up with each face (of an OBJ) getting its
 > own vertices, even if really they should
 > be sharing vertices,

No, not in CAD programs. Not in OpenSCAD or other programs doing
booleans on surface meshes. As mentioned before: "OpenSCAD and other CAD
programs use internal data structures with explicit topology, i.e. it
has explicit representation of which faces connect to which vertices etc. "

http://forum.openscad.org/Model-Not-rendering-CGal-error-tp22122p22135.html

A well defined topology is *required* to do booleans. To be more
specific, OpenSCAD requires a 2-manifold topology. You either have it or
you must guess it. Guessing often does not work, as demonstrated by the
topic of this thread.

 > so I'm not sure if an OBJ like this would be much
 > better than a STL ?

See above, it has been explained already.

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: Model Not rendering, CGal error

codifies
well I've had plenty of experience of seeing badly formed OBJ files, and
there is nothing intrinsic in
file format to prevent this.

On 29/08/17 23:02, Carsten Arnholm wrote:

> On 29. aug. 2017 19:57, Mr C Camacho wrote:
> > yes but quite often you end up with each face (of an OBJ) getting its
> > own vertices, even if really they should
> > be sharing vertices,
>
> No, not in CAD programs. Not in OpenSCAD or other programs doing
> booleans on surface meshes. As mentioned before: "OpenSCAD and other
> CAD programs use internal data structures with explicit topology, i.e.
> it has explicit representation of which faces connect to which
> vertices etc. "
>
> http://forum.openscad.org/Model-Not-rendering-CGal-error-tp22122p22135.html 
>
>
> A well defined topology is *required* to do booleans. To be more
> specific, OpenSCAD requires a 2-manifold topology. You either have it
> or you must guess it. Guessing often does not work, as demonstrated by
> the topic of this thread.
>
> > so I'm not sure if an OBJ like this would be much
> > better than a STL ?
>
> See above, it has been explained already.
>
> Carsten Arnholm
>
>
>
> _______________________________________________
> 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: Model Not rendering, CGal error

cacb
On 2017-08-30 09:22, Mr C Camacho wrote:
> well I've had plenty of experience of seeing badly formed OBJ files,
> and there is nothing intrinsic in
> file format to prevent this.

You are missing the point. The issue is being able to communicate the
topology of a surface mesh in a non-ambiguous way. You can choose to
communicate a badly formed topology, but that is a completely different
issue.

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: Model Not rendering, CGal error

FourthDr
WOW lots of replies. So it seems a complicated issue to resolve. In the mean
time is there some free software that can break up a large print into
smaller pieces that can be re-assembled once printed? And lock together
securely with a secure shape like ball sock/dovetail/etc? I don't always
need this because the print is too large. Sometime it's because the print
has some features that otherwise need major support or are just plain hard
to print correctly in one piece. Any suggestions? I know I searched for some
software like that and found some, but the software was either costly or was
experimental and not really available, like a research project etc..



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

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