rhinoWIP issue - curve says it is at -10 but is slightly out

Hi there…

Was using the attached curve in grasshopper and making some boolean extrusions that failed. The long section’s position on the Z axis is meant to be -10, but if you manage to zoom right in it sits off the grid line.

3dm in dropbox:

I have tried to “Move” the line with grid snaps on but it just won’t play ball, is this a bug with the WIP, or am I being stupid.

Thanks in advance guys…


hey Nick,

the long line section is at -10 Z

it’s possible your booleans are failing because of something else… can you explain more about what you’re wanting to accomplish.

When I zoom in Rhino WIP it’s off the line, here is an example of the baked o/p from grasshopper. I am trying to boolean the lot, but the end caps won’t play ball.

If I move the horizontal struts +ve in the z axis, the boolean works.

The shapes are all trimmed using the same curves in grasshopper, the end caps are just closed arcs instead of joined with the inner profile.

it seems to be a trimming discrepancy, I’ve tested with GH and trimming in rhino and it adds 0.000000000000005 [Rhino for mac WIP] or 0.000000000000007 [GH] to the end points of the arc, when they should be at 10.

See above, this is using a rectangle to trim whose edge is also at -10.

yeah, this will happen with certain operations… these are such insanely small measurements but they can affect other operations further down the line.

i don’t really know what to advise in this particular case but i don’t think this is specific to the mac WIP and is instead coming from the core Rhino code… i.e.- this would probably show up in all rhino versions

If you are trying to move that line 0.000000000000005 units, then, no, that won’t play ball. For all practical purposes that is not moving it at all.

That said, this offset from nominal shouldn’t be causing problems with booleans unless your tolerances are set to some insane value (which they aren’t in the file you posted - 0,01 cm). So if you are having problems with a boolean down the line it would be better to post that geometry.

Here is the geometry it creates. I’ve fixed it by transforming in GH by 0.00001, but it’d good if it just fit :slight_smile:

non boolean for foumr.3dm (2.9 MB)

That was to be expected with that geometry.

This picture show the original geometry to the left and the modified to the right. The modification is done by using the DivideAlongCreases command with SplitAtTangents=Yes. When this is done, the boolean commands will work as expected.

In Grasshopper it seems that you would have to explode the input curves for those and extrude these and then join them into a solid to create correct geometry (unless @DavidRutten has a better idea).
Quick test:

@pascal, do you know if this is something that is flagged in YT or is this pretty much by design? I see that the WIP doesn’t boolean that geometry either.

thanks for a good answer… it does boolean with all of the fins along the middle, just not the first and last shapes [slightly different]

So although I accept this as an answer, it doesn’t seem correct…


Hi Wim - as far as I know coincident planes are OK to Boolean but not if they are a planar part of an otherwise curved surface - splitting at tangents makes for a plane and a plane being coincident, and that works. I’m not sure if that is your question…


That’s not the question, no. I understand that it fails and where it fails. I’m just too lazy to go search YT myself to see if there is an issue registered there. :sunglasses: Or is there a common understanding that this is just the way it is? (I don’t run into cases like this myself…).

Yes, there are several YT entries. The issue is that, currently in Rhino, if two surfaces have a region of overlap then the boundary of that region must consist of trimming edges from the surfaces.

1 Like

thanks guys, without wanting to sound like a dumbass, it is going a little over my head.

What is YT?


Hi Nick - YT is YouTrack, our bug tracker.


1 Like