Proximity Toolkit Core
When creating the Proximity Toolkit, we had to think about the core concepts that play into the notion of proximity. At the same time, we needed to take into account the limitations that may exist inherently in the devices used to take the measurements that reconstruct a fallible model of the 3D space.
At the heart of it are the concepts of Presence and Space. We refer to Space as the realm of possibility for the existence and configuration of Presences, oftentimes the range and fidelity of the sensors, while we consider Presence to be an existence and identity that is detected by the sensors to be within the Space.
To define the configuration of individual Presences within the Space, the Proximity Toolkit provides proximity “decorators” (optionally applicable collections of proxemic attributes) that can be mixed and matched depending on the nature of the data available.
Location – provides the absolute location of a Presence within the Space, represented as a 3D coordinate. In all likelihood the Presence has volume; however this decorator only considers location as a single point, usually the centre of mass (e.g. a ball’s location represented as a point at its centre).
This also assumes that a certain point within the space is considered the origin, and that X, Y, and Z axes point in certain directions orthogonal to one another, forming a 3D coordinate system. The location coordinate exists relative to this arbitrary origin, and according to the axes.
Changes in location between updates also provide direction and magnitude of Velocity and Acceleration of the Presence, relative to the Space.
Motion – provides measurements of Velocity and Acceleration in standard units (distance/second and distance/second2 respectively).
Orientation – provides information about how a Presence is turned within the Space, relative to a ground plane (along the X-Z axes) and an Up direction (the Y axis).
Orientation can only be determined depending on an object’s designated forward and up direction. This is often determined according to how humans hold or interact with the object (e.g. a tea kettle’s spout points forward - away from the person holding it by the handle - and lid points upward). Some objects with uniform geometry that lack distinguishable features (e.g. a solid-coloured ball) may designate an arbitrary forward and up direction, or opt not to use an orientation decorator at all since this information would be essentially useless.
We chose to represent Orientation as angles of Incline, Azimuth, and Roll: Incline being the angle of the forward direction of the presence, parallel to the ground plane; Azimuth being the angle of rotation of the forward direction about the Y axis, relative to the positive direction of the X axis; and Roll being the rotation of the up direction about the forward direction. We chose this schema over the traditional Pitch/Yaw/Roll schema because PYR is not absolute (i.e. there are many combinations of PYR values that represent the same orientation) and can produce values that we found are not intuitive to work with. Here, the Roll information is optional, in which case this decorator can be merely an indication of Direction.
Rotation – provides information about the rotation of a Presence and can be used as an alternative representation of Orientation. Conceptually, Orientation indicates the features of the Presence relative to the Space, while we use Rotation to indicate the difference in a Presence’s actual orientation from a default orientation.
Rotation is represented by Axis and Angle values, which express the rotation as a certain scalar Angle about the given Axis vector.
Some extended decorators pertain to subparts of a presence:
Markers – represents a collection of individually locatable points within a Presence, as PresenceMarker objects.
Pointers – represents features of the Presence that can be used to indicate direction, as PresencePointer objects.
Display - represents displays that are attached to objects (as in phones or tablets) in order to track pointing. This defines display bounds and their attachment relative to a Presence, and ensures the display orientation remains consistent with the orientation of the Presence anchor.
The toolkit’s modular structure can also allow for custom decorators to be defined and applied to Presences, however it is up to the client application to interpret this data. This can be done by querying the data hierarchy for known values, or by referencing the module's library for the decorator's type definition.
For instance, the Vicon Input Module provides a custom Pose decorator that represents the kinematic configuration of bones (PresenceStick) and joints (PresenceJoint) within the Presence.