VR Expansion Plugin Documentation

5.Gripping System

Please familiarize yourself with this list prior to reading

Common Plugin Terms

  • Slot Grip: Is generally a grip that is “snapped” / “slotted” to a specific socket on the object.
  • Server Authoritative: Server has final say on these grips and calls the Grip/Drop functions.
  • Client Authoritative: Gripping Client has final say on these grips and calls the Grip/Drop functions, then notifies the server about it.
  • Late Update: Epics late rendering thread transform update to the motion controller and attached components (VISUAL ONLY) to make up for the 1-2 frame latency in the engines rendering (makes controllers feel more 1:1 with actual movement).

 

Grip system Pro/Con list

Cons:

  • Manual implementation of the when/why/how to grip setup (to retain flexibility)
  • Complicated to get started in
  • If working in networking you will need to learn some specific terms (Client Auth, Server Auth ect) and how the workflow for them goes.
  • Manually implementing the interface for into your own objects can be tedious (though there is generally not much reason to do this).

Pros:

  • VERY flexible, the gripping system is made to be as open to whatever mechanic that you desire as possible, over time this flexibility will increase as I abstract/modularize more of it.
  • Many different grip types and options to modify / support them.
  • Fully networked from the get go (assuming the “manual implementation” part is taken care of).
  • Once setup, is as easy as dragging into the level, setting the mesh and some options and forgetting about it for basic grips.
  • Pretty efficient, as far as replication goes, generally only the initial grip and drop are required to send data, for some specific things they may replication over the course of a grip but only if changed.

Notes

While technically the total number of grips that a hand can have is “unlimited”, there IS a specific limitation that I added in later in the plugins life. Grip structures now contain a GripID byte that identifies the grip per controller (these IDs are NOT unique globally, just to the controller), they are split from 0-127 on normal (server auth) grips, and 128-255 on local (client auth) grips. Technically this means that you cannot have more than 127 unique grip IDs at one time on a controller.

Grip IDs were implemented to sort out some replication issues with TArrays and identifying drops and new grips separately as well as to allow for a cleaner grip identification that allows object deletion.

Suggest Edit