related to this issue: #439

This consecutive "revolve" workaround for Extrude along an arbitrary path seems a very important feature.

The path in #439 also has the same issue.

path.zip

This looks like a problem with coincident surfaces - the end face of one revolve and the "bottom" face of the next one. Unfortunately this is common. As we learn more about the NURBs kernel some of these issues might get fixed.

If you don't need STEP export this does work if you check "force NURBS to triangle mesh" on the 3rd revolve group and continue construction.

Path extrusion would offer a more reliable way to make this, but it's still a long way off. This is exactly the kind of thing I could see being created as one piece (hence no NURBS problems), but you'd still need a difference or intersection to cut the bottom flat.

The first end and second begin faces are carbon copy, but the NURBS kernel treats them different. Is it because of approximation?

This brings up another important feature: stitch: filling the gap between NURBS faces when the faces are not a plane.

After using Solvespace intensively for two weeks, really love it. But in the meantime, found out these two major limitations to handle serious jobs:

• path extrusion: revolve can be a workaround in some cases;
• stitch: no workaround for now.

Ran into this: https://github.com/wsteffe/solvespace_occ

First tests with opencascade bezier curves:

wsteffe/solvespace_occ@f186b74

The problem here is now understood. There is an extra edge being created at the intersection of two planes - the vertical one at the end of the previous revolve and the top surface of the new one. This "curve" is going beyond the area of the surface polygon, as can be seen in the original picture. A couple of hacks confirm this.

Commenting out the call to MakeFirstOrderRevolvedSurfaces() after Revolve operations "fixes" the problem at the expense of leaving those surface with order 1x2 which prevents merging planes and constraining to them - so not a fix. Also, going in SSurface::IntersectAgainst() and aborting surface-surface intersection:

    if(degm == 1 && degn == 1 && b->degm == 1 && b->degn == 1) {
        return;

Makes the problem go away, but again that's not a solution.

That intersection edge is not being split in two and if it was I'm not sure if the outside portion would be discarded.

Unrelated: That "path.slvs" sketch mentioned above as a crude substitute for extrusion along a path works really well with current SolveSpace master branch. No more red or missing surfaces.

It works fine now, thanks.