Usually I’m able to figure out some way to make it happen, but this time I’m stuck. I’m trying to subtract (Boolean Difference) the triangular band from the disk. Eventually I’d polar array the band (16) and subtract. But I can’t even get 1 to work. Both are closed poly-surfaces. Units are inches and tolerance is .001. I tried fiddling with tolerance going to .01 but that didn’t help. No idea where to go. Thoughts?
Hi @CalypsoArt
It works better if you brake up the main disc at its tangents (the command is TestSplitAtTangents). There are some small surfaces and some co-adjacent edges in the small band, and those are sometimes hard to boolean. In this case I’d do just 1/16 of the disc and polar array that - See video for reference 
HTH, Jakob
Thanks. It worked. I have a few questions if you don’t mind?
TestSplitAtTangents? What suggested this to you?TestSplitAtTangentsis not a command that shows up when typed at the command line. Does this require some additional information?Again thanks.
Pascal Golay mentions it at least once every week. By the way, DivideAlongCreases command, SplitAtTangests option=Yes does the same thing as the TestSplitAtTangents.
CreaseSplitting command controls whether commands that make surfaces from kinked curves divide resulting surfaces into polysurfaces with edges at the creases or into single surfaces with creases.
Pascal Golay wrote: Surfaces that have segments that are tangent and not curvature continuous (e.g. often created when the input is tangent arcs and straights) can cause problems for the meshing needed to display the object in shaded modes… Run the DivideAlongCreases command, with no pre-selection and set SplitAttangents =Yes, then select the object… By splitting the surfaces up at tangent locations, each new face is meshed independently. This is generally a better situation for other operations as well… Splitting should just happen, and merging should be the thing you have to do deliberately. I have not got any traction with that over the years. SplitAttangents=Yes/No in some commands is the best we have. source: Cap command is corrupting the surface
…doesn’t that mean it’s time to look at the code again… 
Most Rhino users do not split surfaces into polysurfaces because they hate the polysurfaces. I hate them too.
There is, historically, I guess one could say, a certain resistance to doing this by default - I think this is, or has been, at least somewhat based in how texture mapping works. Myself, I tend to split things at tangents…
-Pascal
me too, and there is another reason for doing it, meshing often goes completely nuts with non split surfaces that contain both planar as well as circular faces
Here we go again. TestSplitAtTangents does not help. I have no idea what is wrong with this. I revolved a CRV. Used the same CRV to make the subtraction tube. It will not subtract.
Can someone tell me what I’m doing wrong? Maybe explain how to prevent this from happening.
EX_WHY.3dm (3.0 MB)
Hello - how was the pipe made? The lower part is pretty messy -
it has edge and vertex tolerances that are very large.
Generally if a Boolean operation fails, run the Intersect command - that will often point at the problem area - in this case a big part of the expected curve was missing.
Here’s a cleaner version.
EX_WHY_PG.3dm (267.8 KB)
-Pascal
I have made all my shapes the same way.
I assume this has something to do with the original curve. I used InterpCrv to create the upper an lower curves, then joined to a couple poly lines, and an arc. A few times I tried using BlendCrv set to tangent. Everything I try fails. I have no idea how to solve this.
’
Hello- something else must have happened for that surface to be quite than messy. But I think I’d work on making simpler, cleaner curves. For example - does the pipe/sweep surface need this little .15 long angular blip that is in your revolve curve:
-Pascal
Thank you Pascal. That works. It’s has solved my problem today, but I don’t know what you did that is different to my method? If in the future I have to create something similar, I’m in the same boat.
Also, before I booleaned the objects in your file, I sub-selected the blue tube end caps individually and pushed them back 6". After that, boolean failed. Undoing the edits didn’t fix it. It would not boolean. I had to re-import your file and boolean without any attempt at editing. This is really finicky for whats seems like a simple process. Is that related to working in Rhino 7?
I would never do that - it’s a recipe for disaster. If you have a cylinder surface that has been trimmed and you move the end caps the surface will most likely get corrupted. Instead, use Split>Isocurve, split off the end where you need and re-cap.
Moving sub-surfaces is only reliable if the surfaces are planar/degree 1. As soon as you move into higher degrees, you will likely get messed up surfaces. The right-hand surface in the image in post #9 above by Pascal looks like a typical result of that.
Indeed but not always, for example cylindrical surfaces sometimes work well if the trims are not at an angle but still not in all cases. It’s more like a hit and a miss, and I think that is even more problematic.
@pascal it would be very helpful if Rhino reported a (drastic) increase in complexity as a warning message. I’m often working in a shaded display mode that doesn’t show isocurves and even then, if the surface is somewhere on the backside, it’s very easy to miss. Furthermore, how do I explain this when I’m teaching?
Yep, that’s why I prefer to avoid them altogether, you never know what’s going to happen. In my experience, it goes bad more often than not.
If things are boxy with rounded corners, it often can work and saves time, so I usually try that first, if it doesn’t work, I explode and use SolidPtOn to do the modifications( this is slightly more reliable) and if that fails too I go for the traditional surface modeling route. I often work on concepts that don’t need to be production surfaces so don’t mind if things get a bit dirty, as long as the trims stay clean and the surfaces stay sane. I think it should not be too hard for Rhino to detect a drastic change in complexity of a surface (for example the wavy example Pascal posted) and report this back to the user. I hope these solid edit tools get more attention in upcoming releases as they save a lot of time in the process of making concepts as well as making the modeling process more interactive.
Looks like where I did a blendcrv (tangency)
Hi Gijs - yes, I’ve been thinking about this exact problem lately - it comes up relatively often - we blithely say ‘oh, just sub-object select and move, you’re done’ but in fact at least half the time this is a bad idea and there is no way for the average user to know when it is OK. Sub-object editing basically needs to become much more sophisticated…
-Pascal
