Offset sharp not working but offset round does


I see that offset sharp is not working on a certain omodel I have but round does, I read that there was a fix for this coming. Should I wait for the next SR or do you guys want the file?

(Pascal Golay) #2

Hi RM- Offsetting sharp is a lot harder than round in some cases- can you post or send me the object? I can check here if there is anything better in a newer build.



Hi Pascal,
That’s what I thought but wasn’t sure ,I’ll send the file, thanks for the quick reply.


Hi Pascal,
I’ve attached the file that doesn’t offset sharp. As well for @BrianJ this is the same model that I have problems with move edge or face and it’s the one that I have troubles in GH with the orient component on the tapered sides.
I made this object with GH maybe that’s why I’m getting the problems.

(Brian James) #5

Hi RM,

The OffsetSrf command is one way to get a wall thickness here but you could also use Shell. I assume you want to offset outward and think you may get the result you’re after by…
Scale (I used the scale handles on the Gumball to scale from the bounding box center)>Cap (to close the planar opening on top) >Shell (I picked the top cap surface as the one to remove).

The move face issue is one I’m not seeing here. I am able to move the tapered side with the MoveFace command and MoveEdge also works. Can you describe how you are using these? I may have missed one of your steps. Sub-object selection and translation with the Gumball also works as an alternate approach to moving faces or edges with these commands.

To help with the GH orientation issue, I’ll need to see the corresponding GH file. I think the alignment may be connected to how the GH components are connected.


Your right @BrianJ that model is okay I’m attaching a similar one but with a small difference, notice the face that fails not sure if it’s my model or Rhino.

Thanks for the shell tips.

(Brian James) #7

Use ShrinkTrimmedSrf on the model first and the movement of this surface will not create the ripple. Keep in mind though that moving this face forward will also maintaining the tapered side walls with the cutout and this will result in non planar sides. If the cutout were not there, the translation of this face would recalculate the side walls based solely on the four border edges and the result would still be planar. The MoveFace command as well as the sub-object method will keep seams joined in a polysrf but continuity between srfs is not guaranteed. There are a bunch of wish list items in this regard though and it is something that will likely be explored in Rhino 6 development.


Thanks for taking a look, the reason this strikes me is that the only difference in this model from the other example is the cutout, when the cutout is more advanced like in this model, moving the example face fails but if the cutout is simple like in the first example I sent in move face works. Really there isn’t a difference but to rhino the way the surf is trimmed does make a difference since I guess in this example the trim is more complex and therefore move face fails?

These kinds of things will be good to explore in future for v6
Thanks for your help on this.

(Pascal Golay) #9

Hi RM- ideally, would you expect the end face to move out and the side (tapered) faces to follow it, thus changing their planes, or would you expect the tapered side planes to remain the same and the end face to shrink as you move it away (or grow as you move it back)? It seems like both are reasonable solutions when moving that face.




Yea I would expect the end face to shrink and grow but as you say it could go both ways. In the future maybe these options can be incorporated and user chosen at the command line when we move a face etc.