SplitBrep feature request

Scripting
1

I’d like to put a request on the future functionality heap. As with several other rhinoscript functions (e.g. filletsurface) the splitbrep/split functions dont work nearly as well as the rhino split command. In particular, it would be really nice to be able to maintain the texture info of the surface to be split. With the regular command, everything works intuitively when I, for instance, split a picture frame surface using a curve or another plane. i.e. the resulting surface is just the trimmed version of the image. This isn’t the case with the scripting function, it basically makes a brand new trimmed surface.

I’ve been able to work around some of these differences using rs.command() and prompting the user to take appropriate actions, but it would be a huge value-add for the scripting in V6 to be more tightly integrated with the core functionality.

On a side note, I’d like to thank you McNeelers for being so awesomely responsive to this community and its many desires!

2

From Python, call RhinoCommon’s Rhino.Geometry.BrepFace.Split function.

3

Oh cool, I hadn’t seen that. Thanks Dale.

On a side note, after looking back into automating filleting, I’ve had very little success. For instance, the following code always returns nothing from the createfillet function:

import rhinoscriptsyntax as rs
import Rhino as rh
import scriptcontext as sc

obja=rs.GetObject(“first srf”)
pointa=rs.GetPointOnSurface(obja)
uvA=rs.SurfaceClosestPoint(obja,pointa)

objb=rs.GetObject(“second srf”)
pointb=rs.GetPointOnSurface(objb)
uvB=rs.SurfaceClosestPoint(objb,pointb)

aref=rh.DocObjects.ObjRef(obja)
bref=rh.DocObjects.ObjRef(objb)

asrf=aref.Geometry().Surfaces[0]
bsrf=bref.Geometry().Surfaces[0]

new_srfs=rh.Geometry.Surface.CreateRollingBallFillet(asrf,uvA,bsrf,uvB,1,0.1)
for item in new_srfs:
sc.doc.Objects.AddSurface(item)

any suggestions?

4

Hi Bert.
I have been having the same issue with rs.FilletSurfaces function, and probably should have reported this.
Then tried using CreateRollingBallFillet method directly, and both of these two did not work (and rs.FilletSurface calls either of those two):
CreateRollingBallFillet_1
CreateRollingBallFillet

The last one though, worked, but only when playing a bit with flipping surfaces. For example this worked:

filletSrf = Rhino.Geometry.Surface.CreateRollingBallFillet(srf0, False, srf1, True, 4, 0.01)

But even this one is quite buggy as filleting a non-straight common edge will result in some small incorrect surfaces.

5

How about this:

import rhinoscriptsyntax as rs
import Rhino as rh
import scriptcontext as sc

id0 = rs.GetObject("First surface")
pt0 = rs.GetPointOnSurface(id0, "Point on first surface")
uv0 = rs.SurfaceClosestPoint(id0, pt0)

id1 = rs.GetObject("Second surface")
pt1 = rs.GetPointOnSurface(id1, "Point on second surface")
uv1 = rs.SurfaceClosestPoint(id1, pt1)

srf0 = rs.coercesurface(id0, True)
srf1 = rs.coercesurface(id1, True)
tol = rs.UnitAbsoluteTolerance()

results = rh.Geometry.Surface.CreateRollingBallFillet(srf0, uv0, srf1, uv1, 1.0, tol)
for rc in results:
    sc.doc.Objects.AddSurface(rc)
    sc.doc.Views.Redraw()
6

Same thing as before; ‘CreateFillet’ returns nothing. I’ve tried lowering the tolerance and changing the radius.

I also tried all permutations of flipping the surfaces, as per djordje’s advice and it still doesn’t work. This test was done with two PlaneSurfaces at 90 degress created via rectangles---->planarsrf

7

Hmm, works here with the geometry you describe…

8

Interestingly, at my place it works with exact case you described Bert, and exact upper settings for CreateRollingBallFillet method.
But dale’s code does not work.
I am using SR5 version.
splitSrf.py (684 Bytes)
splitSrf.3dm (64.8 KB)

9

Strange indeed. Try this file.fillet_test.3dm (72.1 KB)

10

Im using:

Version 5 SR9 64-bit
(5.9.40609.20145, 6/9/2014)
Commercial

Should i be looking for an update of the rhinopython plugin specifically?

picked points seem to have no effect

11

Works here:

12

Ok, those two files work for me djordje, but what is that False/True black magic you’re using in filletsurfaces???

p.s. after building the same surfaces in my own file and using your same script: results are inconsistent. 90 degree angle seems to work, but other angles fail

13

video link is broken

14

Ok, I see there is an overload that is not listed in built-in api.So the UV point version seems to be more broken than the boolean one

edit: it is but im stupid

15

Also, the False, True seems to be the only combination that works for me. Seems that the initial normal of the surface does not matter either

16

It’s not broken, it’s just as I am not a premium vimeo member, so you will have to wait for 30 minutes for the video to be converted.

That’s what I am saying: it’s a bit buggy, sometimes it works sometimes doesn’t.
I am not sure what’s the issue with flip surfaces. To make it even more strange, flipping surface normals directly in Rhino didn’t help. But using False/True to flip/not flip them in CreateRollingBallFillet, worked.

edit: I can see, you noticed that already. Sorry for duplicating post.

17

Indeed. So this is a two-headed monster:

Firstly: using True or False for BOTH flip params never works for me.

Secondly: Using one flip=True and one flip=False will cause one picking-order to succeed, and the other to fail. Inverting the booleans will cause the other pick-order to work

Thirdly: Which value is false and which is true and the picking-order that this implies, is irrespective of the actual normal directions of the surface.

e.g. let flip1=True and flip2=False. Pick the vertical surface and then the horiz. surface. This works. Pick the horiz. surface and then the vert. surface. This fails. Now, leaving the bools the same, manually flip the dir. on each surface. Intuitively, you would think that this means the pick order must be horiz,vert. But in fact, it is still vert,horiz.

And i believe that this logic holds true even when both normals are pointing either towards or away from the fillet.

???

18

Short of the bug being rectified, or at the very least explained in the documentation, the only logical course of action seems to be to do the RollingBall function on every permutation of bools or dirs until a non-empty result is found. otherwise the implementation is never going to be robust. Maybe this is what the ‘native’ FilletSrf command does behind the scenes?