[Interaction] Ability to move items that are attached to hinges about vrtk HOT 24 CLOSED

I've updated the branch, it now handles it differently

There are 3 grab mechanics you can specify now.

• Fixed Joint: works really well for grabbing object (with simple snap, rotation snap, precision snap)
• Spring Joint: works well when you want to manipulate an object with a level of flexibility, opening the drawer uses the spring joint and works quite well.
• Tracked Object: doesn't use a joint to attach to the controller, instead it tracks the objects movement to the controllers movement. This works well for doors as you get a very natural 1:1 control. It's not great for picking up objects though as they are playing catch up and wobble around. Also doesn't work for things like configurable joints (like the drawer) and has no way of breaking the grab when the object is too far from the controller (however, this should be added). This works well with rigidbodies and honours their collisions.

from vrtk.

Two valid points, one I mention in the post above :p

So yeah the break on distance is a must because it's dumb you can have your controller so far away.

And yes it will be possible to set an attach point, this branch is just a sneaky peak for you lovely folks :)

The reason it's on the lid and not the handle is because I think there was an issue when using the track object option on a object that was attached with a fixed joint. I wonder if it would work with if the handle was a child. I'll try it and see.

from vrtk.

I'm happy to experiment to get something that's good. Small steps forward, then learn from the mistakes (like the spring joint implementation!)

I'm hoping to spend some time on this feature tomorrow. I'd like to get it merged but I want it to be acceptable. Doesn't need to be perfect, just a step in the right direction.

I don't think it's acceptable yet though with the fact you can infinitely hold the object no matter how far away you are, and having an attach point too. They're my bare minimum before I merge it I think.

from vrtk.

@thestonefox

I'll model a lamp, a door and that sort of stuff to show it working.

Reposting from the referenced issue. Here's my time to shine. I put together a basic scene with a table, lamp, and doors. Didn't import it into Unity yet, but it should all be fine more or less. Maybe I can iterate on this scene and help you make a little test space.

image preview, toolkit_geometry_v001

fbx file here, https://www.dropbox.com/s/o9rkyfhzizl8d78/Toolkit_Geometry_v001.FBX?dl=0

from vrtk.

@bcoyle reposting my thanks for your work :)

from vrtk.

A work in progress branch for people to try out
https://github.com/thestonefox/SteamVR_Unity_Toolkit/tree/feat/hinged-object-interaction

The drawer still isn't working at the moment, and I've not tried a multi hinged item yet.

The box and the door work well.

from vrtk.

Awesome! Behavior is damn near perfect with only TWO small thing that seems entirely fixable...

...but a given object that has the Track Object option snaps to the controller (and it seems that the leading surface of the door closest to you is aligned with the local center of the controller). Is it not possible for the offset of the controller to the rigidbody be introduced as the grab point?

Secondly, I couldn't pull the controller away from the door to break the connection to the door, another small thing that should be implemented, lest someone could grab a door, walk far away and still manipulate it.

Also as an aside, but in previous versions of the case with the lid, the handle was what you had to grab in order to open it (which is natural). Now you've made the entire lid the grabbable entity. Is this a limitation to using Track Object, or just something you changed? I'd very much rather grab the doorknob, including even having to turn it in order to open the door. This obviously goes without saying, but we want to replicate the real world as much as possible.

Hopefully I'm being constructive and not needlessly picky, but this feels so good and is so close, I'd be remiss if I didn't at least bring these up as talking points. The door movement right now feels so good!

from vrtk.

Oh and what a sneak peak it is! Loved it!!

Alternatively (in the event adding back the handle/knob doesn't work), couldn't we have he interaction isolated to a collider that is only on the handle/knob, leaving the overall object collider there purely for physics?

from vrtk.

Hmm, you mean so the knob is the interactable object but it actually affects the parent object?

That would be doable, but probably would need a custom script.

I'll try get it to work without the need of custom scripts though first.

from vrtk.

Yea ultimately it would be a more authentic experience if yes, having to turn a handle or knob effectively allows a door to open. I don't necessarily expect you to write custom scripts for every situation (I can handle that), but the physics-interaction foundation would probably have to be there yea i'm guessing.

from vrtk.

I think the ideal generic script would be moving a child moves the parent, so in the case of the box the handle opens the box (however, you could grab the box lid in real life and open it too).

Or in the case of the door, grabbing the handle opens it.

Problem when doing it with fixed joints (e.g. the handle is fixed to the door via a fixed joint) is the physics system goes crazy and tries to pull the joint off the door and looks daft.

I'll try it with just parenting the door and see if that helps.

Things like having to rotate a handle down before the door opens I think will need to be custom scripted.

However, you could do this probably by making the handle grabbable on a configurable script (to give it the limited rotation motion). then on the handle reaching it's limit could then say make the parent (door) kinematics as false (previously set to true to stop the door from opening) then the handle child should move the door too.

This is just a wild idea, I dunno if it would actually work, I'll have a play with it though

from vrtk.

Heck I love you're willing to experiment like this!

BTW when do you plan to branch all of this into master? When you're happy with the implementation?

from vrtk.

Not gonna lie...I'm thrilled you got Track Object in. Regardless of the infinite-hold issue, it feels so much better

from vrtk.

Ok, new version on the branch now (just download the head of the feat/hinged-object-interaction branch).

It now supports distance breaking on TrackObject, plus Precision_Snap mode also works on TrackObject so you can pick up at the point of collision.

I've also made the box handle the interactable thing again by attaching it to the lid with a fixed joint. You can see though if you pull the controller too far away from the handle it starts messing up the physics engine and pulling away from the lid. The solution is to lower the Detatch Threshold so any slight movement causes the grab to disengage.

Have a play, let me know if you find any bugs, if it's ok then I think at the moment I'm happy for this iteration to be merged into master.

from vrtk.

Sweet! I absolutely will when I'm back on the my VR rig around noon CST.

from vrtk.

Great, thanks!

from vrtk.

Feeling better and better each iteration, I love it!

Interesting anomaly regarding Precision_Snap on the door...

...but the further away from the center of the door you grab (relative to the hinge), the quicker or slower the door opens. In other words if I grab the door closer to the knob, the door doesn't appear to swing 1:1 with the controller as it does with 'Simple_Snap', but rather the effect "appears" multiplied. The door swings very quickly and well ahead of the controller the further you move it. If I'm not mistaken the door thinks you grabbed it at the center, but the controllers world transform position is much greater, relative to the doors local center, and thus the door moves much further breaking the visual cohesiveness. If do you manage to grab the door closer to its center (mind you local center, nothing to do with the hinge), the door viduslly behaves 1:1. This appears it will need some tweaking.

Another thing that came up while toying around, but catching objects is more difficult here than in The Lab. Have you considered adding either a pre-grip timer to the control so that if the user pulls and holds the trigger (as long as they're not near another interactable object) before the thrown object lands near their "hand", the user catches the object. By using a timer, you give them an envelope of time to catch the object, but if that timer expires (if they pulled and held the trigger long before the object reaches their hand), then they still miss the catch. It's a way to mitigate the need for absolute precision, plus I've noticed that even when I grab the object RIGHT when it's over my controller, at times it doesn't grab and the object passes through.

If that doesn't make sense I can explain it differently.

Great work man

-Steven

from vrtk.

@xEvoGx
I think the precision snap on the door may go a bit wonky because of how that grabbing works. it basically moves the velocity of the grabbed item in relation to the grabbing point, in precision grabbing that point is artificially created (and destroyed on ungrab).

I expect precision grabbing would work better on the door knob only.

I'll take a look at the NewtonVR code again and see if they resolve the issue.

I'll look into the grabbing/catching too.

Haven't had chance all day to look at this toolkit :(

from vrtk.

Hmmm so just chucking this idea out there, but what would be the inherent difference between grabbing the Door Knob, or instead grabbing an artificial Door Knob so to speak at the grab point?

Hey you'e been making great progress, so at the very most I suspect you're just eager to get to it huh? :)

Cheers man

-Steven

from vrtk.

So I looked at the NewtonVR stuff again, They have a completely different script for handling grabbing items that rotate around a hinge where they apply force rather than change the velocity.

I think for now, it's best to just not use "precision grabbing" on the doors as the simple snap seems to work relatively well.

I'll put some more time aside to this in the future to see if there is a way of making it generic so it applies to many joint types, otherwise I'll end up with scripts for each specific purpose! :)

I'm going to tidy this up and merge it in, it serves enough of a purpose for now :)

from vrtk.

Completed with 93fa933

This may come up again in the future! :)

from vrtk.

Hmmm so wait maybe I'm not understanding. Why is it that Simple Snap works perfectly, only that the object in question 'snaps' to the controller if not aligned? Why then can't that same offset be introduced into Precision Snap, as IF the behavior was a Simple Snap.

Or perhaps coming at it the other way, why can't Simple Snap have this same offset and mitigate the issue altogether?

Regardless everything does work far better than it did originally, so bravo to that my friend! :)

Cheers

-Steven

from vrtk.

It's because Simple Snap tracks the object from the center of it (i.e the center of the door)

Whereas, Precision snap adds a new "invisible" object to the point where you interacted with the door, so the force is exerted in relation to that offset rather than the center.

I tried doing things like working out the point at which the collision happened but it's so flakey, that's propbably why NewtonVR attach the invisible grab point object as well.

I may be able to use that new invisible object position to create an artificial offset, but I expect any time I try and do that it will just mess up the velocity calculations.

The way NetwonVR do door opening is using forces applied in the direction the controller is pulling.

Something I could look to implement as another mechanism, but seems really restricted to doors (in their scene anyway).

from vrtk.

I see and yea I have to factor in that while mathematically we can see what's gong on, the physics can only do so much to both behave correctly and give us coherence.

I got it now thanks Stone!

from vrtk.