That’s fair and don’t worry I’m not changing the ALT tap for copying. I just want to be careful when adding more finger jujitsu to the gumball.
That’s an interesting idea. I’m already not super satisfied about changing Mode to Style since this really only fixes the issue if your language is English (or the first letter when localized is also on the convenient half of the keyboard). At least for now it should be a step in the right direction and we can still change it.
That’s reasonable and what I figured needed done from the start. I opened RH-92019.
@Joshua_Kennedy , if you watch my video above, you will notice that the gesture part is literally exactly what’s already used by “SmartTrack”. In fact, I used the latter for my demonstration. The only difference is that I set the “hold-the-mouse-pointer-in-the-same-spot” time to 1000 milliseconds, because 1 second and above is a more appropriate time limit to trigger the one-shot “Snappy dragging”.
That functionality is already in use in Rhino and proven as something usable and easy to learn, just needs to be adapted for switching the Gumball from “Smooth dragging” mode to one-shot “Snappy dragging”.
Also, it will not prevent users from applying “SmartTrack” points, because the latter require far less time to set (typically 300 milliseconds). Not to mention that when you use “SmartTrack”, you want to have an active snap anyway. On top of that, “SmartTrack” is typically used with the “Move” command instead of the Gumball.
As for tapping the Alt key to make a copy, this is a proven way for years and super easy to learn, too. I vote for it to be kept at any cost.
Does the extend function work on closed curve as well when i subselect only a segment?
Please make sure gumball position is calculated in double precision because sometimes i have trouble with gumball default position with iplanes far from origin when the gumball is bit off actual iplane and create problems when unnoticed.
A big issue with Gumball (at least in Rhino 7, I don’t have a look at how it performs in Rhino 9 WIP) is that it does not support LOCAL OBJECT GRID snapping when it’s set to “Align to object”. That means that even if I have a perfectly precise box of 10 mm, the centered scale handle of Gumball is unable to snap to every millimeter when the “Grid snap” option is active AND the origin of the Gumball is NOT located exactly in a full coordinate number of the CPlane grid. I could understand that behaviour for “Align to CPlane” mode, but in my opinion “Align to object” should prioritize the object’s coordinates instead, as the name implies.
Attached here are two identical boxes for test purposes. I wrote detailed information inside the scene. The user is unable to scale the upper box with the scale handles of Gumball every 1 mm even if “Align to object” is active. Not sure if this is a bug or intended by the developers, but I believe that the “Align to object” mode should override the “Align to CPlane” mode in this case. Gumball - Align to object mode with Grid snap.3dm (165.7 KB)
I believe that most Rhino users will benefit if there is an option to snap to equal whole numbers with the scale handles of Gumball when the “Align to object” mode is active and “Grid snap” snaps to the object’s local coordinate instead of the CPlane grid.
In order to snap to the CPlane grid, the user simply needs to switch to “Align to CPlane” mode.
I don’t see any advantage of missing the option to snap to local object coordinates. It’s frustrating that “Align to object” and “Align to CPlane” both snap to the CPlane coordinates while scaling with the Gumball handles.
Another feature request / wish / idea for Gumball: Set point at current Gumball location
A while ago (Oct 2022) I proposed an addition to the Gumball that would take next to no efforts to implement, but would be incredibly useful (at least from my point of view, but I guess I am not the only one) …
Background:
I really like the way entering “0” (zero) is implemented in the Gumball for moving. For those who don’t know yet:
1.) when selecting a Gumball arrow/axis and type 0 and hit enter, the selected item(s) will move so that they go to zero on that axis
2.) when selecting a Gumball plane and type 0 and hit enter, the selected item(s) will move so that they go to zero on that plane
3.) when selecting the Gumball origin and type 0 and hit enter, the selected item(s) will move so that they go to zero on all axis
This is very useful.
However - I think the implementation should be extended with the same concept:
A) When relocating the Gumball position (only the Gumball moves, not the selected items) use the same logic as above. That was already in V8, but in V9 it seems it does not work.
B) When relocating the Gumball rotation → Rotate the Gumball so that it has zero rotation (corresponding to the Gumball) on the axis defined by the selected rotation handle
C) When using a rotate handle → Rotate the selected items so that they have zero rotation (corresponding to the Gumball) on the axis defined by the selected rotation handle
All related to the currently active Cplane.
Again - easy to implement, and very useful for every user. Please consider adding this in V9.
On a preliminary review I can’t find a request for this anywhere else, so going to pile on this thread:
It’d be very useful to be able to be able to snap the orientation of the gumball to another nearby object, other than the one selected.
When you double-click to relocate it, it’d be neat if you could, while you’re relocating it, tap ctrl or shift to get it to snap to the normal direction of an o-snapped feature underneath the cursor.
I frequently want to move a point based on the normal of one of the adjacent faces, rather than the vertex normal as computed.
I’d love to see an extend mode for the gumball when dragging the object aligned curve endpoint. Consider this example where I drag the endpoint vs extending the curve.
Would be really convenient to just shrink and extend the curve. The offsets are parametric, just to show how much it changes the curve.
The first part is possible now. If you hold Option / Alt and then click an arrow, you can release option / alt and type a number to create a copy x units away. Also works with rotation and scale gizmos.
I couldn’t get it to work in RH9 when I was trying just now, but after a restart I can….maybe by install is a little wonky.
I’m also have issues with polyline in RH8 where it sometimes wants to do a curved extension when I select polyline…
Just gonna insert my opinions into the discussion on the current Gumball snapping implementation.
Presenting a choice between Snappy Dragging and Smooth Dragging is clunky and confusing. To me it implies the Gumball has its own snapping behaviour rather than this being a simple flag to respect or ignore Osnaps. A simplified and more helpful menu item might simply be an “Ignore Osnaps” checkbox.
Personally I would advocate for removing that option entirely as snapping should be controlled with the Osnap modifier key during transform - as with every other operator. I don’t understand where there would be a need to exclude the gumball from Osnaps. It seems redundant and adds complexity.
The second thing to highlight is the behaviour of Snappy Dragging where the object will jump to the mouse location on initial drag of an axis or plane, or jump to a rotation based on where the rotation handle was first clicked. It is not helpful and can be incredibly jarring/tiring.
This can be especially bad on rotations where the initial handle click location determines both the direction and magnitude of that initial rotational jump. Personally I want to grab the handle wherever is most convenient rather than having to target some tiny area of a quarter circle to avoid my part flipping over.
The ideal behaviour (as seen in other software) would be for the Gumball to behave as it does in Smooth Dragging mode all the time (where movement is always strictly relative to the cursor position) and then, where snaps are on, it would jump the object to the target.
So I suggest both consolidating the Snappy/Smooth dragging options to a single Osnaps checkbox and removing the jump to mouse behaviour seen in Snappy Dragging would go some ways to making this a more streamlined tool that is easier and more enjoyable to use.
I’m not sure if you have followed the whole development, but we tried this at some point and many users were not happy with it.
Eventually I logged this proposal as an alternative, but Joshua is not convinced this will work out either RH-94216 Gumball: use alt to toggle between Snappy and Smooth
I agree that that is jarring. It was removed at some point but got lost in a revert, see also RH-93850 Gumball: Integrated smooth and snappy dragging modes
I’ll made a new YT for it: RH-97751 Gumball: only jump to cursor once a snap point is hit
No I am very fresh to this, understandably there are many reasons things end up they way they do. I tend to agree with Joshua in that thread that the proposal jumbles the two functions. I’m biased but I think that points in the direction of the in-between solution of one drag mode plus a simple “Ignore Osnaps” menu item that maintains the old functionality and keeps the die-hards happy.
It would be great if the irritating jump to mouse behaviour can be gotten rid of as that is the only reason I have to use smooth dragging mode.
I read through some of that convo you linked to - for the record I use a Space mouse, keyboard shortcuts and Osnaps are always off by default!
The only difference is that I set the “hold-the-mouse-pointer-in-the-same-spot” time to 1000 milliseconds, because 1 second and above is a more appropriate time limit to trigger the one-shot “Snappy dragging”.
