Bug: Inability to move an object to the CPlane zero

Is not that considered a bug? It’s literally an inconsistent moving of objects at totally random distances each time that lead to inaccuracy. Entering 0 as a distance moves an object by 3,96 mm, then entering 0 again moves it by 1,04 mm, then entering 0 again moves it by 12,07 mm. Looks extremely buggy to me. :slight_smile:

It’s not an issue that is crashing Rhino.
-wim

But it surely crashes the workflow and accuracy of the Rhino users. :slight_smile: Not trying to argue, just saying facts. :slight_smile: I often see many other bugs being fixed every couple of weeks with the new service releases of Rhino 7, even though they do not crash it.

No… it was working as designed as far as I can see . As I mentioned, the movement is dependent on the pointer location on the gumball handles. The change is an enhancement, to be sure, but back porting is avoided at this stage of V7 development, as there may be unintended consequences.

-Pascal

What are those unintended consequences? :slight_smile: I see that Rhino 8 WIP already have it fixed quickly, since that was already in the code of Rhino 7’s Snappy dragging. It’s a matter of minutes or hours to transfer it to the Smooth dragging, as your programmers already did with Rhino 8’s Gumball a day ago. I was surprised that the fix for Rhino 8 was so quick. Good job! It’s pity that you don’t want to fix Rhino 7’s Gumball the same way…

I will repeat myself, that there is nothing accurate or predictable in moving objects at totally random distances every time a 0 is being set as a coordinate. This is clearly a huge bug directly causing unwanted inaccuracy and could lead to issues with important projects. I write that as someone who actually works on these and see the issues first hand.

Over the years I have been very impressed with the bug fixes and the willingness of the developers to make Rhino better. However, this particular bug is really annoying, because it literally leads to errors and wrong distances that are not relative to the exact numerical input. For the first time ever I see the developers refuse to fix a bug of such a giant caliber. It was officially reported as a bug and is already fixed for Rhino 8 WIP, yet it’s still present in Rhino 7 and continues to destroy the modeling precision.

Wait, if I select an object and click on a gumball axis arrow then type a number it moves that distance.

For what it’s worth if you select an object, click and drag the gumball from the center point and type 0 it moves the object to 0,0,0.

If I drag an object via the arrow habdle of Gumball and type 0, Rhino 7 will move the former by some random inaccurate distance that does not make any sense and will lead to errors. That random distance is different each time and compromises the accuracy Rhino is known for. The bug is already fixed in Rhino 8 WIP but unfortunately at this very moment is still present in Rhino 7.

What happens if you type a number other than 0?

If “Smooth dragging” is active, typing any number other than 0 will move the object at the exact numerical distance. The bug with inaccurate moving of the object at random location only happens if you type 0. However, if “Snappy dragging” is active, typing 0 will move the object at the CPlane 0, which is the correct way. That also applies while moving with the “Move” tool and the direction is locked via tapping the Tab key before typing 0. Only the “Smooth dragging” mode produces that inconsistency.

What Bobi is pointing is correct.

I don’t use the Gumball that way so I have no opinion about the frustration involved with this scenario.

But after reading the up comments, I find not very logical to end up with two different behaviors when using the same tool to do the same operation but in another fashion ( smooth or snappy dragging here ).

Regards
R.Santos

1 Like

Exactly! The bug literally causes crucial errors related to the positioning of objects, which is the worst bug a NURBS modeling and engineering program could have.

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. :slight_smile:

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). :slight_smile: 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. :slight_smile:

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.