I ran into a split problem with the attached file: the purple surface cannot be split with the white rectangle.
This seems to be working in Rhino 7.
The surface was trimmed using a pipe (in orange) and this is what is causing the issue. I’m aware the geometries are not very clean because they come from an automatic process in Grasshopper.
I found a workaround by changing the splitting object, however I thought I’d post this because it’s working in Rhino 7.
The issue might be related to how Rhino 8 handles trims differently from Rhino 7. Since the geometries are from Grasshopper and not super clean, small tolerances or inconsistencies could be causing the split to fail.
Hi Marco, I rebuilt the surface using Untrim and then split it with Split. It seems to work only this way. Earlier, I tried using the intersection between the two surfaces, but instead of getting the intersection line as a result, I only got a point. I’m not sure what caused this.
In Rhino 8, the split command works successfully after the makeuniform command.
I’ve experienced many instances where the trim command doesn’t work or doesn’t work correctly. I’m curious about why this issue occurs.
The reason is that the surface doesn’t have the correct form or structure, but it seems strange because the trim command should work on a defined surface (such as a polysurface or surface).
Thanks for the reply, Paul. Yes, this is my understanding as well. In fact, if I move the splitting surface by a tiny amount (0.001 mm, which is the document tolerance) then the split works. The problem is that this is part of an automated process in Grasshopper, so these workarounds are not ideal.
Thank you for testing this. Yes, it seemes there is some geometric problem in that area, and like you I’m not sure what is causing that.
Thank you! Even if I don’t know the exact technical reason, this is a great solution, and can also be automated!
You can run the Reparameterize command (use automatic option) on your purple surface and that will allow the surface to split.
The 3d space size of your surface is much bigger than the 2d space size. For more reliable results in calculating intersections the 2d parameter space and 3d space should be about the same size.
Thank you a lot for the answer, @jim, this is an even better solution because it does maintain the geometry untouched.
I understand that if the 2D space size is much smaller than the 3d space size, different points that are very close to each other might end up sharing the same parameters. However, I assumed these parameters would be managed automatically to avoid such issues, so users wouldn’t need to worry about them during these operations.
I’m just wondering: wouldn’t it make sense for the splitting/trimming commands to handle reparameterization automatically before performing the actual split or trim?
Then, if necessary, the resulting geometry could be reparameterized afterward to reflect the original parameterization.
I suspect the issue for computing an intersection like your example is that it is an iterative process that gets refined until it arrives at a curve that is accurate to within tolerance.
A long intersection curve like the one that was used to make your first trim worked well and produces an accurate intersection and Trim. I’m guessing that the short intersection fails probably because if its too short and the initial intersection is inadequate to get the iterative process started due to the mis-match in parameter space and 3d space.
There are a lot of things that could be done behind the user’s back (without the user’s knowledge) to assist in making things work better. In general Rhino developers assume if the user made something then that is the way the user wants it to be. In general I agree with that, but in this particular case I think it would be possible to detect the parameter space mismatch and make it right temporarily just for the sake of computing an intersection curve.
In this case, Rhino 8’s _Trim changes the domain (and leaves it changed after the command is complete), while _Split does not. Not only does this happen between _Trim(ming) the purple surface with the white surface, it also occurs if the purple surface is _Untrim then _Trim with the orange pipe.
Maybe at least part of what is tripping up the _Split with the white plane is a knot span of only 3.28e-06 in a BrepTrim’s curve of the purple surface. (The distance between the R3 points on the face is also that amount.)
The small span of the BrepTrim can be viewed using
Create the BrepTrim’s curve without such a small knot span. (There is mismatch of knots between the purple and relevant orange faces, but only the BrepTrim’s curve, not the BrepEdge’s curve, has the small span.)
Regardless of #1, _Split, similar to _Trim, would modify the domain of the purple face to accomplish the split.
That’s exactly my point. In general I prefer those approaches that leave the user “in control” without hiding things, in this case it seems there are no drawbacks in performing the parameter adjustment behind the scenes.
Thank you for the analysis Steven. The actual operation was a split of the untrimmed purple surface with the orange pipe and then the split with the white plane - and it was done in Grasshopper using the Brep Split component.
In the end I built a cleaner splitting surface and that fixed the problem, but I decided to post it because it seemed like an apparently “easy” split to do - and because Rhino 7 was able to do it - now it’s clear that it was not so easy
Anyway, I’m saving your information in case I run into similar issues.
That is interesting. The change in domain is not exactly the same as Reparameterize but not much different.
Leaving the domain changed permanently is a bad idea.
I mean scaling the domain to make the Rhino developer’s algorithm work better is OK but to leave the user’s geometry permanently modified to suit the developer’s needs is offensive , IMO.
One of the ways that the 2d parameter space gets out of whack with the 3d geometry space is that users sometimes scale the geometry by a factor of say 100 then does a trim and then scales it back. If Rhino permanently makes the geometry poorly defined as a consequence of doing that, how is that helpful to anyone?
If the algorithm for computing an intersection needs a better 2d domain as an intermediary step that is what the intersection code should do but there is no good reason to make it permanent.
That is another whole can of worms. Tiny knot spans in both curves and surfaces cause many problems.
