Pascal Serrarens 17741d862a First commit
2022-01-12 10:50:57 +01:00

105 lines
7.0 KiB
C#

namespace Passer {
/// \version Humanoid Control 4
/// \page Extensions Extensions and tracking
///
/// Note: this documentation is still work in progress...
///
/// The Humanoid Control framework allows you to add support for additional devices
/// which are not supported in the main packages.
/// This document decribes how this can be done.
///
/// Basic architecture
/// ===============
/// Every extension consists of two main parts:
/// 1. The tracking device itself
/// 2. The projection of the tracking device on the humanoid
/// This chapter will decribe the principles for thes two parts:
///
/// The tracking device
/// -------------------
/// All tracking devices are represented as GameObject in the Real World of the Humanoid.
/// Most tracking devices consist of multiple parts. Usually we have one Tracker and multiple Sensors
///
/// ### Tracker
/// The tracker GameObject is the representation of the full tracking device and its Transform is the origin of the tracking space.
/// Examples of this is the Kinect Camera itself, the origin of the OpenVR tracking space or the BaseStation of the Razer Hydra.
/// Every tracker GameObject should have a specific implementation of a Tracking::TrackerComponent attached.
/// Examples these tracker components are Tracking::AzureKinect, Tracking::OpenVR and Tracking::HydraBaseStation.
///
/// ### Sensor
/// Each tracker GameObject can have multiple Sensor children.
/// A Sensor represents a tracking point within the tracking space around the tracker.
/// Examples of these are a tracked hand from the Kinect Camera, an OpenVR Hmd or an Razer Hydra Controller.
/// Every sensor GameObject should have a specific implementation of a Tracking::SensorComponent attached.
/// Examples of these sensor components are Tracking::OpenVRHmd and Tracking::HydraController.
/// The Kinect does not have specific sensor children, but uses Tracking::TrackedBone for skeletal tracking.
///
/// Note: The TrackerComponent and SensorComponent are still simple.
/// In the future they are expected to be extended to simplify the implementation of new custom extsnsions.
///
/// The project of the tracking device on the humanoid
/// --------------------------------------------------
/// Like with the tracking device we have a similar setup for the project on the humanoid.
///
/// ### Humanoid::HumanoidTracker
/// This implements the projection for the humanoid as a whole.
/// It has references to HumanoidSensors for the different parts of the body: head, hands, hips and feet
/// For every extension, an specific implementation of the Humanoid::HumanoidTracker should be created.
/// Examples of this are the Humanoid::KinectTracker, Humanoid::OpenVRHumanoidTracker and Humanoid::HydraTracker.
///
/// ### Humanoid::HumanoidSensor
/// The humanoid sensor takes care of the projection of the sensor to the specific bone in the targets rig of the Humanoid.
/// Most sensors will project to a fixed bone in the rig. For example a VR HMD will always project onto the head bone of the target rig.
/// But sometimes it is possible to select to which bone the sensor will be projected.
/// An example of this is the Humanoid::ViveTrackerArm where you can choose to put it on the hand, forearm, upper arm or shoulder in the rig.
/// Exmples of humanoid sensors are Humanoid::Kinect4Arm, Humanoid::OpenVRHmd and Humanoid::RazerHydraHand.
///
/// The rigs
/// ========
/// Humanoid Control uses two rigs: the tracking rig and the avatar rig.
///
/// ### Avatar rig
/// The avatar rig is the rig of the avatar as you know it:
/// the pose of this rig will determine the pose of the avatar how you will see it.
/// When you change the position of the hand for example, the avatar's hand will follow that hand directly.
///
/// ### Tracking rig
/// The tracking rig is the target pose which is derived from the tracking devices.
/// Humanoid Control will try to align the avatar rig to the tracking rig using forward and inverse kinematics.
/// Note however that differeces will appear between the two rig in many situations. Most important are:
/// - Physical limitations of the avatar:
/// for example the arms of the avatar are not long enough to reach the hand target or the target rig will result in unnatural poses.
/// - Physics:
/// for example the hand target is inside a wall and Huamnoid::HumanoidControl::physics is enabled the avatar's hand will collide with the wall
/// preventing the hand to reacht the target.
///
/// The tracking rig has actually two levels of detail:
/// - The target rig
/// This is a complete rig for all supported bones in the humanoid. It is often visible in the Unity Inspector as a TargetRig GameObject.
/// - The targets. There are 6 main targets: Head Target, Hips Target, 2 Hand Targets and 2 Foot Targets.
/// These targets are often directly visible in the Unity Inspector.
///
/// The targets will actually match the transforms of the matching bones in the target rig.
/// For example the head target will have the same position and rotation as the head bone in the target rig.
///
/// Tracking confidence
/// ================
/// A key component in the use of multiple tracking devices simultaneously is the tracking confidence.
/// Every sensor component will have a specific quality in tracking.
/// For example the Kinect has good positional tracking quality but rotations are of lower quality.
/// This is because of the Kinect technology using a depth camera.
/// On the other hand Perception Neuton has good rotational quality but not so good positional quality.
/// This is because Perception Neuron uses IMUs (rotational sensors) to determine the pose of the user.
/// To cope with this and to be able to merge the data coming from different tracking devices we use tracking confidence.
///
/// Every bone in the target rig has a positionConfidence and rotationConfidence.
/// When an Humanoid::HumanoidSensor updates the position and rotation of a bone in the target rig, it should also update
/// the positionConfidence and rotationConfidences of that bone.
/// The basic rule with this is: when the sensor data has a higher confidence than the target bone,
/// it will update the position and/or rotation and update the confidence of that bone.
/// The tracking confidence is a float in the range 0..1 where 1 represents an 100% certainty that the bone is at that position.
/// There are no hard rules about these values, but we use 0.2 for animated bones (no tracking),
/// 0.5 for fair tracking or values derived from other tracking data. 0.9 for good tracking and 0.99 for excellent tracking.
/// The value 1 is never use because then we have no possibility to override it if this is required.
///
}