Improbable Icon

SpatialOS Forums

Transferring authority for smooth VR interactions

Hi, I was following along in this thread, and at the end the discussion shifted a bit towards ways to interact with items in VR. Snapshots and player authority entities

I’m working on a VR game as well and want to allow things like picking up and throwing networked objects (using Transform Synchronization). Right now the objects are server authoritative but I’m wondering if there’s a way to quickly switch them to be client authoritative (ex. when I pick it up) and then back to server authoritative (ex. when I release the throw) without issues. I’ve seen some docs about transferring authority over different components but I’m not sure if this is the recommended approach.

If I leave the objects server authoritative then the movement feels jittery and unresponsive to the player holding the object because of the latency between moving their hand and the client-side representation following. Any ideas?

(Using unity gdk)

Hey @LaurenVR

The nature of VR requires minimal latency on player movement and interaction of any kind and this introduces some unique considerations with regards to networking and SpatialOS. You’re correct in your thoughts on making entities player authoritative when being held, similarly to the scenario in the other thread you linked. There are a few different ways you could go about this though and I suppose which you choose would depend on your particular project.

Directly changing the write access authority for the transform component of the entity the player is manipulating would be the most obvious solution, but probably not the most efficient.

Assuming that you’re most likely already replicating the player’s hand tracking in some form, it would potentially be redundant to replicate that same data on a held entity’s transform. If you wanted to optimize for network overhead then it might make more sense to hide/disable the replicated object when grabbed and create a dummy object (with the same model) parented directly to the player’s hand at the point of contact. With this approach the only thing to replicate would be a value indicating what the held object is (and potentially a static transform offset for position/rotation), and it would only need to be updated on grab and again on release (at which point you would move the real entity to the new location, apply relevant forces and un-hide/re-enable it).

This approach would be more network efficient and avoid having to mess around with authority altogether. There would be potential added complexities if you wanted these held objects to have any interactions or behaviors when held, however, which would be something else to consider.