I am building a Bezier curve and surface library in OpenSCAD. As a demo, I am modelling the classic Newell's tea set. The following image is the rendering of the tea cup with an extra spout for clarity: <http://forum.openscad.org/file/n16646/Teacup_fail.png> The cup spout is made of Bezier patches to model its cilindrical form whose extremities are closed by two (in fact 4) planar faces. As you can see, CGAL did not closed the spout top end. However, if I render just the spout (just one), the closing faces are rendered. In any case, they are previewed. <http://forum.openscad.org/file/n16646/Teacup_fail2.png> I already checked that the closing faces are planar. In fact, all vertices are in a vertical plane, x=cte. The face triangulations you see in the preview were done by the code, not by the previewer, as an attempt to overcome the issue. The images were generated with very low surface samples to help debugging. But I didn't found any reason for the missing faces. Sometimes, CGAL displays a warning that the model may not be a manifold. Any suggestion? -- View this message in context: http://forum.openscad.org/Strange-render-behaviour-tp16646.html Sent from the OpenSCAD mailing list archive at Nabble.com.

It sounds like you are creating a polyhedron() with a non-manifold mesh. One suggestion is to export the suspect polyhedron to STL, then load it into a mesh repair program that can diagnose where the problem is. That might help debug any problem you might have with the arguments you are passing to polyhedron(). On 21 March 2016 at 21:40, Ronaldo <rcmpersiano@gmail.com> wrote: > I am building a Bezier curve and surface library in OpenSCAD. As a demo, I > am > modelling the classic Newell's tea set. The following image is the > rendering > of the tea cup with an extra spout for clarity: > > <http://forum.openscad.org/file/n16646/Teacup_fail.png> > > The cup spout is made of Bezier patches to model its cilindrical form whose > extremities are closed by two (in fact 4) planar faces. As you can see, > CGAL > did not closed the spout top end. However, if I render just the spout (just > one), the closing faces are rendered. In any case, they are previewed. > > <http://forum.openscad.org/file/n16646/Teacup_fail2.png> > > I already checked that the closing faces are planar. In fact, all vertices > are in a vertical plane, x=cte. The face triangulations you see in the > preview were done by the code, not by the previewer, as an attempt to > overcome the issue. The images were generated with very low surface samples > to help debugging. But I didn't found any reason for the missing faces. > Sometimes, CGAL displays a warning that the model may not be a manifold. > > Any suggestion? > > > > -- > View this message in context: > http://forum.openscad.org/Strange-render-behaviour-tp16646.html > Sent from the OpenSCAD mailing list archive at Nabble.com. > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > >

Thank you, dough, for your clue. I am still learning how to debug OpenSCAD codes. However, the STL in Meshlab and TriMM just confirmed that the faces where missing. After lot of tests (I almost complete a manifold test code in OpenSCAD for polyhedron data) I found that the faces where not considered planar by CGAL. I had no warning of that. A suitable triangulation solved the issue. I am using an unconventional strategy in building the polyhedra that simplifies the modelling scheme. Eventually the vertices of adjacent faces are doubled in the polyhedron definition. That is, I define each patch vertices (to send to the polyhedron) independently for each patch. And the faces of that patch refer (index) those vertices. So, the same vertex appear many times in the list 'points' of the polyhedron. That gives me freedom to define each patch data without referring to the vertices already defined by other patches. The only care is needed is to use the same coordinates in the repetitions to have a proper join. Look this simple example: // a simple tetrahedron vert = [ [0,0,0], [100,0,0], [0,100,0], [0,0,100], [100,0,0], [0,100,0], [0,0,100] ]; tris = [ [0,1,2], [0,2,3], [3,1,0], [5,4,6] ]; difference(){ polyhedron( points = vert, faces = tris ); cube(40); } The last face is the only one to refer to the last 3 vertices which double previous occurrences. CGAL deals with that and seems to consolidate all vertices. That polyhedron is accepted as a manifold by CGAL. 2016-03-22 0:01 GMT-03:00 doug moen <doug@moens.org>: > It sounds like you are creating a polyhedron() with a non-manifold mesh. > One suggestion is to export the suspect polyhedron to STL, then load it > into a mesh repair program that can diagnose where the problem is. That > might help debug any problem you might have with the arguments you are > passing to polyhedron(). > > On 21 March 2016 at 21:40, Ronaldo <rcmpersiano@gmail.com> wrote: > >> I am building a Bezier curve and surface library in OpenSCAD. As a demo, >> I am >> modelling the classic Newell's tea set. The following image is the >> rendering >> of the tea cup with an extra spout for clarity: >> >> <http://forum.openscad.org/file/n16646/Teacup_fail.png> >> >> The cup spout is made of Bezier patches to model its cilindrical form >> whose >> extremities are closed by two (in fact 4) planar faces. As you can see, >> CGAL >> did not closed the spout top end. However, if I render just the spout >> (just >> one), the closing faces are rendered. In any case, they are previewed. >> >> <http://forum.openscad.org/file/n16646/Teacup_fail2.png> >> >> I already checked that the closing faces are planar. In fact, all vertices >> are in a vertical plane, x=cte. The face triangulations you see in the >> preview were done by the code, not by the previewer, as an attempt to >> overcome the issue. The images were generated with very low surface >> samples >> to help debugging. But I didn't found any reason for the missing faces. >> Sometimes, CGAL displays a warning that the model may not be a manifold. >> >> Any suggestion? >> >> >> >> -- >> View this message in context: >> http://forum.openscad.org/Strange-render-behaviour-tp16646.html >> Sent from the OpenSCAD mailing list archive at Nabble.com. >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

Ronaldo wrote > That gives me freedom to define each patch data without referring to the > vertices already defined by other patches. The only care is needed is to > use the same coordinates in the repetitions to have a proper join. Interesting approach. I am curious: when you say "the only care needed is to use the same coordinates...", you DID "refer to the vertices already defined", right ? What that seems to me is to avoid "index referring to the existing data" by introducing a "new data referring to the existing data" approach, and you still need to use indexing at the same time, now you have two tasks instead of one. So the advantage doesn't seem to be there. Besides, if complexity increases, matching the data points could be a huge headache. ----- $ Runsun Pan, PhD $ libs: doctest , faces ( git ), offline doc ( git ), runscad.py( 1 , 2 , git ), synwrite( 1 , 2 ); $ tips: hash( 1 , 2 ), sweep( 1 , 2 ), var( 1 , 2 ), lerp , animGif , prodVid , precision( 1 , 2 ), xl-control , type , rounded polygon -- View this message in context: http://forum.openscad.org/Strange-render-behaviour-tp16646p16686.html Sent from the OpenSCAD mailing list archive at Nabble.com.

Ok, let me try to make myself clearer. I have a lot of functions that generate Bezier patches in the form of matrices of points (meshes). And I have a standard module that receives a list of patch meshes and a list of planar faces and combine everything in one polyhedron call. This module deals with each patch or face independently, that is, it creates a list of vertices for each and a list of faces referring to those vertices. Than the module concat all vertices of all patches and planar faces, concat all face lists of those elements and send them to the polyhedron primitive. To model a part, I create the control points of the patches assuring that the adjacent patches have the same control points at their meeting border and that both are discretized the same way. I don't have to identify the vertices of each side (although they will have the same coordinates). The faces are created similarly eventually extracting (by a function) from the adjacent patches the list of vertices adjacent to it. If all faces and patches form the boundary of a solid (manyfold) the polyhedron created by the module with them will pass the manyfold test of CGAL. The Newell teaset dataset was created in the 80's as a test set for realistic graphic display. It is made of a list of degree 3 Bezier patches. However it is not a solid: there missing parts (like the bottom and interior of the teapot) and some minor control points misplacement. I completed the model in order to have manyfold parts using the approach I outlined above. And everything works now. Here is a render of part of the set: Cup-saucer-spoon.PNG <http://forum.openscad.org/file/n16688/Cup-saucer-spoon.PNG> Just for reference, the cup (without the spout) is made of 16 Bezier paches and 2 planar faces and it is a single polyhedron. The spout is another polyhedron added by union(). -- View this message in context: http://forum.openscad.org/Strange-render-behaviour-tp16646p16688.html Sent from the OpenSCAD mailing list archive at Nabble.com.

I c. From the standpoint of modularization, it does look like a good approach to stick things together. ----- $ Runsun Pan, PhD $ libs: doctest , faces ( git ), offline doc ( git ), runscad.py( 1 , 2 , git ), synwrite( 1 , 2 ); $ tips: hash( 1 , 2 ), sweep( 1 , 2 ), var( 1 , 2 ), lerp , animGif , prodVid , precision( 1 , 2 ), xl-control , type , rounded polygon -- View this message in context: http://forum.openscad.org/Strange-render-behaviour-tp16646p16689.html Sent from the OpenSCAD mailing list archive at Nabble.com.