Proximity Toolkit Core Concepts
Toolkit Structure
The Proximity Toolkit uses a client-server model.
Proximity Server (Application)
The Proximity Server is a pre-built application that is responsible for collecting and processing raw data from one or more input sources.
Each input source must be wrapped as a ProximityInputModule in its own .DLL file adjacent to the server application. When the Proximity Server application loads, it will detect and attempt to load all .DLL libraries that match the pattern "*Module.dll". If the library contains a definition for a subclass of ProximityInputModule, the module will be instantiated and hooked into the server's input polling and processing pipeline. For safety purposes, on the detection of any new or changed modules, the program will prompt you to decide whether or not to load the module. The program can be configured to ignore notification about changes to modules of which it is aware, which is useful to accommodate recompilation during module development.
Each server represents a particular Proximity Space, which is the area in 3D space where proximity interactions can be detected by our hardware. If it makes sense to do so, multiple Proximity Spaces can be represented on a single server instance by connecting additional servers to that instance. However, in general only one space can be represented per machine.
Proximity Toolkit (Library)
In most cases, application developers will use the client to connect to the server program on their local machine, or perhaps across a network. The client toolkit is a library that can be used in your programming project, which handles network communication and updates, as well as the calculation of relationship data between objects.
Relationship data is calculated by request only, which can be specified upon creation of a RelationPair object, or by attaching an event handler to any one of its events. The RelationPair contains a general event callback for all updated data which occurs after all specific update callbacks.
Proxemics
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.