Having trouble with closed extrusions

[DougPollard]

I'm not sure if I'm not understanding something (likely!) or if I'm hitting a bug. I'm interested specifically in complex 3d extrusions. I've hit similar problems a few times already. It is frequently a manifold problem, which of course makes me think I've got crossing elements, but I can't find them, if so. Here's a relatively simple example. It has few segments without sharp bends, so it shouldn't suffer from elements that bend back on themselves. (famous last words?)

include <BOSL2/std.scad>

function f(i) =
  let(a=65*sin(720*i),b=360*i-25*sin(1440*i))
  [cos(a)*sin(b),cos(a)*cos(b),sin(a)]
;
  
steps = 120;
radius = 20;
face = [ [-1,-0.2],[-1,0.2],[1,0.2],[1,-0.2] ];
path = [ for (i=[0:steps-1]) radius*f(i/steps) ];
normals = [ for (i=[0:steps-1]) f(i/steps) ];
  
difference() {
  sphere(r=radius,$fn=360);
  path_sweep(face,path,normal=normals,method="manual",closed=true); // appears to draw caps!
  //path_sweep(face,path,normal=normals,method="manual",closed=true,caps=false); // NotManifold
  //path_sweep(face,list_wrap(path),normal=list_wrap(normals),method="manual",closed=false,caps=false); // NotManifold
  //path_sweep(face,path,normal=normals,method="manual",closed=false,caps=true); // Manifold! but not closed
}

The first (uncommented) path_sweep leaves this artifact when previewed or rendered:

To my eye I would describe it as an infinitely thin volume between two end caps from my swept path. You can't see the endcaps, if they're actually there, in a solid generation, but when you use the final shape in a difference statement, like here, it becomes visible.

Further oddness, when closed is true caps is supposed to be false. To test that, the second path_sweep (commented out) explicitly sets caps false. The preview of this code looks good, without the artifact of endcaps being visible. However, a final render produces the dreaded NotManifold error.

The third path_sweep is a test to see if I understand closed correctly. Here I explicitly include the starting point in the path via list_wrap() and specify closed as false. This seems to behave identically to the second example, which matches my expectation.

The fourth path_sweep doesn't close the path and explicitly requests endcaps. It works exactly as I would expect, including Manifold. But of course it's not the closed shape I'm looking for.

I'm using the latest BOSL2 sources from yesterday (5/11) and the developer build of openscad from 5/10. I've tried a couple of versions of openscad from the last couple of months with identical results, so I don't think it's a simple overnight bug in openscad.

[adrianVmariano]

There is a bug in the handling of caps in the module version of path_sweep. Temporary workaround: use the function form, e.g. v=path_sweep(...); vnf_polyhedron(v); Still have any issues?

[DougPollard]

Thanks for letting me know about the bug in the module usage -- that will help me narrow down my focus.

I did play with more variants than the 4 I presented, including the vnf_polyhedron() route, which I found behaved basically like my second example. That is, the preview looked good but the render produced the NotManifold error. Am I hitting the "classic" case warned about often in the BOSL docs about crossing extruded shapes? My example is such a slow, lazy curve with few steps that it seems like there is something else going on.

My fourth example, where the subtracted shape is not closed, doesn't appear to generate the NotManifold error, which makes me feel like there is still some issue at the interface where the two ends of my subtracting shape are being closed. But maybe that's just a bias due to looking at the caps error from the module usage.

[adrianVmariano]

Your second example works fine for me. I'm testing with the stable OpenSCAD release with CGAL. It takes 3 minutes to render, but it's happy. First method works if you apply the above workaround. So unless I'm missing something, it appears that you've found a bug in Manifold and should open an OpenSCAD issue with the point being works under CGAL but fails under Manifold. (This is a risk of running the dev version.) I don't see any issues with your model. No, there are no hidden self-intersections.

Third version fails because you have duplicated the position and normal but not the tangent at the endpoint. The computed tangents aren't the same when they are calculated based on the open curve. Observe the red lines showing sections from the two ends---not coincident like would be required for valid geometry.

If you want to make that approach work you'll need to compute your own tangents and pass those in, and ensure that they agree at both ends.

[DougPollard]

My second and subsequent attempts were only to test my understanding (which was clearly lacking!). It makes sense why most examples (and the built-in 2d geometry) deal with "open" paths and then rely on closed=true parameters to take care of the details at that closure point. I'm happy to stick with my first approach, but bypassing the module use of path_sweep().

I'll file an issue with openSCAD and then promptly return to using the stable version, since I'm sure all the many minutes I've saved on render times to date have now been lost chasing my tail on this problem.

Thanks for your help on this, taking the time to test it and then explain it!

[DougPollard]

@adrianVmariano a quick folllow up. Marius investigated my issue (openscad/openscad#5134) and found that the problem is the BOSL close procedure is creating duplicate vertices for the begin/end instead of, preferably, reusing the same vertices in the polyhedron construction. I have no idea if this is an easy change in BOSL or if it's intrinsic to its basic operation. Since Manifold is presumably the future for OpenSCAD it probably makes sense to at least put this on the radar if it's not already.

Oh, and another user error on my part. I had the option on to stop on the first warning in OpenSCAD. With that turned off Manifold produces one (or multiple!) warnings but eventually resolves the duplicate vertices and produces a final rendering, in my short example given and in a few more complex items I'm working on.

[adrianVmariano]

I think this is actually a catastrophic change that will break stuff all over the place.

[adrianVmariano]

Note also that it's totally reasonable and appropriate to always run with "stop on first warning" set to true. Most of the things that are warnings should be fatal errors and it's hard to find the cause of problems without this option turned on.