What is wrong with my polyhedron? (No top level geometry error)

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

What is wrong with my polyhedron? (No top level geometry error)

joshyaxley
This post has NOT been accepted by the mailing list yet.
This post was updated on .
Hi,

I've looked around the internet and found many variations of the "no top level geometry" error, but couldn't work out how to fix it in my case. Here is the code for my polyhedron:

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


And the messages given when pressing F6:

Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
PolySets in cache: 11
PolySet cache size in bytes: 18240
CGAL Polyhedrons in cache: 14
CGAL cache size in bytes: 0
Total rendering time: 0 hours, 0 minutes, 0 seconds
WARNING: No top level geometry to render


Is it something to do with faces facing the wrong way or something? I thought that they were supposed to show up non-yellow if that was the case, which none of them do. There are no 'extra' faces or overlapping faces. Every edge is shared by only 2 faces. I can't think what the error is.

If you can help fix this I would really appreciate knowing how to fix it in general, because I am going to have to do a lot of these polyhedra, and I imagine similar errors will occur.

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

Re: What is wrong with my polyhedron? (No top level geometry error)

joshyaxley
This post has NOT been accepted by the mailing list yet.
Okay, it seems that I didn't have it set to the "Thrown Together" view, which is why I didn't see that some of my faces were facing the wrong way.

I identified which ones were wrong simply by playing with the numbers and seeing which faces changed, and then reversing the sequence of vertices if the face needed flipping.

Is there a quicker way to identify which faces are the wrong way? I.E. A way to identify them from only the co-ordinates and order of their vertices.
Reply | Threaded
Open this post in threaded view
|

Re: What is wrong with my polyhedron? (No top level geometry error)

hagen
by separating the points and faces definition from the polyhedron, you can use them to visualize a specific face

p = [
[4,1,7],
[2,1,5],
[2,2,4],
[4,-1,7],
[2,-1,5],
[4,0,6],
[0,0,2],
[2,1,3],
[0,1,1],
[2,-2,4],
[2,-1,3],
[0,-1,1]
];

f = [
[5,10,9,3],
[9,10,11],
[1,6,8,2],
[6,11,8],
[0,1,2],
[0,3,4,1],
[1,4,6],
[9,4,3],
[9,11,6,4],
[5,3,0],
[2,8,7],
[7,10,5],
[0,2,7,5],
[8,11,10,7]];

polyhedron(points = p ,faces = f);

testface = 7;
for (i=f[testface]) translate(p[i]) sphere(r=.5);
Reply | Threaded
Open this post in threaded view
|

Re: What is wrong with my polyhedron? (No top level geometry error)

szabi
I guess it's the triangles you try to define by four points?

Szelp, André Szabolcs

+43 (650) 79 22 400


On Sat, Jun 21, 2014 at 3:10 PM, hagen <[hidden email]> wrote:
by separating the points and faces definition from the polyhedron, you can
use them to visualize a specific face

p = [
[4,1,7],
[2,1,5],
[2,2,4],
[4,-1,7],
[2,-1,5],
[4,0,6],
[0,0,2],
[2,1,3],
[0,1,1],
[2,-2,4],
[2,-1,3],
[0,-1,1]
];

f = [
[5,10,9,3],
[9,10,11],
[1,6,8,2],
[6,11,8],
[0,1,2],
[0,3,4,1],
[1,4,6],
[9,4,3],
[9,11,6,4],
[5,3,0],
[2,8,7],
[7,10,5],
[0,2,7,5],
[8,11,10,7]];

polyhedron(points = p ,faces = f);

testface = 7;
for (i=f[testface]) translate(p[i]) sphere(r=.5);



--
View this message in context: http://forum.openscad.org/What-is-wrong-with-my-polyhedron-No-top-level-geometry-error-tp8652p8735.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: What is wrong with my polyhedron? (No top level geometry error)

MichaelAtOz
Administrator
szabi wrote
I guess it's the triangles you try to define by four points?
wiki "faces
(introduced in version 2014.03) vector of point n-tuples with n >= 3. Each number is the 0-indexed point number from the point vector. When referencing more than 3 points in a single tuple, the points must all be on the same plane."

@josh
Your posts are still flagged as "This post has NOT been accepted by the mailing list yet. " so they don't get seen by everyone. You need to complete registration
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: What is wrong with my polyhedron? (No top level geometry error)

Kenneth R Sloan
I have always thought this feature was a mistake - not only in OpenSCAD, but in the
many systems that preceded it.  One issue is that 4 points are rarely precisely coplanar
when in general position with coordinates represented in floating point.

--
Kenneth Sloan
[hidden email]
"La lutte elle-même vers les sommets suffit à remplir un coeur d'homme; il faut imaginer Sisyphe heureux."


On Jun 22, 2014, at 00:32 , MichaelAtOz <[hidden email]> wrote:

szabi wrote
I guess it's the triangles you try to define by four points?

wiki "faces
(introduced in version 2014.03) vector of point n-tuples with n >= 3. Each
number is the 0-indexed point number from the point vector. When referencing
more than 3 points in a single tuple, the points must all be on the same
plane."

@josh
Your posts are still flagged as "This post has NOT been accepted by the
mailing list yet. " so they don't get seen by everyone. You need to
complete registration
<http://forum.openscad.org/mailing_list/MailingListOptions.jtp?forum=1>  



--
View this message in context: http://forum.openscad.org/What-is-wrong-with-my-polyhedron-No-top-level-geometry-error-tp8652p8747.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: What is wrong with my polyhedron? (No top level geometry error)

Oskar
Kenneth R Sloan wrote
I have always thought this feature was a mistake - not only in OpenSCAD, but in the
many systems that preceded it.  One issue is that 4 points are rarely precisely coplanar
when in general position with coordinates represented in floating point.
Well, it still serves to signal intent, and it relieves the user of having to do the tessellation. Internally, the polygon would be triangulated, but edge flags can be kept to hide this fact from the user during presentation. I think this makes sense for when the nonplanarity is just caused by the limits of the floating point representation. Another question is what to do when the user instead incorrectly supplies significantly nonplanar points. In this case, the choice of triangulation strategy could significantly affect the resulting geometry. It might make sense to have a threshold for when it is considered an error.
Reply | Threaded
Open this post in threaded view
|

Re: What is wrong with my polyhedron? (No top level geometry error)

szabi
In reply to this post by MichaelAtOz
Oops, I missed that feature update of 2014.03!

Szelp, André Szabolcs

+43 (650) 79 22 400


On Sun, Jun 22, 2014 at 6:32 AM, MichaelAtOz <[hidden email]> wrote:
szabi wrote
> I guess it's the triangles you try to define by four points?

wiki "faces
(introduced in version 2014.03) vector of point n-tuples with n >= 3. Each
number is the 0-indexed point number from the point vector. When referencing
more than 3 points in a single tuple, the points must all be on the same
plane."

@josh
Your posts are still flagged as "This post has NOT been accepted by the
mailing list yet. " so they don't get seen by everyone. You need to
complete registration
<http://forum.openscad.org/mailing_list/MailingListOptions.jtp?forum=1>



--
View this message in context: http://forum.openscad.org/What-is-wrong-with-my-polyhedron-No-top-level-geometry-error-tp8652p8747.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: What is wrong with my polyhedron? (No top level geometry error)

szabi
In reply to this post by Oskar
Noncoplanar points with #points >3 *must* naturally result in an error.

Szelp, André Szabolcs

+43 (650) 79 22 400


On Sun, Jun 22, 2014 at 11:49 AM, Oskar <[hidden email]> wrote:
Kenneth R Sloan wrote
> I have always thought this feature was a mistake - not only in OpenSCAD,
> but in the
> many systems that preceded it.  One issue is that 4 points are rarely
> precisely coplanar
> when in general position with coordinates represented in floating point.

Well, it still serves to signal intent, and it relieves the user of having
to do the tessellation. Internally, the polygon would be triangulated, but
edge flags can be kept to hide this fact from the user during presentation.
I think this makes sense for when the nonplanarity is just caused by the
limits of the floating point representation. Another question is what to do
when the user instead incorrectly supplies significantly nonplanar points.
In this case, the choice of triangulation strategy could significantly
affect the resulting geometry. It might make sense to have a threshold for
when it is considered an error.



--
View this message in context: http://forum.openscad.org/What-is-wrong-with-my-polyhedron-No-top-level-geometry-error-tp8652p8749.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: What is wrong with my polyhedron? (No top level geometry error)

Kenneth R Sloan
In reply to this post by Oskar
Yes to all - this is familiar territory.  The same issues have been around for at least 50 years.
IMHO, no one has solved them completely satisfactorily so far.  Who knows, perhaps the OpenSCAD community will succeed where everyone else has failed.

The main point is that over constraining something (in this case, a plane) tends to make
the system brittle.

Another is that a triangulation done further along in the pipeline might change if the object
is transformed.  This can have many annoying side-effects.  There are similar problems with repeated “identical” faces.

One quibble - if we are talking about STL export, then my recollection is that you 
do NOT *have to* triangulate.  Doesn’t STL allow arbitrary “planar” faces (as long as they are also convex)?  Perhaps I’m thinking of one of the other myriad mesh formats.
Perhaps some other subsystem (CGAL?) requires triangles.  

In any event, I’m in favor of triangulation from the beginning.  And…think about the *reason* that
it might be the case that “Internally, the polygon would be triangulated”.  Then consider whether that
is simply a question of what internals are currently in use, or if there is a *reason* for that
triangulation.

For user convenience, I might be in favor of a representation short cut which allows for more-than-three-sided faces - but in that case, I would be in favor of immediate triangulation using the simplest possible method, with NO attempt to find a “good” triangulation, or catch errors.  My personal favorite is the “zig-zag” triangulation.

When the face is truly “close enough to planar” and “close enough to convex”, this will work just fine (except that the “same” face repeated somewhere else in the model may be triangulated differently).
When it’s not…too bad.

I’m in favor of keeping things simplicial.

As for “curved triangles” - good luck with that.  There are *lots* of methods to choose among.  I despair of any three subsystems in the pipeline actually agreeing on which one is “right”.  One advantage of planar triangles is that once you have specified the vertices there is no question about what’s going on (either on the edges, or in the interior). [well, there’s two-sided vs. one-sided, and if one-sided, WHICH side…] If you move up to specifying vertices and surface normals at the vertices, there are still MANY variations - all of which seem “natural” to someone.   Most of which, in practice, are triangulated for rendering.

All of the above applies to shapes which the user represents as “faceted”.  For other shapes (cylinder, sphere, and cone come to mind) I go the other way - I would prefer a system that carries through the full information on curvature all the way from user input to rendered output.  In these (limited) cases, internal triangulation should be completely hidden from the user (to avoid the abomination of “to create a hex nut, just specify a cylinder with $fn=6).  The trick here is to choose your primitives carefully, and be very precise about what is meant, what is guaranteed, and what may be left up to the system to determine when a truly smooth model can no longer be maintained.  To the extent possible, the system should allow (require!) the user to specify what he *means* and then do its level best to deliver.

OpenSCAD is now feeling the pain that many programming languages went through - when the community finally separates into “implementers” and “users”.  It has proven to be exceedingly difficult for implementers who are also users to NOT let internal features and techniques leak out to where the users can see them.  Getting it right requires eternal vigilance, and a certain bloody mindedness about consistency and “correctness”.  Hacks are wonderful - but have a limited audience and lifetime.

--
Kenneth Sloan
[hidden email]
"La lutte elle-même vers les sommets suffit à remplir un coeur d'homme; il faut imaginer Sisyphe heureux."


On Jun 22, 2014, at 05:49 , Oskar <[hidden email]> wrote:

Kenneth R Sloan wrote
I have always thought this feature was a mistake - not only in OpenSCAD,
but in the
many systems that preceded it.  One issue is that 4 points are rarely
precisely coplanar
when in general position with coordinates represented in floating point.

Well, it still serves to signal intent, and it relieves the user of having
to do the tessellation. Internally, the polygon would be triangulated, but
edge flags can be kept to hide this fact from the user during presentation.
I think this makes sense for when the nonplanarity is just caused by the
limits of the floating point representation. Another question is what to do
when the user instead incorrectly supplies significantly nonplanar points.
In this case, the choice of triangulation strategy could significantly
affect the resulting geometry. It might make sense to have a threshold for
when it is considered an error.



--
View this message in context: http://forum.openscad.org/What-is-wrong-with-my-polyhedron-No-top-level-geometry-error-tp8652p8749.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
tp3
Reply | Threaded
Open this post in threaded view
|

Re: What is wrong with my polyhedron? (No top level geometry error)

tp3
Kenneth R Sloan wrote
One quibble - if we are talking about STL export, then my recollection is that you
do NOT *have to* triangulate.  Doesn’t STL allow arbitrary “planar” faces (as long as they are also convex)?  
No, STL is a list of triangles.
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: What is wrong with my polyhedron? (No top level geometry error)

Oskar
In reply to this post by Kenneth R Sloan
Kenneth R Sloan wrote
One quibble - if we are talking about STL export, then my recollection is that you
do NOT *have to* triangulate.  Doesn’t STL allow arbitrary “planar” faces (as long as they are also convex)?  Perhaps I’m thinking of one of the other myriad mesh formats.
Perhaps some other subsystem (CGAL?) requires triangles.
In theory, the ASCII STL representation supports polygons of arbitrary number of vertices. In practice, more or less all current software only works with triangles, and in addition, the binary STL format only supports triangles.

The parts of CGAL that we use don't in general require triangles, but they do require that all vertices of a polygon are *exactly* coplanar, so even a rotated cube would in general require its sides to be triangulated. In addition, the OpenGL visualization requires triangles.

Kenneth R Sloan wrote
In any event, I’m in favor of triangulation from the beginning.  And…think about the *reason* that
it might be the case that “Internally, the polygon would be triangulated”.  Then consider whether that
is simply a question of what internals are currently in use, or if there is a *reason* for that
triangulation.
Since most export formats only support triangles, you are correct that a triangulation needs to happen at one point of the computation chain, so I'd agree. Best do it as early as possible.

Kenneth R Sloan wrote
For user convenience, I might be in favor of a representation short cut which allows for more-than-three-sided faces - but in that case, I would be in favor of immediate triangulation using the simplest possible method, with NO attempt to find a “good” triangulation, or catch errors.  My personal favorite is the “zig-zag” triangulation.

When the face is truly “close enough to planar” and “close enough to convex”, this will work just fine (except that the “same” face repeated somewhere else in the model may be triangulated differently).
When it’s not…too bad.

I’m in favor of keeping things simplicial.
Currently OpenSCAD has a number of different triangulation algorithms at different places throughout the code. The one most used is based on a 2D constrained Delaunay triangulation of the polygon projected along its estimated normal's dominant coordinate axis.

The Delaunay triangulation should in general avoid generating degenerate triangles for collinear points, and since it's already robustly implemented in CGAL and there exist a reasonable motivation for its use I'd suggest we stick to it.

Kenneth R Sloan wrote
As for “curved triangles” - good luck with that.  There are *lots* of methods to choose among.  I despair of any three subsystems in the pipeline actually agreeing on which one is “right”.  One advantage of planar triangles is that once you have specified the vertices there is no question about what’s going on (either on the edges, or in the interior). [well, there’s two-sided vs. one-sided, and if one-sided, WHICH side…] If you move up to specifying vertices and surface normals at the vertices, there are still MANY variations - all of which seem “natural” to someone.   Most of which, in practice, are triangulated for rendering.
I guess the AMF format, given that it is an ISO standard, has a very clear definition of how its curved triangles are to be interpreted. In the cases where we know the underlying continuos surface model (which doesn't apply to user supplied faceted geometry) we could adapt the output to fit.

Kenneth R Sloan wrote
All of the above applies to shapes which the user represents as “faceted”.  For other shapes (cylinder, sphere, and cone come to mind) I go the other way - I would prefer a system that carries through the full information on curvature all the way from user input to rendered output.  In these (limited) cases, internal triangulation should be completely hidden from the user (to avoid the abomination of “to create a hex nut, just specify a cylinder with $fn=6).  The trick here is to choose your primitives carefully, and be very precise about what is meant, what is guaranteed, and what may be left up to the system to determine when a truly smooth model can no longer be maintained.  To the extent possible, the system should allow (require!) the user to specify what he *means* and then do its level best to deliver.
I agree, and have been thinking along the same lines. The facets we generate to approximate cylinders, cones and spheres could carry information about the underlying continuous surface (for these primitives, e.g. coefficients for a quadratic equation). Since CSG operations never create new surfaces (at most flips orientations for the case of difference()), this information would survive to the final triangulated mesh. That mesh could then be up-sampled, converted to curved triangles or even converted into a curved surface mesh in a conservative manner – i.e. only transform the triangles and edges that we are certain don't risk creating self-intersecting geometry. This approach would mean that we simply use the mesh triangulation and CSG as an intermediary step to solve for the surface topology while we preserve the underlying generating functions to reconstruct surface geometry. In most cases, the number of mesh facets required for correct or sufficiently good topological construction is most likely quite low which means that it has the potential to be much faster than what we need to do today to get reasonable accuracy.

Do you think this is a feasible approach, and if so what kind of continuous surface representation would you suggest?

Along that line, it would be interesting to consider what other kinds of geometry we could preserve continuous curved surfaces for. For example, convex hulls and (at least convex) Minkowski involving spheres. Extruded shapes are another interesting class. For the 2D subsystem, I don't think the Clipper library that we currently use supports adding information to the polygon edges, but we may be able to hack that in. Circles (as well as affine transformations of them) and rectangles would then be handled analogously to the 3D case.
Reply | Threaded
Open this post in threaded view
|

Re: What is wrong with my polyhedron? (No top level geometry error)

doug.moen
In reply to this post by Kenneth R Sloan
I agree with Kenneth's points:
 * "To create a hex nut, just specify a cylinder with $fn=6" is an abomination.
 * The user should specify what he *means* and the system does its
best to deliver.
 * OpenSCAD is now feeling the pain that many programming languages
went through - when the community finally separates into
“implementers” and “users”.

As a beginning user with little background in CSG, I want OpenSCAD to
be easy to use. I don't want to be burdened with understanding and
specifying low-level implementation details when I am trying to do
something simple.

I know that the CSG experts in the OpenSCAD community have more
complex requirements than I have, but we should keep language designer
Alan Kay's dictum in mind: "Simple things should be simple, complex
things should be possible."

As a naive user, I would prefer sphere() and cylinder() to construct
mathematically exact objects, which are displayed as perfect spheres
and cylinders in the preview. I dislike the fact these primitives
return crappy polygonal approximations, and that when I union or
intersect the results, I get an approximation of an approximation --
the errors accumulate. I also don't like the fact that I can specify
$fn= separately for each object, because that's an extra decision that
I'm asked to make each time I use one of these primitives, as a way of
working around the first issue.

Also, I don't want to have to ever worry about "coincident faces" or
vertexes that are touching. For example, the first time I tried to use
the 2D subsystem (early this year), my first model crashed OpenSCAD
because I created a checkerboard in which the black squares were
sharing vertexes. (Marius says this is now fixed.)

I would prefer OpenSCAD to maintain a mathematically exact result all
the way to the end, and then tesselate the objects at the point where
I'm exporting to STL. It's during this final conversion to polygons
where I would be comfortable in specifying a $fn value.

Since I'm not a CSG expert, I'm mostly ignorant about how much work is
involved to create this naive user paradise.

I have noticed that ImplicitCAD uses a mathematically exact
representation, which is tesselated only on conversion to STL. The
boolean operations (like union) do not appear to fail in the presence
of coincident faces and vertexes. There appear to be some useful
geometric primitives, missing from OpenSCAD, that are easy to
implement using the implicit function representation: eg, rounded
union. But it's not a panacea: they don't support Minkowski Sum,
because it is far too expensive to calculate for the implicit function
representation.

We've talked about using the AMF 'curved triangle' representation
internally. Full support for AMF import would require this. My
impression is that you store a triangle, plus normal vectors to
specify curvature. The normal vectors can be used when previewing to
smooth out the facets and make the underlying polygon look more
curved. In the simplest implementation of union and intersection, the
underlying polygonal skeleton would still create errors in the model
where a seam was created at the intersection of two objects. A more
complex and expensive algorithm could avoid these errors by
subdividing triangles where seams are created.

We could create a hybrid geometry engine that supports multiple
representations: eg, implicit functions and polyhedra (with/without
rounded triangles). The engine could convert from one representation
to another based on which geometric primitives are being used. And it
would delay conversion from a curved to a tesselated representation as
long as possible.

I've probably misunderstood or oversimplified some things, so
corrections are welcome.

On 22 June 2014 07:25, Kenneth R Sloan <[hidden email]> wrote:

> Yes to all - this is familiar territory.  The same issues have been around
> for at least 50 years.
> IMHO, no one has solved them completely satisfactorily so far.  Who knows,
> perhaps the OpenSCAD community will succeed where everyone else has failed.
>
> The main point is that over constraining something (in this case, a plane)
> tends to make
> the system brittle.
>
> Another is that a triangulation done further along in the pipeline might
> change if the object
> is transformed.  This can have many annoying side-effects.  There are
> similar problems with repeated “identical” faces.
>
> One quibble - if we are talking about STL export, then my recollection is
> that you
> do NOT *have to* triangulate.  Doesn’t STL allow arbitrary “planar” faces
> (as long as they are also convex)?  Perhaps I’m thinking of one of the other
> myriad mesh formats.
> Perhaps some other subsystem (CGAL?) requires triangles.
>
> In any event, I’m in favor of triangulation from the beginning.  And…think
> about the *reason* that
> it might be the case that “Internally, the polygon would be triangulated”.
> Then consider whether that
> is simply a question of what internals are currently in use, or if there is
> a *reason* for that
> triangulation.
>
> For user convenience, I might be in favor of a representation short cut
> which allows for more-than-three-sided faces - but in that case, I would be
> in favor of immediate triangulation using the simplest possible method, with
> NO attempt to find a “good” triangulation, or catch errors.  My personal
> favorite is the “zig-zag” triangulation.
>
> When the face is truly “close enough to planar” and “close enough to
> convex”, this will work just fine (except that the “same” face repeated
> somewhere else in the model may be triangulated differently).
> When it’s not…too bad.
>
> I’m in favor of keeping things simplicial.
>
> As for “curved triangles” - good luck with that.  There are *lots* of
> methods to choose among.  I despair of any three subsystems in the pipeline
> actually agreeing on which one is “right”.  One advantage of planar
> triangles is that once you have specified the vertices there is no question
> about what’s going on (either on the edges, or in the interior). [well,
> there’s two-sided vs. one-sided, and if one-sided, WHICH side…] If you move
> up to specifying vertices and surface normals at the vertices, there are
> still MANY variations - all of which seem “natural” to someone.   Most of
> which, in practice, are triangulated for rendering.
>
> All of the above applies to shapes which the user represents as “faceted”.
> For other shapes (cylinder, sphere, and cone come to mind) I go the other
> way - I would prefer a system that carries through the full information on
> curvature all the way from user input to rendered output.  In these
> (limited) cases, internal triangulation should be completely hidden from the
> user (to avoid the abomination of “to create a hex nut, just specify a
> cylinder with $fn=6).  The trick here is to choose your primitives
> carefully, and be very precise about what is meant, what is guaranteed, and
> what may be left up to the system to determine when a truly smooth model can
> no longer be maintained.  To the extent possible, the system should allow
> (require!) the user to specify what he *means* and then do its level best to
> deliver.
>
> OpenSCAD is now feeling the pain that many programming languages went
> through - when the community finally separates into “implementers” and
> “users”.  It has proven to be exceedingly difficult for implementers who are
> also users to NOT let internal features and techniques leak out to where the
> users can see them.  Getting it right requires eternal vigilance, and a
> certain bloody mindedness about consistency and “correctness”.  Hacks are
> wonderful - but have a limited audience and lifetime.
>
> --
> Kenneth Sloan
> [hidden email]
> "La lutte elle-même vers les sommets suffit à remplir un coeur d'homme; il
> faut imaginer Sisyphe heureux."
>
>
> On Jun 22, 2014, at 05:49 , Oskar <[hidden email]> wrote:
>
> Kenneth R Sloan wrote
>
> I have always thought this feature was a mistake - not only in OpenSCAD,
> but in the
> many systems that preceded it.  One issue is that 4 points are rarely
> precisely coplanar
> when in general position with coordinates represented in floating point.
>
>
> Well, it still serves to signal intent, and it relieves the user of having
> to do the tessellation. Internally, the polygon would be triangulated, but
> edge flags can be kept to hide this fact from the user during presentation.
> I think this makes sense for when the nonplanarity is just caused by the
> limits of the floating point representation. Another question is what to do
> when the user instead incorrectly supplies significantly nonplanar points.
> In this case, the choice of triangulation strategy could significantly
> affect the resulting geometry. It might make sense to have a threshold for
> when it is considered an error.
>
>
>
> --
> View this message in context:
> http://forum.openscad.org/What-is-wrong-with-my-polyhedron-No-top-level-geometry-error-tp8652p8749.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: What is wrong with my polyhedron? (No top level geometry error)

Alan Cox
In reply to this post by Kenneth R Sloan
On Sun, 22 Jun 2014 11:25:42 +0000
Kenneth R Sloan <[hidden email]> wrote:

> Yes to all - this is familiar territory.  The same issues have been around for at least 50 years.
> IMHO, no one has solved them completely satisfactorily so far.  Who knows, perhaps the OpenSCAD community will succeed where everyone else has failed.

Intrinsic functions deal with this, but you then need to be able to
export the relevant functions to the slicer and have it compute this for
each layer.

Effectively you don't export a mesh, you export an equation that for any
given co-ordinate tells you if that spot is inside or outside. The CSG
builds the equation and the slicer solves it for a given z each layer.

The other more robust methods I've seen used for similar problem spaces
treat every "point" as the centre of an overlapping small object not as
points describing edges.


Alan
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: What is wrong with my polyhedron? (No top level geometry error)

donbright
In reply to this post by Kenneth R Sloan
do you have any links to an open source implementation of a zig-zag triangulation? thanks
-db