Can't find what's wrong here (use import stl and difference)
I am out now. I will send you in about one hour.
Em 16 de nov de 2016 14:10, "Johan Jonker" johangjonker@zonnet.nl
escreveu:
I am very interested to try that!
Johan Jonker wrote
I have an object without purple triangels. See the last wireframe I put in
the message.
Of this part I am quite sure that it has non planar faces. I think all the
quads in the curved sides are non planar.
I am also quite sure that the vertices are not very close.
The distance between the layers is .2 mm.
The curved corner makes has a radius of 1.25 mm and steps of 5 degrees.
But I can try to scale the design by a factor 100 and see what happens.
You have many options (the best would be to attach the piece of your code,
containing the problem).
- try skin(). I has exactly the same data interface. (I will not repeat
this option again) - Run your code with sweep(..., showslices = true) to see which slices get
close. Then reduce the call to subsets containing only two consecutive
polygons. - Write a function that returns the minimum mutual distance of all points
in a polygon (2D) - Write a function that returns the minimum distance of two polygons (in
3D) - Write a function that tests, if two polygons (in 3D) overlap.
sweep() triangulates any quads in the "sides" of an extrusion path (by
connecting consecutive polygons). But the caps (i.e. first and last polygon)
are triangulated by OpenSCAD/CGAL (which does not happen in the new torus
version)
--
View this message in context: http://forum.openscad.org/Can-t-find-what-s-wrong-here-use-import-stl-and-difference-tp19123p19154.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Ronaldo wrote
CGAL works with very strict testings. But it collapses vertices that are
equal or very very near. So, for things like a torus,
...
I have a simple polygon check function for planar polygons. If you need I
can provide the code.
Ronaldo, my experience is that CGAL will not touch a polyhedron at faces
already triangulated. So it might lead to trouble, when vertices get too
close. If Johan follows my advice and starts with a Polygon in 2D and uses
my affine transformations R_(), T_(), ... what he seems to do, it will stay
planar, but he has to take care of non-intersection and singularity problems
himself.
I'm thinking about changing sweep() to knit quad faces and let CGAL
triangulate them. But I have to test this first and I have more important
things to do.
For the torus: I implement things only when I need them. It was quite
trivial to implement the close = true option. You omit the face
definitions for the caps and add the connection of the first and the last
polygon. But for this you have to fiddle around with the "knitter" algorithm
for the triangulation.
--
View this message in context: http://forum.openscad.org/Can-t-find-what-s-wrong-here-use-import-stl-and-difference-tp19123p19156.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Johan Jonker wrote
I am very interested to try that!
The following code contains the polygon projection on its fitting plane, the
test for simple 2D polygons and the triangulation of simple 2D polygons:
polygon_triangulation.scad
http://forum.openscad.org/file/n19160/polygon_triangulation.scad
At the end you will find an application example.
It requires some few functions of the following libraries:
lists.scad http://forum.openscad.org/file/n19160/lists.scad
linear_algebra.scad
http://forum.openscad.org/file/n19160/linear_algebra.scad
Enjoy.
--
View this message in context: http://forum.openscad.org/Can-t-find-what-s-wrong-here-use-import-stl-and-difference-tp19123p19160.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On Nov 16, 2016, at 06:04, Johan Jonker johangjonker@zonnet.nl wrote:
Is there a possibility to force sweep to make triangles?
sweep currently build quads:
https://github.com/openscad/list-comprehension-demos/blob/master/sweep.scad#L43
Should be easy to build triangles instead. Not sure how to easily determine optimal triangulation. Perhaps just choose one and stick to it.
Another option could be to properly triangulate any polygons ourselves before attempting to pass it to CGAL. CGAL does triangulate, but their algorithm isn’t 100% robust. We already do this before exporting to STL, so we could probably do it for polyhedron evaluation as well.
-Marius
I used to triangulate non planar polygons before sending them to
polyhedron. However, I observed that CGAL remake the triangulation of those
polygons and so defines other surfaces. Therefore, I removed the
triangulation from my codes. If CGAL triangulation algorithm is not 100%
robust, we are in trouble.
2016-11-16 18:27 GMT-02:00 Marius Kintel marius@kintel.net:
On Nov 16, 2016, at 06:04, Johan Jonker johangjonker@zonnet.nl wrote:
Is there a possibility to force sweep to make triangles?
sweep currently build quads:
https://github.com/openscad/list-comprehension-demos/blob/
master/sweep.scad#L43
Should be easy to build triangles instead. Not sure how to easily
determine optimal triangulation. Perhaps just choose one and stick to it.
Another option could be to properly triangulate any polygons ourselves
before attempting to pass it to CGAL. CGAL does triangulate, but their
algorithm isn’t 100% robust. We already do this before exporting to STL, so
we could probably do it for polyhedron evaluation as well.
-Marius
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
@Marius, we are not talking about the sweep() you are referring to. Johan
uses one of my libaries: http://www.thingiverse.com/download:2567102 which
is more or less equivalent to your skin.scad.
@Ronaldo: The best you can get out of triangulating non-planar polynoms is
some kind of minimal surface. To do this properly in each case would not be
worth the CPU time. Unless you demand such a surface, and use a special
algorithm for it, the result completely depends on where the algorithm
starts and how it proceeds. In this post
http://forum.openscad.org/Combining-different-sweeps-does-not-work-tp18937p18970.html
I showed some code for an animation which explicitly tests this out. The
result is a bistable solution depending on the slope - and it also depends
on starting point.
--
View this message in context: http://forum.openscad.org/Can-t-find-what-s-wrong-here-use-import-stl-and-difference-tp19123p19166.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
My point is that CGAL changes the user triangulation. And it is not 100%
robust.
It is irrelevant how good is your triangulation.
Here an example:
The preview of the polyhedron I have created with all faces triangulated:
http://forum.openscad.org/file/n17150/modelling_demo_previewed.png
http://forum.openscad.org/file/n17150/modelling_demo_previewed.png
The render of the same polyhedron:
http://forum.openscad.org/file/n17150/modelling_demo_CGAL.png
http://forum.openscad.org/file/n17150/modelling_demo_CGAL.png
The hole was made by difference.
--
View this message in context: http://forum.openscad.org/Can-t-find-what-s-wrong-here-use-import-stl-and-difference-tp19123p19173.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Ronaldo wrote
My point is that CGAL changes the user triangulation. And it is not 100%
robust.
I never noticed that. What I had, was that polygon() reduced the vertex
number. But to have a similar effect with polyhedron() would astonish me. I
always got out what I put in, unless Boolean operations came into play.
Do you have testcode that shows this? So that we can track it down somehow.
--
View this message in context: http://forum.openscad.org/Can-t-find-what-s-wrong-here-use-import-stl-and-difference-tp19123p19174.html
Sent from the OpenSCAD mailing list archive at Nabble.com.