Snaps are on and sometimes do not display when selecting Point to move from during Move command:
Note that Rhino dropped a marker under the cursor while it was briefly stationary during the Point to move selection. This can be seen south east of its current location.
After cancelling and rerunning Move command, with no other changes, the same selection shows the snaps correctly:
Rhino 7.7.21151.13001, 2021-05-31 (with Grasshopper running but minimised and with preview off. Grasshopper references the point being moved).
Hi Jeremy -
I’ve tested this a bit with a circle and a point and that point being reference in Grasshopper but I’m not seeing any issues with the display of the snap.
That’s the frustrating thing about intermittent bugs . Next time I see it I’ll try and think if there is anything specific about the circumstances. Its happened several times, so hopefully not too long till the next time.
FWIW this is only happening since the SRC mentioned.
OK, somewhat reproducible. Bug appears if in response to ‘Select objects to move’ I select the circle first, followed by the point and when selecting the point the Selection Menu pops up for me to choose between the point and the underlying curves and I choose the point from it. Then leave the cursor where I had clicked on the Selection Menu and rest it there before hitting Enter to complete selection. After which moving the cursor leaves the dropped marker behind and snaps are not highlighted.
The bug does not seem to happen if I manage to select the point without the Selection window popping up.
The bug does not seem to happen if Grasshopper is closed.
The bug is reproducible repeatedly if I meet the described criteria.
Slideaway Wim.3dm (1.6 MB)
4bar_utility hinge_Kangaroo_002.gh (38.4 KB)
Hi Jeremy - do you mean the cursor snaps but the tag does not show what the snap is, or the snap is not active at all? I have seen the latter from time to time, and every time I go to make a bug report, I cannot repeat it, even with the same file and operation - but I know it is there.
@jeremy5 - yes, got it - thanks, I can repeat this here. I do not think my cases involve GH but this is repeatable so a great start.
RH-64532 Osnap - fails with GH running and selection menu
Snap isn’t there @pascal. I’ve just posted more criteria to reproduce and copies of the files, so maybe that will help you repeat it.
It looks like this problem is caused by having the ‘Grab’ component of Kangaroo running, which is intercepting these particular mouse events where the Rhino dropdown Selection menu overlaps a Kangaroo point, so it starts dragging the Kangaroo point (and it’s not obvious to see this is what is happening when the GH preview is off).
I’m trying to find a way to avoid this happening at all, but currently this issue could be worked around by disabling the Grab component or closing Grasshopper if you want to interact only with the Rhino document.
Thanks for the insight. However, after further investigation I am inclined to think that it is the fact that the selected point is a kangaroo point, rather than the selection menu overlies one, which triggers the problem. I say that because:
a) if I leave geometry preview enabled I do not see any sign that I have grabbed anything (i.e. no kangaroo point moves when I move the mouse) but I still lose the snaps indicators.
b) if I add similar geometry to the viewport, don’t reference it in Grasshopper, but place it so that the selection menu will lie over a kangaroo point, then the move command executes correctly without displaying the bug.
c) in my initial experiments I’m not convinced that the selection menu did lie over a kangaroo point.
I can confirm that the bug seems to disappear with grab disabled.
Thanks for experimenting and reporting.
I agree - it seems it’s just the initial point clicked being close to grabbable Kangaroo point that matters.
I think the way the mouse release event for the dropdown is handled in Rhino is causing Kangaroo not to properly end the grabbing even when the button is no longer pressed. Is it possible you weren’t seeing anything moving because the grabbed point was anchored? (meaning it would still be intercepting mouse events and stopping Rhino snaps working, but not moving).
I have what I think is a fix - I’ll upload for testing soon.
Have a go with this - you can replace the existing grab component in your definition with this one (appears on the Kangaroo2>Main tab with a blank icon).
GrabFix.gha (10 KB)
I’d be interested to hear if it fixes your issue.
Good news! I haven’t been able to reproduce the bug whilst using GrabFix. At the same time, I haven’t noticed any change in the grab behaviour (once I disabled the original Grab instead of just disconnecting it…).
One question: the original Grab strength was set to 0.001 whereas GrabFix was set to 1. I tested with both values without apparent difference unless perhaps the movement was smoother at 0.001. What and how much effect does this parameter have?
Great. Glad to hear it’s working. I’ll apply this change to the built in Grab component for the next SRC.
About the strength - it’s essentially the strength of a spring between the grabbed point and the mouse location (as a 3d ray). For something like this where you want it to behave as a constrained linkage of rigid parts, if the grab strength is very high, then you’ll be able to stretch and pull apart the linkage, while setting Grab strength very low means the points will move only along the paths possible without stretching the parts.