Inconsistent Workflow Issues


I was hoping someone might be able to comment a situation that has me perplexed a bit.

In the attached file I created a simple bowl shaped object ( It is colored dark green in the file ).

I did a series of projected 2d line drawings onto the surface of the bowl and from there created ‘relief’ surfaces from that ( from the projected lines )

In order to create one single object, as part of the process, I am trimming the surface of the bowl with the relief objects.

The perplexing part for me is that when I use a single relief object and do a polar array around the same axis that was used to create the bowl, each ‘copy’ of the polar arrayed relief object acts differently when I use it to attempt a trim or split action on the bowl surface.

In the file you can see I have been successful with some of the arrayed objects, but there are some cut-outs that are yet finished because the polar-arrayed object won’t work.

Now for the ones that don’t work I can select their edges and using the project command make a ‘new’ edge from which a trim command would work. I thought this meant somehow the polar-arrayed object became separated from the bowl surface which is why it doesn’t work, but in the end I can join polar-arrayed object with the bowl to make one object.

I know this post is a bit verbose, but my main query is more about trying to understand why geometry that is identical works in one case but not the other.

To try and show it more simply as an example; In the file there is an object colored cyan. It is the result of a polar array of the object colored red. The polar array was done ( as I indicated before ) using the same axis of rotation that was used to make the dark green bowl ( which was created by a single profile revolved 360 degrees ).

Geometricaly, the ‘layout’ of the objects are identical, yet I can do a trim with the red relief object and green bowl, but I cannot do a trim with the cyan relief object and the green bowl.

This sort of thing makes it difficult to predict what I may or may not be able to do when planning a workflow in creating an object.

Insights are much appreciated. Thank you

Edit: sorry I uploaded the wrongly save file

Here’s the file that should have been uploaded

Inconsistant new example.3dm (2.6 MB)

Hi Baba - it’s a little iffy here because your red object’s edge is hits the hole next to it - just - I’d try to avoid that I think, either have the pointy thing penetrate a little past or stop a little short of the neighboring hole. My guess of the moment is that these just touching, plus a little numerical noise, may be making the difference.

In addition the cutters barely touch the target surface, making for, very likely, not quite complete curves of intersection when you trim. You can avoid this by, if you know the cutter’s edge is right on the target surface, using the edge curve to trim with rather than relying on a tenuous Surface-Surface intersection that you’d get if you use the surface as a cutter, if you see what I mean. So, when you trim, either DupEdge and use the curve to trim with, or when selecting the cutters, type in CRV and Enter to force only curve selection (including edge curves).


Hi Pascal,

Hmmm…when you say “…plus a little numerical noise,…” I suspect that was a contributing factor.

Do you think there may be a bit of “numberical noise” as well for the 'edges" of the relief objects that meet at the target surface?

When I created those profiles projected onto the target surface, I then used a series of NetworkSrf commands to create the relief part. I am assuming after a networksrf command the resulting geometry doesn’t always give the same ‘edges’ as what the input geometry was - close, but not ‘exactly’?

Actually I did use a DupEdge of the relief object and still ran into the similar problems.

But when you mention the “numerical noise”, I think what may be happening is that I am trying to make things too “Exact”.

I am coming from a SolidWorks background and am used to doing things in an “Exact” manner. However, that doesn’t mean it will ( SolidWorks ) let you do anything you want. Many times it will complain with things like “Attempted Zero Geometry” or something like that and won’t let you complete it.

I think I’ve already come across something like this in Rhino with a revolve that was giving self-intersecting geometry, which it let me finish doing, but in SolidWorks it wouldn’t let me do the operation.

I’m not trying to suggest one way is better than the other; Letting you do an operation or not. There are advantages/disadvantages to both.

But I am sensing in this particular case of my original post here, I am getting a situation where Rhino is letting me go ahead with something that in the end might be ‘iffy’.

More of a case of experience I guess of working with Rhino in foreseeing potential problems and taking a different approach from the start to avoid if this is desired.

Hi BabaJ - it is true that Rhino will let you make ‘impossible in the real world’ stuff that a solids modeler is maybe predisposed not to allow.

If you run into trims from edges, using edge curves that fail, then we should look at those cases.

Yeah - depending on the input, it might be rather different - e.g. no kinks will exist in a NetworkSrf. But, for this type of thing (your example) Making the details as clean geometry flat in ortho space and then popping it up to the bowl with OrientOnSrf might be a much simpler workflow - maybe that is how you did it, but if so, I’d always set the base points of OrientOnSrf so that the object penetrates a few thousands into the target surface.


Thank you very much Pascal for your input.

I was thinking I’m going to have to do something along these lines when you say “… I’d always set the base points of OrientOnSrf so that the object penetrates a few thousands into the target surface…”

Something to incorporate in my workflow in principle plus the command OrientOnSrf, a new one to me, to play around with.

Again, thank you for your help. You are extremely helpfull. I don’t think I’ve seen this level of good feedback with other software.

Certainly promotes continued use of Rhino :slight_smile: