I’m seeing what seems to be an inconsistency that I can’t understand, between what I see in Rhino and what I get with Compute:
If I open the attached model in Rhino I can split the blue surface, using the others as the cutters, with a tolerance of 1mm, no problem.
When using Compute though (as shown in the code below), this fails when the tolerance is 1. I have to increase the tolerance to something large (>50, I don’t know what value exactly, but 100 mm works).
import compute_rhino3d.Brep as Brep
import compute_rhino3d as rc
def get_objects_by_layer_name(model, layer_name):
layer = model.Layers.FindName(layer_name,0)
objects = list(filter(lambda o: o.Attributes.LayerIndex == layer.Index, model.Objects))
model = rhino3dm.File3dm.Read("test.3dm")
cl_surf = get_objects_by_layer_name( model, "cl").Geometry
bottom_surf = get_objects_by_layer_name( model, "bottom").Geometry
print( "Split, 1: ", Brep.Split( cl_surf, bottom_surf, 1 ) )
print( "Split2, 1: ", Brep.Split2( cl_surf, [bottom_surf], 1 ) )
print( "Split, 100: ", Brep.Split( cl_surf, bottom_surf, 100 ) )
print( "Split2, 100: ",Brep.Split2( cl_surf, [bottom_surf], 100 ) )
# Split, 1: 
# Split2, 1: 
# Split, 100: [<rhino3dm._rhino3dm.Brep object at 0x0000016285E94F30>, <rhino3dm._rhino3dm.Brep object at 0x0000016285E94E70>]
# Split2, 100: [None, <rhino3dm._rhino3dm.Brep object at 0x00000162893711B0>, <rhino3dm._rhino3dm.Brep object at 0x0000016285E94F30>
test.3dm (192.6 KB)
compute_rhino3d.Brep.CreateSolid() perhaps has something similar going on - surfaces that happily create a solid in Rhino refuse to do so via Compute, for the same tolerance value.
My initial reaction, by looking at your model, is that this is a units and tolerance issue.
Some reading that might be helpful:
Rhino math is happy with tolerances between .01 and .000001.
Hi @dale , do you mean that tolerances larger than 0.01 can cause problems? I haven’t previously heard that. I’ve been using large (1mm, 3mm, 5mm) tolerances in rhino to get closed surfaces representing very large objects to feed into CFD for many years.
Millimetres is the correct units for my model, and the tolerance is set to 1 because I’m comparing behaviour with a Compute script which is also using a tolerance of 1 unit (and the reason the script uses 1 unit is because the accuracy is acceptable, and because it helps avoid partial intersections and failure during joining, etc).
The sequence of events that occurred:
- I have a script working with surfaces that should be able to split each other, with a tolerance of 1. The split fails.
- I add some lines to the script to save the surfaces to file just before the split is attempted.
- I write a little test script (posted above) to check that there isn’t some hidden complexity in my script to blame, and so I have code to post here. It gets the same results as the “real” script.
- I open the saved surfaces file (in rhino 5), change tolerance to 1 unit (units are mm), and attempt the split manually - it works fine.
- I undo the split, save the file and post it here.
In rhino the surfaces and Split behave just as I’d expect. It’s the Compute script where behaviour is odd. The tolerance parameter for Brep.Split is the absolute tolerance isn’t it?
Do you get the same behaviour I do with the given surfaces, in rhino and in the test script above? The script should be able to successfully split at a tolerance of 1, but can’t.
I haven’t’ had time to try your scrpt. But Rhino 7’s
Split command doesn’t work with your model.
Split failed, objects may not intersect or intersections may not split object.
Intersect command provides an incomplete result. Perhaps a clue.
The intersection issue seems to be a regression from V6. I’ve opened an issue so we can look into this.
I can’t access that ticket @dale , with or without an account, I get a 404.
I can’t find it by searching through all issues either.
It should be visible now.
Is there any estimation of when this might be fixed? From my perspective it’s really quite a devastating problem to not be able to reliably intersect.
At the moment it seems to be slated for Rhino 8.
Ok, thanks for the info Luis.
This came up today - trying to split one surface with another, someone in our team put the split in a loop and altered the tolerance each iteration:
There are ranges where the split succeeds, and ranges above and below where it fails.