Hi all - did you see
RH-68316 Gumball: Typing 0 while smooth-dragging an arrow did not move Gumball origin to axial 0
?
-Pascal
Hi all - did you see
RH-68316 Gumball: Typing 0 while smooth-dragging an arrow did not move Gumball origin to axial 0
?
-Pascal
Hi @pascal , I noticed that the bug is being considered as a bug to be fixed only for Rhino 8, but will be left by âMcNeelâ for Rhino 7. Also, when I asked:
@wim replied:
and:
Then you added:
Despite the fact that the code is already existing in Rhino 7 for the âSnappy draggingâ and only needs to be included to the âSmooth draggingâ as well. I see no unintended consequences into this. The fix of this bug will have only positives, because it will bring the necessary precision expected from Rhino as a CAD program. The current behaviour of the Gumball produces inaccuracy due to the random distances it moves the object while typing 0, as seen in my video above.
I just tried it again with the latest Rhino 7 SRC18 and the bug is still unresolved. One time typing 0 moves the center of the object to 5,35 mm from the CPlane origin. The next time it moves the object to 7,49 mm. Then, it moved to 7,41 mm, 8, 31 mm, 6,48 mm, 6,37 mm, 24,13 mm, 13,29 mm, 7,29 mm, 7,03 mm, 7,26 mm, 6,27 mm, 5,99 mm, 3,61 mm and so on. These are all camera-dependent, despite entering a precise numerical value of 0 in the Command line, and as such cause errors with the modeling. The bug is that the Gumball totally ignores the numerical value of 0 and does âits own thingâ by moving the object at random distances instead of the intended action which otherwise works properly while moving with Gumballâs âSnappy draggingâ or the âMoveâ command with locked direction before typing 0.
It bugs me that the Gumball in Rhino 7 still features this GIANT BUG that makes it move a selected object to a totally random position, ultimately destroying the accuracy of my work, despite that I write a very specific number that the program refuses to execute properly. Take this case, for example. I want to move the selected control point along the X-axis to the 0 coordinate, so I click on the corresponding arrow handle and write 0. However, Gumball âthinksâ that itâs totally acceptable to add some mess to the project, so it moves the control point to a different random position upon any time I repeat the same operation with exactly the same number (0). This is a well known BUG that directly affects the accuracy of the modeling in Rhino, which is the primary reason for the existence of the program, so I see no reason for it to be leaved unresolved by the programmers.
Hi Bobi - the pick location moves to zero with Gumball set to Smooth dragging - to do what I think you want, set gumball to âsnappyâ dragging.
-Pascal
Hi Pascal, as it was previously discussed, the Snappy dragging with the Gumball comes with a lot of disadvantages, because itâs way too aggressive and snaps all the time. Itâs tedious to constantly switch between Smooth dragging and Snappy dragging as a workaround for a bug that should not be there in the first place. Also, in order for me to move a point to 0 in X, Y or Z direction with the Snappy dragging, I would be forced to preliminary build some object there to be able to subsequently snap to it (imagine working with plenty of CPlanes - one have to build a huge amount of those âzero objectsâ to snap). All of this adds an unnecessary amount of extra mouse clicks. The true solution is to just fix the bug by using some of the existing code already used for the Snappy dragging regarding the 0 coordinate while using Gumballâs arrow handles. Itâs as simple as that.
See if this mode can satisfy youďź
You can directly input 0 in an axis
I want align mode like this
I tried it, but itâs not what Iâm looking for. The issue is in the Gumball itself, because it refuses to work properly when the âSmooth draggingâ option is being selected.
We need a solution to this huge bug!