Can't cap perfectly trimmed polysurface

Rhino 7 SR15

even though the ends were trimmed by vertical iplane so it should be perfectly planar. …
CANT CAP.3dm (140.5 KB)

Hi Ivan -
Do you have that object and trim location reference in the pre-trimmed state?
-wim

its a result of sweep 1 i am sending neccessary shapes
CANT CAP 2.3dm (33.1 KB)

Hi Ivan- thanks - for now, PlanarSrf & Join will get it done, I’ll add this to the pile- I see that if I copy the profile curve to the other end and sweep both, it does cap at the far end. (this is even before trimming) It may be that Cap uses a tighter tolerance than PlanarSrf.

(Trimming the sweep with planes at the locations of your trims does allow capping, here.)

RH-69171 Sweep1: Sweep of planar curve does not cap

-Pascal

1 Like

that sweep profile was imported from dwg maybe there is something wrong about the curve itself. i would inspect that aspect of the problem first.

i think so too:

using CANT CAP.3dm file - first post
_cap fails here as well
but
_explode (the polysurface)
_join (again)
_cap (works as expected)

my guess:
the initail polyline is only closed within tolerance:
see first and last Point - that should be identical for a closed polyline:

ON_PolylineCurve: domain = [0,11]
point[ 0] = (67.098209415191931, 2.8346343993509442, 14.15905665854595), 0

point[11] = (67.098209415212793, 2.8346343994673595, 14.159056658314057), 11

after fixing this everything works fine:
REPAIR CURVE
duplicating the curve
sub–select and delete the small segment neart the end
_line
_join

REDO
_sweep1
_trim with surfaces
_cap

segment i removed / redraw

successful trim cap

attached file - layernames give additional info

CANT_CAP_2_repair_tp.3dm (178.6 KB)

kind regard -tom

I agree, but you are far too polite:
THIS IS A BUG or at least it is the a consequence of a bug.

If Rhino is going to call something a closed curve then it should make sure the start point and end point of that curve have exactly the same X,Y.Z values. This is not rocket science. Its dead simple to do this. ( I can’t wait for the McNeelies to try to justify this stupidity)

Now as Tom pointed out if you explode and join then it ends up truly closed., but so what? It doesn’t matter how this curve was made if Rhino calls it closed then it should have the start and end points at exactly the same point and if it does not, then that is McNeel’s fault. Its not the fault of somebody else McNeel can blame it on to avoid doing the simple few minutes work required to fix it.

The consequences of failing to make positively sure the start and end point of a closed curve are not exactly the same are numerous. This is just one example.

I run into this on occasion when exporting to other software. Most other software like Rhino is somewhat tolerant of tiny differences when it comes to comparing two values, but inevitably if you are sloppy in making things that are supposed to be the same not exactly the same then its going to come back and bite you in the ass.

1 Like

RH-69171 is fixed in the latest WIP