Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Twohand-release delay. #24

Open
OlePLarsen opened this issue Feb 1, 2022 · 4 comments
Open

Twohand-release delay. #24

OlePLarsen opened this issue Feb 1, 2022 · 4 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@OlePLarsen
Copy link
Contributor

Right now if you're using a TwoHandGrabbable, and try to release both hands at once it's likely that the model will snap to one hand, before getting released. Thus bouncing away from it's intended placement.

My suggestion is that if handA releases it's grip, there's a timer, and if handB releases the grip within that timer, the model is placed where it was when handA released it.

Having a configurable delay ( like 0.1 sec, or something similar. ) would make it easier to place and release 2-hand interactions, and have them stop 'as expected' when releasing your grip.

The bigger question is how to make this interaction feel proper or 'smuud', instead of it lagging and snapping around for a split second.

@OlePLarsen OlePLarsen added enhancement New feature or request good first issue Good for newcomers labels Feb 1, 2022
@Adrian-Wennberg
Copy link
Contributor

I have been thinking about this a bit and my suggestion is that we change interactions to try to enforce the rule "interaction beams should allways be straight.". This woluld mean that TwoHandGrabbable objects would scale based on the distance between the collision points of the interacton beams with the object, instead of the distance between the hands the way it is now.

This might get clunky if the interaction beams cross or touch at nearly the same point as things would change scale in unexpected or unintuitive ways. , so it would have to be tested and tough properly through first. We would also have to make sure it works well wrt rotation and position, since a change in position or rotation cold also bend the beams at the moment.

@OlePLarsen
Copy link
Contributor Author

To me that feels like a separate, valid issue we need to address.

The release-delay is specifically to combat the transform jump you get when trying to release an object from 2-handed interaction, most notably the location.
Due to it being controlled by 2 -> 1 -> 0 hands, instead of 2 -> 0.
(As both rotation and scaling disable when you release the first hand, pretty sure.)

@Adrian-Wennberg
Copy link
Contributor

Ah, okay. It still sounds a bit weird to me to have the object snap after a short delay. I think it would in theory solve the isse at hand, but the learning curve would go up as it would be non obvious to new user what is going on. It is definitely a quick fix we could try though ☺

I also have another option to suggest. We could say that the fist hand you use is the one that controls position and the second one controls rotation and scale. This way, one of the beams would always be straight. This would mean if you let go with the second hand, it does not snap and you can still move the object around. If you let go with the first hand, we could either make you automatically let go with the second hand, or we could lock the position and still let the second hand be used for rotation and scaling. If we do something like this, we can also use colors to differentiate which beam is which.

Also since there are so many ways to do this, maybe the framework should implement or support multiple and let the app developers pick or customize what works for them 🤔

@MartinHelvig
Copy link
Collaborator

MartinHelvig commented Sep 5, 2022

Many good points here!
MRTK does it slightly different: When "Hand A" releases the object, it will slowly move towards "Hand B" position and straighten the beam. The movement is between 1-2 seconds on the slowest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants