Plugins

Component model

The Unity plugin follows a component-based model. You build Teslasuit behaviour by adding components to GameObjects and connecting them, rather than by writing procedural setup code. This page explains the pieces you compose and how to put them together.

Components and assets#

Everything in the plugin is expressed as Unity components and ScriptableObjects:

Components (MonoBehaviours) are added to GameObjects. They handle device access, haptic playback, motion animation, and biometry streaming.
Assets (ScriptableObjects) hold configuration and content: avatar settings, simplified haptic channels, and imported .ts_asset files.

Because the plugin uses Unity's own component and event systems, you compose features by attaching the right components to the right objects and pointing them at each other in the Inspector.

Quick start with a ready-made setup#

The fastest start is the wiring the plugin already ships. Pick the one for your device, then add your own components and scripts on top:

Glove: drop in a fully rigged hand_l or hand_r prefab. Each is a complete glove object (a TsGloveBehaviour with TsLiveMotionProvider and TsHandAnimator already wired), so you connect a glove and get a live tracked hand with no setup.
Suit: start from the Suit mocap example scene, which wires a character to the suit stream. It uses a demo character (Ethan), so retarget it to your own rig when you build for real.

Build it from components#

When neither ready-made setup fits, or you want full control, you can compose the device object yourself:

Add a GameObject to represent the device.
Attach a device behaviour. Device access comes from a TsDeviceBehaviour, which is abstract, so you add one of its concrete forms:
- TsSuitBehaviour provides a suit, selected by SuitIndex (for example, Suit0 for the first suit), and exposes the device as an ISuit.
- TsGloveBehaviour provides a glove, selected by GloveIndex and a TsDeviceSide (Left or Right), and exposes the device as an IGlove.
Add MonoBehaviour scripts to the same GameObject to interact with the various subsystems (haptics, mocap, biometry) as desired.

Each subsystem component finds the device behaviour through GetComponent, requires it to be present, and becomes usable automatically once the device connects. You rarely write connection or session code yourself: the device behaviour and subsystem components handle that.

Layer your own MonoBehaviour#

Your own logic goes in a MonoBehaviour on the same GameObject. Source the subsystem components in Start, then drive them from Update or your own methods:

using TsSDK;
using UnityEngine;

// Attach to the suit GameObject. RequireComponent adds the subsystem
// components automatically if they are not already there.
[RequireComponent(typeof(TsSuitBehaviour))]
[RequireComponent(typeof(TsHapticPlayer))]
[RequireComponent(typeof(TsPpgProvider))]
public class SuitDemo : MonoBehaviour
{
    private TsHapticPlayer m_haptic;
    private TsPpgProvider m_ppg;

    private void Start()
    {
        m_haptic = GetComponent<TsHapticPlayer>();
        m_ppg = GetComponent<TsPpgProvider>();
    }

    private void Update()
    {
        // Use m_haptic to play touches and m_ppg to read heart rate here.
    }
}

You can keep all your logic in one script like this, or split it across several small MonoBehaviours on the same object, one per concern. Both work; use whichever suits your project.

This is the recommended pattern for almost all projects. For advanced needs, such as reaching the native session directly, resolving devices yourself, or reacting to connection changes, see Advanced development.

Component model

Components and assets#

Quick start with a ready-made setup#

Build it from components#

Layer your own MonoBehaviour#

What to read next#