Hi Direct Editing Department,
I just tried to make a chance to a cylindrical face subject. I needed to change its diameter just a few tens of a millimeter for a better fit of a part, and I just caught Rhino messing with the lower inset cylinder too. Not cool, and also unnoticeable when you are making such a small change.
BTW, I tested this in the current V8 and still gives the same bad result.
scale_subobject_bug_gf_230420.3dm (248.7 KB)
Thanks,
G
use push pull on this in v8. It will do what you are expecting
Hi Kyle,
I want to scale 2D from the center and make sure that my selected surface is scaled to a target dimension of 31.2mm diameter (from whatever it was before). So I’d scale from center, click on the quadrant and type in 31.2mm as my target scale dimension.
How does push and pull would help me here?
Thanks,
G
I’m confused, how does it not?
simply determine how much smaller you need it and then drag the cylinder that amount, or give it a drag distance in the command line.
if you need specifically dimensioned reference geometry to snap to (say exactly 31.2mm) , draw a correctly sized circle out first at whatever dimension you need then use osnap to give PP somthing to snap to.
He’s complaining about how it’s less intuitive than just scaling to the exact dimensions you want.
we’d need parametrics to do that, which we do not have.
That would be creating a reference geometry/calculation of an arbitrary existing surface. That’s not how precision workflows work, and a bad habit that’s prone to errors in math calculations ± tolerance variations. I’d never do that.
I’m trying to cut steel at precise tolerances based on input dimension where my only true reference is the center.
Meaning: doubling my work? you apply that logic to an entire model and a 15 hours work, is now a 30 h job.
This is a horrible bug, for someone trying to use a tool that should work to do efficient, fast, and accurate work. Do you disagree? Do you think it should not be fixed?
G
It’s definitely annoying (Especially since getting the same result as Push/Pull requires 7 commands in R7 as far as I can tell), but it’s not really a bug and instead seems to be a feature of how the two surfaces are interacting with each other. Hopefully the new constraints system will give us better control over features we want to remain immutable.
I agree that direct editing is not working as you are expecting, but I disagree with push pull to a referenced object is imprecise.
in your example the starting radius is 31.75
I simply draw a reference object at the correct dimension-
and snap my push pull to that.
which will have as much precision as you have in any other part of the model.
Yes, Kyle of course I can do that, and I can do it in any other number of ways, all of which, like I already explained are either: A. prone to error; or B: take a lot more steps, and more clicks (like the one you showed here).
I came here to report a pretty nasty bug. So let me ask the question again:
Do you disagree? (I’m referring to the fact that this is a bug and that it should be filed. Honestly, is quite irrelevant if you find it important or not)
Do you think it should not be fixed? …and by that meaning: you think it should not be filed as a bug, which is the entire reason I took the time to spot it, double check in in V8 so I do not report an obsolete bug, record it as a video, save a video file, save a .3dm file and come it an make a post.
Your developers always say that “if you can show us, we can fix it.” And instead, today, I’m getting lectured and advised with inferior or more laborious modeling methods.
If I didn’t think this is important, I would not be taking the time to do all this. You already know that.
I’m not trying to have, let alone win an argument with you, I just want someone at McNeel to please file this as a bug, and by seeing how nasty this is, hopefully, it motivates some developer to fix it, someday.
Have a great weekend Kyle, and let’s put this aside.
G
i dont like this attitude not to treat bugs as bugs. if it has few votes they dont fix it. bugs should be fixed no matter how many “likes”
you are using a tool for a process that is better served by a better tool. How is entering a push pull distance in the command line more work than what you originally showed?
the process is
the snapping images I sent were simply a 2nd workflow if you wanted more visual feedback.
If you don’t want to use it, so be it. Keep pounding in screws with a hammer.
I’ll happily file a bug for the process you showed, however the process you are using is obsolete, because of that the bug will likely be ignored, as this type of edit is much better served by pushpull.
Despite what you may think, I’m not trying to fight you, I’m trying to help you, whether you choose to accept it is up to you.
bug report here-
https://mcneel.myjetbrains.com/youtrack/issue/RH-74391/direct-editing-fails-on-this-part.
I agree with you, and your simple modelling task looks like perfectly reasonable action to do by the user. I don’t see the reason why one of the unaffected polysurface pieces should be deformed. Push-pull action is welcomed addition and its logic should be incorporated where it makes sense. I value the hard work of developers but modelling is also a hard work and it always should be made easier, so user can focus on the design instead of juggling between tools.
At least in this case, it doesn’t seem that desired output should be limited to using one tool but not the another.
Hi Kyle, you’re right saying the new push-pull tool does a great job in this situation and for sure is preferable but on the other hands is a bad UI behavior to constraint user choice to a single workflow.
Also if you consider the fact that this same process works just fine in previous versions.
I have to agree with Gustavo saying this behaviour should happen.
Thanks for listening to us.
If you are manipulating the outer loop of a surface, this is when the problem happens - any inner loops (i.e. holes) are also moved. If you manipulate only an inner loop, the outer is not affected.
https://www.screencast.com/t/HuggOSQm
Note the above video is in V7, so the problem is not new in V8.
Correct Mitch, the problem happens in V7 (what I use daily) and I also confirmed that it is still happening in V8 before reporting the bug.
I’m calling it a nasty bug because it’s changing my model in an area never selected, and not expected to move/change.
I see Rhino destroying models with direct editing but it’s fair game (I guess?) if it does it with touching/selected/input polysurfaces. This is not the case here.
G
Oh, I agree that it’s a real problem and that it can lead to dimensional disaster if you are making small adjustments where you might not notice that something you didn’t want moved got in fact moved.
And, I thought that this problem might only be limited to non-planar stuff like cylinders, but no, as my video shows, it’s easy to produce with simple box shapes as well. 
It’s particularly spiteful because only the top edge of the inner hole is resized. The bottom remains the same, so you now have a taper.
This the sort of inaccurate modelling the forum sages are constantly advising newbies to correct. 
This is correct.
Looking at the untrimmed surfaces in a similar model I made that has the same issue, When you scale the outermost trim line on a given surface in a polysurface the entire surface scales down with it including any inner trim lines that are on the original surface. My best guess for why this is done is so that surfaces in polysurfaces don’t have any extra trailing material left over beyond the outermost trim line, and also it avoids having to rebuild the entire surface and recalculate the trim lines relative to the new surface.
Obviously this leads to unintuitive behavior.
