🧩Modules
HPTK is like a puzzle. Each piece implementes the MVC pattern.
Last updated
HPTK is like a puzzle. Each piece implementes the MVC pattern.
Last updated
This section describes the code architecture of an HPTK module and the different modules included:
Hand-specific:
Input: Drives master hand by reading an Input Data Provider.
Gesture Detection: Provides values from 0 to 1 for different basic or extended/custom gestures.
Part-specific:
Puppet: Drives slave part by reaching its master part.
Contact Detection: Provides contact info for each object hovered/touched by its part.
HPTK modules implement the MVC pattern. Each instance of an HPTK module contains a View, a Model and a Controller which are MonoBehaviour components.
Each HPTK module is a GameObject with these 3 components. SubModels and SubViews are grouped in child GameObjects. This way the hierarchy of GameObjects matches the data hierachy of the module.
Hierarchy | Model / View / Controller | SubModel / SubView |
View is a component that is safe to be shared and accessed by any other component in the scene.
It only exposes properties, events and methods that can be used freely without risk of causing errors. A View can access its Model (and therefore its Controller) internally but their references are not exposed publicly.
By using only references to Views in your custom components you are ensuring low code coupling.
Here's a short description of what you can find in a View:
Properties: Model's variables that are safe to be read (and sometimes written) by any other script.
Events: UnityEvents that are invoked by the Controller.
Methods: Controller's methods that are safe to be called by any other script.
Views can have SubViews, each of them with their own properties, events and methods.
It's posible to reach any part or child module of an avatar from its View. HPTK.core containes the Views of the Avatar modules of any registered avatar. Check out Examples to see how to access and use Views.
Models contains data and references.
Variables and references to sub-models, registered modules, MonoBehaviour components and ScriptableObjects are stored in Models.
The Awake function is the only logic that a model can execute by itself. This is useful for detecting and fixing missing references before the Controller starts. This way, by the time the controller starts, the Model will have had time to fix missing references (where possible).
Models can have SubModels, each of them with their own SubView but all driven by the same controller as they are part of the same module.
Controllers contains the business logic.
Each instance of an HPTK module has its own Controller.
Controllers are responsible of registering themselves in the registry of their parent module. Avatar modules don't have a parent module but they are registered themselves in HPTK.core.avatars.
