Scary direct editing bug

It’s more work than you originally showed because if we wanted to scale the radius to a specific distance we would first have to measure the current radius, calculate the offset and then enter that into the push/pull command.

The process is:

  1. measure the current radius
  2. calculate the difference between the current radius and the desired radius
  3. run push pull
  4. pick a surface
  5. enter the difference in the command line


  1. run the circle command
  2. pick the center of the circle
  3. enter the desired radius
  4. run push pull
  5. pick a surface
  6. pull the surface and snap it to the drawn circle
  7. delete the reference geometry

compared to:

  1. run scale2d
  2. pick a surface
  3. select the center of the circle and the outer boundary
  4. enter the desired radius

The problem is compounded because of the solutions that work, it’s best practice to do the longer one that requires reference geometry because there’s less room for compounding error, and the scale2D solution is still best practice because you can do all your modelling while referencing a single center point.

1 Like

Well, not really. You can move, rotate or scale a single outer edge or face in the rectangular form I showed in the video without affecting the inner hole. You can also split the circular edge and move one or even two adjacent segments of it without affecting the hole, just not all of them. They are both planar surfaces anyway, so there is no rebuilding involved, just re-trimming.

1 Like

Interesting, so it only happens when you uniformly scale an outer trim line along one or more axes.
It might just be a bad optimization then. It’s just assumed that scaling the whole surface is equivalent to scaling the outer trim line in those specific cases.

You’re right that you could just retrim the surface, but imagine a case where you had a massive surface and scaled that outer trim line down an enormous amount. You might not want to maintain all that extra surface outside of the outer trim line.

Rhino does this routinely - you can make a ‘massive’ rectangular planar surface and then trim it down to a small square, it maintains the original underlying surface - unless you deliberately shrink it.

1 Like

I agree, however I’m just suggesting that one explanation of this behavior is to avoid doing this more frequently.

1 Like

FWIW this step is not necessary since you can enter the PushPull distance as a sum and let Rhino do the calculation:


1 Like

Hi Kyle,

I’d argue it isn’t obsolete and, by definition, can’t be as long as customers use it. For the moment it cannot even be deprecated as your preferred alternative PushPull is not available in the production version of Rhino.



Wishlist: A specialised subtype of PushPull for constant radius surfaces that only requires, and allows you to specify, a target radius. That could be the best tool. And it would be very easy to code, so a quick win.



I’d argue we make obsolete the idea that the new-and-cool Sketchup-like push-and-pull can even be considered as a valid replacement of a direct input 2D scale with a much shorter and reliable approach to make explicit modeling changes, if the tools that Rhino has been shipping for this actually worked.


1 Like

If the direct-editing system is obsolete, then it should be removed entirely. But that would be completely ridiculous. What should happen is that if, while direct editing, Rhino recognizes that this is a ‘push-pull’ type of operation, that it automatically switches to that mode silently without you having to do or invoke anything else. THAT would be an intelligent solution.


Now you are talking! That’s what Spaceclaim and others have been doing for over a decade now. You select the cylindrical subobject and you give it a new radius/diameter as its resulting size. I bet @Joshua_Kennedy can add that in a few days.



Provided the selected surface is a surface with 3 edges, the attached should work:
(see script further down this thread)

Thanks for sharing @Gijs, but keeping up with scripts and the awareness of when we need them for each case where Rhino tools should just work is not viable for me.

I think the development team should take these mayor/dangerous bugs more seriously and address them in the native tools.

Thanks again,



I agree with you. I think the way you are now using the scale tool is a workaround and the way it is done in SpaceClaim is the preferred method. This script is meant as a tryout only, not as a fix for this issue. It shows that this way of editing cylinders should not be difficult to implement.

Got it. I’ll test and report back. Last week I also encountered a limitation with the new push-pull that did not extend the surfaces as I was expecting. I’ll show you that too.



for now the script is too unreliable because PP looks at mouse direction, therefore I logged:
RH-74766 PushPull scripted version: ignore mouse direction


A lot of good points being brought up. Props to @gustojunk for being so patient. I would have lost it way sooner with people proposing alternative ways of doing things when this is a simple bug reporting thread.

Agree with @jeremy5, if the tool/process is obsolete then remove it altogether. If not feasible then that means it needs to get fixed.

A simple

Thank you for taking the time to report this bug. We appreciate your diligence in bringing it to our attention.

While we acknowledge the significance of the bug you’ve reported, we would like to inform you that our development team is currently working on various high-priority tasks and projects. As a result, we cannot guarantee an immediate resolution or provide a specific timeframe for when this issue will be addressed.

Or else.

We are currently working on new tools and workflows. We are in the process of implementing new tools and technologies that will replace the existing tool. As a result, our resources and priorities are currently focused on this transition.

Given the shifting nature of our workflow, it is possible that the bug you’ve reported may not be worth resolving.

1 Like

Oh noooooooo… my Rhino development fears are coming true! First, you get parametrics wrong (it’s not required) and then you plan to introduce obsolescence in a really widely used Rhino tool instead of bringing it up to date with new improvements in other parts of the software.



Not sure if the fix Joshua made to the commandline version already made it into the current WIP, but if it did, this script should allow you to make edits to simple cylindrical surfaces with flat endings. In other words, a diagonally cut cylinder doesn’t play nicely (yet) with _PushPull. (2.3 KB)

It allows you to go from this:

to this:

without doing any calculations.
Note that for the object with the filleted edge, after running the script the amount that was needed for _PushPull to set that fillet to the correct radius is still in memory, so running -_PushPull (commandline version) after setting that radius, allows you to level out the sides with that fillet as well.

1 Like

it’s weird cause ppl say GH is parametric.

It seems there’s a huge niche that’s been completely overlooked – parametrically speaking.

I agree we need parametrics. GH is something else.

looks like 3D parametric constraint driven approach.