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 nonyellow 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! 
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 coordinates and order of their vertices. 
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); 
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 _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
Administrator

wiki "faces (introduced in version 2014.03) vector of point ntuples with n >= 3. Each number is the 0indexed 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. 
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.
"La lutte ellemê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 _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
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. 
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 _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
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 _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
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 sideeffects. 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 morethanthreesided 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 “zigzag” 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 twosided vs. onesided, and if onesided, 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 ellemê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 _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
No, STL is a list of triangles.
 Torsten

In reply to this post by Kenneth R Sloan
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. 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. 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. 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. 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 upsampled, 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 selfintersecting 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. 
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 lowlevel 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 sideeffects. 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 morethanthreesided 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 “zigzag” 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 twosided vs. onesided, and if onesided, 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 ellemê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/WhatiswrongwithmypolyhedronNotoplevelgeometryerrortp8652p8749.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 
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 coordinate 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 
In reply to this post by Kenneth R Sloan
do you have any links to an open source implementation of a zigzag triangulation? thanks
db 
Free forum by Nabble  Edit this page 