Hi Jeremy- as far as I can see the system as it is now works the same in all views. The pointer location is used as the from point to move to zero in that axis - the difference may be that that point’s location in 3d is more precise in an ortho view.
Jeremy is correct. I made a mistake which I’ll correct.
Type w0 for the world origin.
If you click on an object and start dragging it, then type 0 and enter will continuing to hold down the mouse button, the object will move so that the location on the object where you clicked is at the Cplane origin.
If you click on an object and start dragging it, then type a number other than zero and enter will continuing to hold down the mouse button, the object will be constrained so that the location on the object where you clicked is at typed distance from its original position.
Hi Bobi - I think we’ve got the move to zero problem, and how you would prefer it, pinned down. (The distance it moves is not random, it may not be very useful, but it us not random as far as I can see: it uses the ponter location as the From point and I can see that there may be arguments for not changing this, but as I said, I’ll ask) RH-68316 SetPt: Make zero always be snappy
Hi @pascal , based on my observations on that bug, when I set 0 in the Command line, it moves the object to at least 5 different distances each time. What’s interesting, though, is that no matter where I press the arrow handle, those few random distances repeat after several trials. It’s especially noticeable when I turn off the Grid snap. One random distance may be 12,41 mm, the next one may be 9,93, the next may be 11,04, then the first one repeats again at 12,41 mm, then 11,04 again, and so on. No matter if I drag the object to the positive or negative direction of the arrow handle, or if I click on the tip or 5 pixels away from it, those few numbers repeat over the time and I still fail to understand what’s the logic behind this particular behaviour since the 0 in the Command line is an exact number which is typically used to set the movement to the center of the CPlane.
I didn’t know that before. Thanks for mentioning.Very useful.
It’s those “hidden” gems that make working effictively so much easier.
I still think the idea I posted a while ago about implementing percentage of the current selection would make a lot of sense in some cases. But as with many (good ?) ideas that suggestion drowned in the sea of too many other requests.
Wow, that was quick! Is there any chance to add the fix to Rhino 7’s Gumball, as well? I guess it’s just a matter of copying a portion of the code that’ already available to the Snappy dragging. Thanks!
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.
But it surely crashes the workflow and accuracy of the Rhino users. Not trying to argue, just saying facts. 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.
What are those unintended consequences? 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.
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.