Proximity Toolkit

Toolkits.ProximityToolkit History

Hide minor edits - Show changes to output

March 25, 2013, at 04:21 PM by 136.159.7.119 -
Deleted lines 38-58:

!!!History
* Version 2.1 (in progress)
** Updates for record/simulation function
** New tracking plugins
** Transition to public subversion repository
* Version 2.0
** Includes support for Microsoft Kinect
** New collection of sample applications
** Updated plugin architecture
** Updates and bug fixes for all included tools (e.g., visualization)
* Version 1.2.1
** Includes support for WPF applications
** Many bug fixes to the ProximityServer application
** Includes sample content
* Version 1.1.0
** Major updates to client side API
** Support for Winforms graphical layout
* Version 1.0.0
** First official release.
Added line 80:
Changed lines 20-22 from:
----
to:
\\

\\
Added line 15:
%rfloat% Attach:proximity-toolkit.jpg
Changed lines 9-12 from:
Contents: [[#intro | Introduction]] | [[#download | Download and Installation]] | [[#recipes | Recipes, How-To's]] | [[#tutorials | Tutorials and Examples]] | [[#links | Links]] | [[http://grouplab.cpsc.ucalgary.ca/proximitytoolkit | Reference]]
----
to:
Changed lines 17-34 from:
Currently, our primary source of input is a Vicon motion tracking system, which provides highly accurate tracking on objects that are tagged with a combination of several infrared-reflective markers. In the most recent version 2.0 of the toolkit we also added support for tracking through Microsoft Kinect depth-sensing cameras..

!!! Topics
* [[ProximityToolkitCoreConcepts | Core Concepts]] - Core concepts of the Proximity Toolkit.
* [[ProximityToolkitDataHierarchy | Data Hierarchy]] - An explanation of the data hierarchy, and how to work with it.
* [[ProximityToolkitServer | The ProximityServer]] - Using the ProximityServer application.
* [[ProximityToolkitSubjects | Tracked Subjects]] - A list of standard subjects available for use in the lab.
* [[ProximityToolkitEvents | Client Events]] - A discussion on how the client-side toolkit events and monitors work hand in hand.
* [[ProximityToolkitCollisionDetection | Collision Detection]] - An explanation of the collision detection functionality built into the toolkit.

!!! Modules

* '''ViconInputModule''' - Based on the [[ViconToolkit | Vicon Toolkit]], this module gathers input from a Vicon motion tracking system. (Status: COMPLETE)
* '''KinectInputModule''' - This module gathers input from a Microsoft Kinect depth-sensing camera. (Status: COMPLETE)
* '''ARToolkitModule''' - Based on the ARToolkit, this module gathers identity and position data from 2D markers as seen by a webcam. (Status: NOT STARTED)
* '''PhidgetsModule''' - Uses the [[Phidgets-NET | Phidgets .NET]] API to gather information from any number of sensors. (Status: NOT STARTED)
to:
Currently, our primary source of input is a Vicon motion tracking system, which provides highly accurate tracking on objects that are tagged with a combination of several infrared-reflective markers. In the most recent version 2.0 of the toolkit we also added support for tracking through Microsoft Kinect depth-sensing cameras.
Changed line 38 from:
* Version 2.1 (planned)
to:
* Version 2.1 (in progress)
Added line 41:
** Transition to public subversion repository
Changed lines 56-59 from:
* Version 1.0.1a
** Several fixes to calibration bugs
to:
Changed line 62 from:
!!! Recipes and How-To's
to:
!!! Documentation and How-To's
Added lines 64-68:
* [[ProximityToolkitCoreConcepts | Core Concepts]] - Core concepts of the Proximity Toolkit.
* [[ProximityToolkitDataHierarchy | Data Hierarchy]] - An explanation of the data hierarchy, and how to work with it.
* [[ProximityToolkitServer | The ProximityServer]] - Using the ProximityServer application.
* [[ProximityToolkitEvents | Client Events]] - A discussion on how the client-side toolkit events and monitors work hand in hand.
* [[ProximityToolkitCollisionDetection | Collision Detection]] - An explanation of the collision detection functionality built into the toolkit.
Added lines 71-76:

!!! Tracking plugins
* '''ViconInputModule''' - Based on the [[ViconToolkit | Vicon Toolkit]], this module gathers input from a Vicon motion tracking system. (Status: COMPLETE)
* '''KinectInputModule''' - This module gathers input from a Microsoft Kinect depth-sensing camera. (Status: COMPLETE)
* '''ARToolkitModule''' - Based on the ARToolkit, this module gathers identity and position data from 2D markers as seen by a webcam. (Status: NOT STARTED)
* '''PhidgetsModule''' - Uses the [[Phidgets-NET | Phidgets .NET]] API to gather information from any number of sensors. (Status: NOT STARTED)
Changed lines 56-57 from:
** Updates for record/simulation functions
to:
** Updates for record/simulation function
** New tracking plugins
Changed lines 59-60 from:
** Includes support for Microsoft Kinect.
to:
** Includes support for Microsoft Kinect
** New collection of sample applications
Changed lines 64-66 from:
** Includes support for WPF applications.
** Many bug fixes to the ProximityServer application.
** Includes sample content.
to:
** Includes support for WPF applications
** Many bug fixes to the ProximityServer application
** Includes sample content
Changed lines 68-69 from:
** MAJOR updates to client side API - you'll love it!
** Support for Winforms graphical layout.
to:
** Major updates to client side API
** Support for Winforms graphical layout
Changed line 71 from:
** First official release! Please inform us of bugs.
to:
** First official release.
Added line 12:
Deleted lines 14-21:
>>redbox<<
!!! Note
We will release the new '''Version 2.0''' of the Proximity Toolkit soon -- including the '''full integration of Kinect''' depth-camera tracking, updated API, and new tools. The information, instructions, tutorials, and examples on this page all refer to the previous version 1.2.1 (with VICON tracking only). The new version 2.0 will be also available as open source, allowing developers to extend the architecture (e.g., through new plugins providing tracking data).

>><<

\\
Changed lines 19-20 from:
Currently, our primary source of input is a Vicon motion tracking system, which provides higly accurate tracking on objects that are tagged with a combination of several infrared-reflective markers. Our plans are to expand the toolkit to include other input sources such as the ARToolkit (which tracks identity and position of 2D markers from webcam images) and Phidgets (which use low-level hardware devices and sensors to collect basic input).
to:
Currently, our primary source of input is a Vicon motion tracking system, which provides highly accurate tracking on objects that are tagged with a combination of several infrared-reflective markers. In the most recent version 2.0 of the toolkit we also added support for tracking through Microsoft Kinect depth-sensing cameras..
Added line 32:
* '''KinectInputModule''' - This module gathers input from a Microsoft Kinect depth-sensing camera. (Status: COMPLETE)
Changed lines 36-41 from:
!!! Demo Applications

The ProximityToolkit comes bundled with two demo applications that use the ''WhiteHat'' and ''Pencil'' subjects, on the ''SmartBoard'' display:
* '''ProximityPaint''' - A painting program that allows for color selection by looking and pointing; painting and erasing at various thicknesses by distance of the pencil to the display; and zooming by distance of the hat to the display.
* '''ProximityFace''' - A fun application with a face that reacts to the distance, direction, and motion of the hat. The pencil acts as a flashlight metaphor, demonstrating pointing and touching.
to:
Added lines 42-47:
* '''[[Attach:ProximityToolkit-Version2.0.zip | ProximityToolkit-Version2.0.zip]] (Version 2.0 | October 4th, 2011)'''\\
Complete source code package of the toolkit; including server, visualization, and developer API. An installer version of the toolkit follows in the next weeks. The source code development will also be moved to an open subversion repository.
* '''[[Attach:ProximityToolkit-Version2.0-Examples.zip | ProximityToolkit-Version2.0-Examples.zip]] (October 4th, 2011)'''\\
Collection of simple example applications and code snippets

!!! Archived versions
Changed lines 49-50 from:
!!!Bug Fixes
to:
* [[Attach:ProximityToolkit-1.1.0.msi | ProximityToolkit-1.1.0.msi]] (Version 1.1.0 | Aug 26, 2010)
* [[Attach:ProximityToolkit-1.0.0.msi | ProximityToolkit-1.0.0.msi]] (Version 1.0.0 | Aug 17, 2010)
* [[Attach:ProximityToolkit1.0.1a-Setup.msi | ProximityToolkit1.0.1a-Setup.msi ]] (Version 1.0.0a | June 2, 2010)
* [[Attach:ProximityToolkit1.0.0a-Setup.msi | ProximityToolkit1.0.0a-Setup.msi ]] (Version 1.0.0a | June 2, 2010)

!!!History
* Version 2.1 (planned)
** Updates for record/simulation functions
* Version 2.0
** Includes support for Microsoft Kinect.
** Updated plugin architecture
** Updates and bug fixes for all included tools (e.g., visualization)
Changed lines 73-79 from:
!!!Archived Versions
* [[Attach:ProximityToolkit-1.1.0.msi | ProximityToolkit-1.1.0.msi]] (Version 1.1.0 | Aug 26, 2010)
* [[Attach:ProximityToolkit-1.0.0.msi | ProximityToolkit-1.0.0.msi]] (Version 1.0.0 | Aug 17, 2010)
* [[Attach:ProximityToolkit1.0.1a-Setup.msi | ProximityToolkit1.0.1a-Setup.msi ]] (Version 1.0.0a | June 2, 2010)
* [[Attach:ProximityToolkit1.0.0a-Setup.msi | ProximityToolkit1.0.0a-Setup.msi ]] (Version 1.0.0a | June 2, 2010)
to:
Added lines 88-89:
* [[Attach:ProximityToolkit-Version2.0-Examples.zip | ProximityToolkit-Version2.0-Examples.zip]] (October 4th, 2011)\\
Collection of simple example applications and code snippets
Changed lines 103-104 from:
* Coming Soon
to:
* [[http://grouplab.cpsc.ucalgary.ca/Projects/ProjectProximityToolkit]]
Deleted lines 106-114:
[[#futurework]]
>>greybox<<
!!! Future Work
* [[ProximityToolkitFutureWork | Proximity Toolkit Future Work List]] - Suggestions for future Proximity Toolkit fixes and features.

!!! Bugs
* [[ProximityToolkitBugs | Bug Tracking]] - An area to document bugs in the ProximityToolkit.

>><<
May 26, 2011, at 05:36 PM by 136.159.7.55 -
Changed line 107 from:
>>redbox<<
to:
>>greybox<<
May 26, 2011, at 05:35 PM by 136.159.7.55 -
Deleted lines 21-22:
May 26, 2011, at 05:35 PM by 136.159.7.55 -
Changed lines 20-23 from:
to:
\\

May 26, 2011, at 05:35 PM by 136.159.7.55 -
Changed lines 16-17 from:
We will release the new '''Version 2.0''' of the Proximity Toolkit soon -- including the '''full integration of Kinect''' depth-camera tracking. The information, instructions, tutorials, and examples on this page all refer to the previous version 1.2.1 with VICON tracking only.
to:
We will release the new '''Version 2.0''' of the Proximity Toolkit soon -- including the '''full integration of Kinect''' depth-camera tracking, updated API, and new tools. The information, instructions, tutorials, and examples on this page all refer to the previous version 1.2.1 (with VICON tracking only). The new version 2.0 will be also available as open source, allowing developers to extend the architecture (e.g., through new plugins providing tracking data).
May 26, 2011, at 05:33 PM by 136.159.7.55 -
Changed lines 16-17 from:
We will release the new version 2.0 of the Proximity Toolkit soon -- including the full integration of Kinect depth-camera tracking. The information, instructions, tutorials, and examples on this page all refer to the previous version 1.2.1 with VICON tracking only.
to:
We will release the new '''Version 2.0''' of the Proximity Toolkit soon -- including the '''full integration of Kinect''' depth-camera tracking. The information, instructions, tutorials, and examples on this page all refer to the previous version 1.2.1 with VICON tracking only.
May 26, 2011, at 05:32 PM by 136.159.7.55 -
Added lines 12-13:
\\
May 26, 2011, at 05:32 PM by 136.159.7.55 -
Changed line 13 from:
!!! Notes
to:
!!! Note
May 26, 2011, at 05:32 PM by 136.159.7.55 -
Added lines 12-18:
>>redbox<<
!!! Notes
We will release the new version 2.0 of the Proximity Toolkit soon -- including the full integration of Kinect depth-camera tracking. The information, instructions, tutorials, and examples on this page all refer to the previous version 1.2.1 with VICON tracking only.

>><<
Changed lines 99-100 from:
* [[ProximityToolkitFutureWork | Rob's Future Work List]] - Suggestions for future Proximity Toolkit fixes and features.
to:
* [[ProximityToolkitFutureWork | Proximity Toolkit Future Work List]] - Suggestions for future Proximity Toolkit fixes and features.
November 07, 2010, at 01:14 PM by 136.159.18.20 -
Changed lines 89-90 from:
* [[Attach:2010-09_ProximityToolkit.pptx | 2010/09/14 Proximity Toolkit Presentation]] (save as .pptx) - a presentation on using the ProximityToolkit.
to:
* [[Attach:2010-09_ProximityToolkit.pdf | 2010/09/14 Proximity Toolkit PDF]] and [[Attach:2010-09_ProximityToolkit.pptx | PowerPoint Presentation]] (save as .pptx) - a presentation on using the ProximityToolkit.
November 01, 2010, at 10:22 PM by 136.159.18.20 -
Changed lines 80-81 from:
*[[[Attach:proximity-example-fungr.zip | Hello World Video Player]] that responds to distance and orientation to play a video.
to:
*[[Attach:proximity-example-fungr.zip | Hello World Video Player]] that responds to distance and orientation to play a video.
November 01, 2010, at 10:19 PM by 136.159.18.20 -
Changed lines 80-81 from:
to:
*[[[Attach:proximity-example-fungr.zip | Hello World Video Player]] that responds to distance and orientation to play a video.
Changed lines 43-44 from:
* [[Attach:ProximityToolkit-1.1.0.msi | ProximityToolkit-1.1.0.msi]] (Version 1.1.0 | Aug 26, 2010)
to:
* [[Attach:ProximityToolkit-1.2.1.msi | ProximityToolkit-1.2.1.msi]] (Version 1.2.1 | Sept 23, 2010)
Added lines 46-49:
* Version 1.2.1
** Includes support for WPF applications.
** Many bug fixes to the ProximityServer application.
** Includes sample content.
Added line 52:
** Support for Winforms graphical layout.
Added line 59:
* [[Attach:ProximityToolkit-1.1.0.msi | ProximityToolkit-1.1.0.msi]] (Version 1.1.0 | Aug 26, 2010)
Changed line 22 from:
* [[ProximityToolkitSubjects | Tracked Subjects]] - A list of standard subjects available in the lab for use.
to:
* [[ProximityToolkitSubjects | Tracked Subjects]] - A list of standard subjects available for use in the lab.
Added line 22:
* [[ProximityToolkitSubjects | Tracked Subjects]] - A list of standard subjects available in the lab for use.
Changed lines 21-22 from:
* [[ProximityToolkitEvents | Events]] - A discussion on how the toolkit events and monitors work hand in hand.
to:
* [[ProximityToolkitServer | The ProximityServer]] - Using the ProximityServer application.
* [[ProximityToolkitEvents | Client Events]] - A discussion on how the client-side
toolkit events and monitors work hand in hand.
Changed lines 30-47 from:
!!! 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
.
to:
!!! Demo Applications

The ProximityToolkit comes bundled with two demo applications that use the ''WhiteHat'' and ''Pencil'' subjects, on the ''SmartBoard'' display:
* '''ProximityPaint''' - A painting program that allows for color selection by looking and pointing; painting and erasing at various thicknesses by distance of the pencil
to the display; and zooming by distance of the hat to the display.
* '''ProximityFace''' - A fun application with a face
that reacts to the distance, direction, and motion of the hat. The pencil acts as a flashlight metaphor, demonstrating pointing and touching.
Deleted line 89:
* [[Attach:2010-09_ProximityToolkit.pptx | 2010/09/14 Proximity Toolkit Presentation]] (save as .pptx)
Changed lines 91-92 from:
* Under Construction
to:
* [[http://grouplab.cpsc.ucalgary.ca/proximitytoolkit | ProximityToolkit Reference]] - an MSDN style reference.
* [[Attach:2010-09_ProximityToolkit.pptx | 2010/09/14 Proximity Toolkit Presentation]] (save as .pptx) - a presentation on using the ProximityToolkit.
Added line 76:
Added line 84:
Added lines 93-96:

'''Papers / Videos'''
* Coming Soon
Changed lines 106-109 from:
>><<

'''Papers / Videos'''
* Coming Soon
to:
Changed lines 91-92 from:
to:
>><<
Changed lines 96-99 from:
*[[ProximityToolkitFutureWork | Rob's Future Work List]] - Suggestions for future Proximity Toolkit fixes and features.
to:
* [[ProximityToolkitFutureWork | Rob's Future Work List]] - Suggestions for future Proximity Toolkit fixes and features.

!!! Bugs
* [[ProximityToolkitBugs | Bug Tracking]] - An area to document bugs in the ProximityToolkit
.
Changed line 95 from:
*[[RobsFutureWorkList | Rob's Future Work List]] - Suggestions for future Proximity Toolkit fixes and features.
to:
*[[ProximityToolkitFutureWork | Rob's Future Work List]] - Suggestions for future Proximity Toolkit fixes and features.
Changed line 20 from:
* [[ProximityToolkitData | Data Hierarchy]] - An explanation of the data hierarchy, and how to work with it.
to:
* [[ProximityToolkitDataHierarchy | Data Hierarchy]] - An explanation of the data hierarchy, and how to work with it.
Changed line 19 from:
* [[ProximityToolkitCore | Core Concepts]] - Core concepts of the Proximity Toolkit.
to:
* [[ProximityToolkitCoreConcepts | Core Concepts]] - Core concepts of the Proximity Toolkit.
Changed lines 22-23 from:
to:
* [[ProximityToolkitCollisionDetection | Collision Detection]] - An explanation of the collision detection functionality built into the toolkit.
Deleted lines 46-78:
!!!! Data Hierarchy

The root of the data hierarchy is a '''ProximitySpace''' object, which contains information about the dimensions of the capture area, and establishes the 3D coordinate system.

The Proximity Space deals with 4 different concepts of presence, that are specializations of the '''PresenceBase''' class:
* '''TrackedPresence'''s (aka. Presences) - Detectable artifacts that can be changed or manipulated.
* '''DisplayPlane'''s - Rectangular areas that represent screens or monitors. Usually these are fixed in place, however the DisplayDecorator supports mobile displays on devices such as tablets or phones, which appear as sub-nodes of their TrackedPresence anchor.
* '''Volume'''s - Shapes that represent surfaces or solid objects such as furniture, or hollow regions of interest.
* '''CaptureDevice'''s - Spacial information about input sensors that may be required for Input Modules to represent their collected data in the common coordinate space.

PresencesObjects can contain any of the following data decorators (discussed in detail above), as specializations of the '''DecoratorBase''' class:
* '''LocationDecorator''' - An absolute position in 3D space that is representative of the whole presence.
* '''MotionDecorator''' - Details about movement in 3D space that is representative of the whole presence.
* '''OrientationDecorator''' - Details about where a presence is facing, and what way up.
* '''RotationDecorator''' - Details about the rotation of the presence.
* '''CollisionDecorator''' - Details about the physical volume of the presence (currently under development).
* '''MarkerDecorator''' - A set of detectable points that are subparts of the presence.
* '''PointerDecorator''' - A set of defined rays that point in directions of interest from the presence.
* '''DisplayDecorator''' - The details of a display that is attached to a presence (useful for phones/tablets).

The ViconInputModule extends the collection of possible decorators:
* '''PoseDecorator''' - The skeleton of a presence with movable parts, representing bones and joints.

TrackedPresences require decorators because their set of proximity information may vary depending on the capabilities of the input technology used. Fixed objects such as DisplayPlane, Volume, and CaptureDevice do not contain decorators because their set of properties are calibrated manually.

Each of the above PresenceBase and DecoratorBase specializations implement a common interface called '''IPresenceNode'''. These objects form a traversable data tree that goes from the ProximitySpace root, right down to the individual data properties of PresenceBase and DecoratorBase objects. The ''IPresenceNode.Parent'' property holds the parent node in the tree structure, while the ''IPresenceNode.Nodes'' structure holds the list of child nodes. Data for any subtree can be accessed by using an indexer on a node, and a dot-separated path string as follows:

''object data = Node["NodeName.NodeName"]''

OR, if a particular data type is expected:

''DataType data = Node.GetValue<DataType>("NodeName.NodeName")''
Deleted lines 46-85:
!!!! Core Concepts of Proximity Toolkit

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.
Added lines 18-22:
!!! Topics
* [[ProximityToolkitCore | Core Concepts]] - Core concepts of the Proximity Toolkit.
* [[ProximityToolkitData | Data Hierarchy]] - An explanation of the data hierarchy, and how to work with it.
* [[ProximityToolkitEvents | Events]] - A discussion on how the toolkit events and monitors work hand in hand.
Changed line 155 from:
* [[Attach:2010-09_ProximityToolkit.pptx | 2010/09/14 Proximity Toolkit Presentation]]
to:
* [[Attach:2010-09_ProximityToolkit.pptx | 2010/09/14 Proximity Toolkit Presentation]] (save as .pptx)
Changed line 155 from:
* [[2010-09_ProximityToolkit.pptx | 2010/09/14 Proximity Toolkit Presentation]]
to:
* [[Attach:2010-09_ProximityToolkit.pptx | 2010/09/14 Proximity Toolkit Presentation]]
Added line 155:
* [[2010-09_ProximityToolkit.pptx | 2010/09/14 Proximity Toolkit Presentation]]
Changed line 20 from:
* '''ViconInputModule''' - Based on the [[ViconToolkit | Vicon Toolkit]], this module gathers input from a Vicon motion tracking system. (Status: IN DEVELOPMENT)
to:
* '''ViconInputModule''' - Based on the [[ViconToolkit | Vicon Toolkit]], this module gathers input from a Vicon motion tracking system. (Status: COMPLETE)
Changed lines 162-163 from:
to:
>><<
Added lines 158-162:
[[#futurework]]
>>redbox<<
!!! Future Work
*[[RobsFutureWorkList | Rob's Future Work List]] - Suggestions for future Proximity Toolkit fixes and features.
Changed line 9 from:
Contents: [[#intro | Introduction]] | [[#download | Download and Installation]] | [[#recipes | Recipes, How-To's]] | [[#tutorials | Tutorials and Examples]] | [[#links | Links]]
to:
Contents: [[#intro | Introduction]] | [[#download | Download and Installation]] | [[#recipes | Recipes, How-To's]] | [[#tutorials | Tutorials and Examples]] | [[#links | Links]] | [[http://grouplab.cpsc.ucalgary.ca/proximitytoolkit | Reference]]
August 26, 2010, at 11:33 AM by 136.159.7.119 -
Changed lines 120-121 from:
* [[Attach:ProximityToolkit-1.0.0.msi | ProximityToolkit-1.0.0.msi]] (Version 1.0.0 | Aug 17, 2010)
to:
* [[Attach:ProximityToolkit-1.1.0.msi | ProximityToolkit-1.1.0.msi]] (Version 1.1.0 | Aug 26, 2010)
Added lines 123-124:
* Version 1.1.0
** MAJOR updates to client side API - you'll love it!
Added line 131:
* [[Attach:ProximityToolkit-1.0.0.msi | ProximityToolkit-1.0.0.msi]] (Version 1.0.0 | Aug 17, 2010)
August 17, 2010, at 04:58 PM by 136.159.7.119 -
Changed lines 107-114 from:
Each of the above PresenceBase and DecoratorBase specializations implement a common interface called '''IPresenceNode'''. These objects form a traversable data tree that goes from the ProximitySpace root, right down to the individual data properties of PresenceBase and DecoratorBase objects. The ''IPresenceNode.Parent'' property holds the parent node in the tree structure, while the ''IPresenceNode.Nodes'' structure holds the list of child nodes. Data for any subtree can be accessed by using an indexer on the root node, and a dot-separated path string as follows:

''IPresenceNode["NodeName.NodeName"]''

OR, if a particular datatype is expected:

''IPresenceNode.GetValue<DataType>("NodeName.NodeName")''
to:
Each of the above PresenceBase and DecoratorBase specializations implement a common interface called '''IPresenceNode'''. These objects form a traversable data tree that goes from the ProximitySpace root, right down to the individual data properties of PresenceBase and DecoratorBase objects. The ''IPresenceNode.Parent'' property holds the parent node in the tree structure, while the ''IPresenceNode.Nodes'' structure holds the list of child nodes. Data for any subtree can be accessed by using an indexer on a node, and a dot-separated path string as follows:

''object data = Node["NodeName.NodeName"]''

OR, if a particular data type is expected:

''DataType data = Node.GetValue<DataType>("NodeName.NodeName")''
August 17, 2010, at 04:53 PM by 136.159.7.119 -
Changed lines 32-35 from:
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 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.
to:
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.
Changed lines 40-41 from:
Relationship data is calculated by request only, and the ProximitySpace object handles Starting/Stopping of '''Monitors''' (desired relation information) and Adding/Removing '''Handlers''' (event callbacks when particular relation information changes). The ProximitySpace contains a default event callback for all updated Monitors which can be used to handle simple monitoring schemes, or act as a dispatcher for custom functions.
to:
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.
Changed lines 56-57 from:
'''Motion''' – provides measurements of Velocity and Acceleration in standard units (distance/second and distance/second2 respectively) in axes purely relative to the Presence (e.g. an accelerometer).
to:
'''Motion''' – provides measurements of Velocity and Acceleration in standard units (distance/second and distance/second2 respectively).
Changed lines 69-80 from:

The toolkit’s modular structure can also allow for custom decorators to be defined and applied to Presences. For instance
, the Vicon Input Module can detect proxemic information for subparts of the presence: markers, pointers, bones, and joints. Thus, the Vicon Input Module introduces a Marker Decorator, Pointer Decorator, and Pose Decorator.

'''Marker''' – represents a collection of individually locatable points within
a Presence.

'''Pointer''' – represents a feature of the Presence that can be used to indicate direction
.

'''Pose''' – represents the kinematic configuration of bones and joints within the Presence.

Furthermore, to handle movable devices with displays such as phones or tablets, the Vicon Input Module also provides a Display Decorator. 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.
to:
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.
Changed lines 84-85 from:
The root of the data hierarchy is the '''ProximitySpace''' class, which contains information about the dimensions of the capture area, and establishes the 3D coordinate system.
to:
The root of the data hierarchy is a '''ProximitySpace''' object, which contains information about the dimensions of the capture area, and establishes the 3D coordinate system.
Changed lines 87-89 from:
* '''PresenceObject'''s - Detectable artifacts that can be changed or manipulated.
* '''DisplayPlane'''s - Rectangular areas that represent screens or monitors. Usually these are fixed in place, however we are planning to support mobile displays on devices such as tablets or phones.
* '''Volume'''s - Shapes that represent solid objects such as furniture, or hollow areas
of interest.
to:
* '''TrackedPresence'''s (aka. Presences) - Detectable artifacts that can be changed or manipulated.
* '''DisplayPlane'''s - Rectangular areas that represent screens or monitors. Usually these are fixed in place, however the DisplayDecorator supports mobile displays on devices such as tablets or phones, which appear as sub-nodes of their TrackedPresence anchor.
* '''Volume'''s - Shapes that represent surfaces or solid objects such as furniture, or hollow regions
of interest.
Changed lines 98-102 from:
The ViconInputModule extends the collection of possible decorators to include indicators of internal structure:
* '''MarkerDecorator''' - A set of detectable points that are subparts of the presence .
* '''PointerDecorator''' - A set of defined rays that point in directions of interest from the
presence .
* '''PoseDecorator''' - The skeleton of a presence with movable parts, representing bones and joints
.
to:
* '''MarkerDecorator''' - A set of detectable points that are subparts of the presence.
* '''PointerDecorator''' - A set of defined rays that point in directions of interest from the presence.
Changed lines 102-103 from:
PresenceObjects require decorators because their set of proximity information may vary depending on the capabilities of the input technology used. Fixed objects such as DisplayPlane, Volume, and CaptureDevice do not contain decorators because their set of properties are already known, and assumed not to change regularly.
to:
The ViconInputModule extends the collection of possible decorators:
* '''PoseDecorator''' - The skeleton of a presence with movable parts, representing bones and joints.

TrackedPresences require decorators because their set of proximity information may vary depending on the capabilities of the input technology used. Fixed objects such as DisplayPlane, Volume, and CaptureDevice do not contain decorators because their set of properties are calibrated manually
.
Added lines 111-114:
OR, if a particular datatype is expected:

''IPresenceNode.GetValue<DataType>("NodeName.NodeName")''
August 17, 2010, at 04:12 PM by 136.159.7.119 -
Changed lines 115-116 from:
* [[Attach:ProximityToolkit1.0.1a-Setup.msi | ProximityToolkit1.0.1a-Setup.msi]] (Version 1.0.1a | June 5, 2010)
to:
* [[Attach:ProximityToolkit-1.0.0.msi | ProximityToolkit-1.0.0.msi]] (Version 1.0.0 | Aug 17, 2010)
Added lines 118-119:
* Version 1.0.0
** First official release! Please inform us of bugs.
Added line 124:
* [[Attach:ProximityToolkit1.0.1a-Setup.msi | ProximityToolkit1.0.1a-Setup.msi ]] (Version 1.0.0a | June 2, 2010)
July 22, 2010, at 09:18 PM by 136.159.7.119 -
Added lines 42-80:
!!!! Core Concepts of Proximity Toolkit

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) in axes purely relative to the Presence (e.g. an accelerometer).

'''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.


The toolkit’s modular structure can also allow for custom decorators to be defined and applied to Presences. For instance, the Vicon Input Module can detect proxemic information for subparts of the presence: markers, pointers, bones, and joints. Thus, the Vicon Input Module introduces a Marker Decorator, Pointer Decorator, and Pose Decorator.

'''Marker''' – represents a collection of individually locatable points within a Presence.

'''Pointer''' – represents a feature of the Presence that can be used to indicate direction.

'''Pose''' – represents the kinematic configuration of bones and joints within the Presence.

Furthermore, to handle movable devices with displays such as phones or tablets, the Vicon Input Module also provides a Display Decorator. 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.
Changed lines 91-106 from:
Features of presences are represented by the following, which are PresenceBase specializations in themselves:
*
'''PresenceMarker''' - a detectable point in 3D space that in itself can possess Location and Motion information.
* '''PresencePointer''' - a ray that represents a direction of interest emitted from a part of an object.

PresencesObjects can contain any of the following data decorators, as specializations of the '''DecoratorBase''' class:
* '''Location''' - An absolute position in 3D space that is representative of
the whole presence.
* '''Motion''' - Details about movement in 3D space that is representative of the whole presence.
*
'''Direction''' - Details about where an object is facing.
* '''Orientation''' - Details about the position of the object, compared to its "default" orientation.
* '''Rotation''' - Details about
the rotation of the object.
* '''Collision''' - Details about the physical volume of the object.
* '''Markers''' - A set of detectable points that are subparts of the object.
* '''Pointers''' - A set of defined rays that point in directions
of interest from the object.

PresenceObjects require decorators because their set
of proximity information may vary depending on the capabilities of the input technology used. Fixed objects such as DisplayPlane, Volume, and CaptureDevice do not contain decorators because their set of properties are already known at compile-time.
to:
PresencesObjects can contain any of the following data decorators (discussed in detail above), as specializations of the '''DecoratorBase''' class:
* '''LocationDecorator''' - An absolute position in 3D space that is representative of the whole presence
.
* '''MotionDecorator''' - Details about movement in 3D space that is representative of the whole presence.
* '''OrientationDecorator''' - Details about where a presence is facing, and what way up.
*
'''RotationDecorator''' - Details about the rotation of the presence.
* '''CollisionDecorator''' - Details about
the physical volume of the presence (currently under development).

The ViconInputModule extends the collection of possible decorators to include indicators of internal structure:
*
'''MarkerDecorator''' - A set of detectable points that are subparts of the presence .
* '''PointerDecorator''' - A set of defined rays that point in directions of interest from
the presence .
* '''PoseDecorator''' - The skeleton of a presence with movable parts, representing bones and joints.
* '''DisplayDecorator''' - The details of a display that is attached to a presence (useful for phones/tablets).

PresenceObjects require decorators because their set
of proximity information may vary depending on the capabilities of the input technology used. Fixed objects such as DisplayPlane, Volume, and CaptureDevice do not contain decorators because their set of properties are already known, and assumed not to change regularly.
June 07, 2010, at 02:17 PM by 136.159.7.119 -
Added line 93:
* [[ModuleAPI | Input Module API]] - the API for implementing a custom input module.
June 05, 2010, at 07:37 PM by 207.251.46.30 -
Added lines 79-82:
!!!Bug Fixes
* Version 1.0.1a
** Several fixes to calibration bugs
June 05, 2010, at 07:33 PM by 207.251.46.30 -
Changed lines 77-78 from:
* [[Attach:ProximityToolkit1.0.1a-Setup.msi | ProximityToolkit1.0.1a-Setup.msi ]] (Version 1.0.1a | June 5, 2010)
to:
* [[Attach:ProximityToolkit1.0.1a-Setup.msi | ProximityToolkit1.0.1a-Setup.msi]] (Version 1.0.1a | June 5, 2010)
June 05, 2010, at 07:30 PM by 207.251.46.30 -
Added lines 77-79:
* [[Attach:ProximityToolkit1.0.1a-Setup.msi | ProximityToolkit1.0.1a-Setup.msi ]] (Version 1.0.1a | June 5, 2010)

!!!Archived Versions
Changed lines 82-85 from:
!!!Known Issues in Version 1.0.0a
* Module context menu items do not work.
* Collision detection not accurate.
* Display calibration wizards not working.
to:
June 02, 2010, at 02:40 PM by 136.159.7.119 -
Added line 82:
* Display calibration wizards not working.
June 02, 2010, at 01:05 PM by 136.159.7.119 -
Added lines 78-81:

!!!Known Issues in Version 1.0.0a
* Module context menu items do not work.
* Collision detection not accurate.
June 02, 2010, at 01:01 PM by 136.159.7.119 -
Changed line 77 from:
* [[ ProximityToolkit1.0.0a-Setup.msi | ProximityToolkit1.0.0a-Setup.msi ]] (Version 1.0.0a | June 2, 2010)
to:
* [[Attach:ProximityToolkit1.0.0a-Setup.msi | ProximityToolkit1.0.0a-Setup.msi ]] (Version 1.0.0a | June 2, 2010)
June 02, 2010, at 12:57 PM by 136.159.7.119 -
Changed line 77 from:
* [[ ProximityToolkit1-0a.msi | Proximity Toolkit ]] - Version 1.0a (June 2, 2010)
to:
* [[ ProximityToolkit1.0.0a-Setup.msi | ProximityToolkit1.0.0a-Setup.msi ]] (Version 1.0.0a | June 2, 2010)
June 02, 2010, at 12:54 PM by 136.159.7.119 -
Changed line 77 from:
* Public release coming soon.
to:
* [[ ProximityToolkit1-0a.msi | Proximity Toolkit ]] - Version 1.0a (June 2, 2010)
May 25, 2010, at 12:10 PM by 136.159.7.119 -
Changed line 83 from:
* Under Construction
to:
* [[Startup | General Startup Procedure]] - the procedure to follow to prepare the Proximity Server for an interaction session.
May 21, 2010, at 12:45 PM by 174.0.52.43 -
Changed line 90 from:
* Under Construction
to:
*[[FontResizer | Text Font Resizer]] is an introductory example shows you how to construct a basic WPF program using the tool kit.
May 19, 2010, at 04:19 PM by 136.159.7.119 -
Added lines 18-23:
!!! Modules

* '''ViconInputModule''' - Based on the [[ViconToolkit | Vicon Toolkit]], this module gathers input from a Vicon motion tracking system. (Status: IN DEVELOPMENT)
* '''ARToolkitModule''' - Based on the ARToolkit, this module gathers identity and position data from 2D markers as seen by a webcam. (Status: NOT STARTED)
* '''PhidgetsModule''' - Uses the [[Phidgets-NET | Phidgets .NET]] API to gather information from any number of sensors. (Status: NOT STARTED)
May 19, 2010, at 04:14 PM by 136.159.7.119 -
Changed line 13 from:
!!! Introduction
to:
!! Introduction
Changed lines 18-19 from:
!!!!Toolkit Structure
to:
!!! Toolkit Structure
Changed lines 22-23 from:
!!!!! Proximity Server (Application)
to:
!!!! Proximity Server (Application)
Changed lines 30-31 from:
!!!!! Proximity Toolkit (Library)
to:
!!!! Proximity Toolkit (Library)
Changed lines 36-37 from:
!!!!! Data Hierarchy
to:
!!!! Data Hierarchy
May 19, 2010, at 04:13 PM by 136.159.7.119 -
Changed line 9 from:
Contents: [[#download | Download and Installation]] | [[#recipes | Recipes, How-To's]] | [[#tutorials | Tutorials and Examples]] | [[#links | Links]]
to:
Contents: [[#intro | Introduction]] | [[#download | Download and Installation]] | [[#recipes | Recipes, How-To's]] | [[#tutorials | Tutorials and Examples]] | [[#links | Links]]
Added line 13:
!!! Introduction
Changed lines 18-19 from:
!!Toolkit Structure
to:
!!!!Toolkit Structure
Changed lines 22-23 from:
!!! Proximity Server (Application)
to:
!!!!! Proximity Server (Application)
Changed lines 30-31 from:
!!! Proximity Toolkit (Library)
to:
!!!!! Proximity Toolkit (Library)
Changed lines 36-37 from:
!!! Data Hierarchy
to:
!!!!! Data Hierarchy
May 19, 2010, at 04:12 PM by 136.159.7.119 -
Added line 9:
Contents: [[#download | Download and Installation]] | [[#recipes | Recipes, How-To's]] | [[#tutorials | Tutorials and Examples]] | [[#links | Links]]
Changed lines 11-13 from:
Contents: [[#download | Download and Installation]] | [[#recipes | Recipes, How-To's]] | [[#tutorials | Tutorials and Examples]] | [[#links | Links]]
----
to:
May 19, 2010, at 04:12 PM by 136.159.7.119 -
Added lines 1-13:
%define=box padding-left=1em padding-right=1em margin='3px 3px 0'%
%define=yellowbox box bgcolor=#fdfaea border='1px solid #ffad80'%
%define=redbox box bgcolor=#fff3f3 border='1px solid #ffc9c9'%
%define=bluebox box bgcolor=#f4fbff border='1px solid #a1cae6'%
%define=skybox box bgcolor=#f8fcff border='1px solid #aaaaaa'%
%define=greybox box bgcolor=#fbfbfb border='1px solid #aaaaaa'%
%define=greenbox box bgcolor=#e6f3e5 border='1px solid #8fd586'%
%define=whitebox box bgcolor=#ffffff border='1px solid #999999'%
----
Contents: [[#download | Download and Installation]] | [[#recipes | Recipes, How-To's]] | [[#tutorials | Tutorials and Examples]] | [[#links | Links]]
----

[[#intro]]
Changed lines 64-95 from:
''IPresenceNode["NodeName.NodeName"]''
to:
''IPresenceNode["NodeName.NodeName"]''

----

[[#download]]
>>greenbox<<
!!! Download and Installation
* Public release coming soon.
>><<

[[#recipes]]
>>yellowbox<<
!!! Recipes and How-To's
* Under Construction
>><<


[[#tutorials]]
>>bluebox<<
!!! Tutorials and Examples
* Under Construction
>><<

[[#links]]
>>greybox<<
!!! Links
'''Documentation/Code'''
* Under Construction

'''Papers / Videos'''
* Coming Soon
>><<
May 19, 2010, at 04:06 PM by 136.159.7.119 -
Changed lines 9-10 from:
!!! Proximity Server
to:
!!! Proximity Server (Application)
Changed lines 17-18 from:
!!! Proximity Client
to:
!!! Proximity Toolkit (Library)
May 19, 2010, at 04:05 PM by 136.159.7.119 -
Changed lines 49-51 from:
Each of the above PresenceBase and DecoratorBase specializations implement a common interface called '''IPresenceNode'''. These objects form a traversable data tree that goes from the ProximitySpace root, right down to the individual data properties of PresenceBase and DecoratorBase objects. The ''IPresenceNode.Parent'' property holds the parent node in the tree structure, while the ''IPresenceNode.Nodes'' structure holds the list of child nodes. Data for any subtree can be accessed by using an indexer on the root node, and a dot-separated path string as follows: ''IPresenceNode["NodeName.NodeName"]''
to:
Each of the above PresenceBase and DecoratorBase specializations implement a common interface called '''IPresenceNode'''. These objects form a traversable data tree that goes from the ProximitySpace root, right down to the individual data properties of PresenceBase and DecoratorBase objects. The ''IPresenceNode.Parent'' property holds the parent node in the tree structure, while the ''IPresenceNode.Nodes'' structure holds the list of child nodes. Data for any subtree can be accessed by using an indexer on the root node, and a dot-separated path string as follows:

''IPresenceNode["NodeName.NodeName"]''
May 19, 2010, at 04:05 PM by 136.159.7.119 -
Changed line 49 from:
Each of the above PresenceBase and DecoratorBase specializations implement a common interface called '''IPresenceNode'''. These objects form a traversable data tree that goes from the ProximitySpace root, right down to the individual data properties of PresenceBase and DecoratorBase objects. The ''IPresenceNode.Parent'' property holds the parent node in the tree structure, while the ''IPresenceNode.Nodes'' structure holds the list of child nodes. Data for any subtree can be accessed by using an indexer on the root node, and a dot-separated path string.
to:
Each of the above PresenceBase and DecoratorBase specializations implement a common interface called '''IPresenceNode'''. These objects form a traversable data tree that goes from the ProximitySpace root, right down to the individual data properties of PresenceBase and DecoratorBase objects. The ''IPresenceNode.Parent'' property holds the parent node in the tree structure, while the ''IPresenceNode.Nodes'' structure holds the list of child nodes. Data for any subtree can be accessed by using an indexer on the root node, and a dot-separated path string as follows: ''IPresenceNode["NodeName.NodeName"]''
May 19, 2010, at 03:23 PM by 136.159.7.119 -
Changed lines 38-46 from:
* ''Location'' - An absolute position in 3D space that is representative of the whole presence.
* ''Motion'' - Details about movement in 3D space that is representative of the whole presence.
* ''Direction'' - Details about where an object is facing.
* ''Orientation'' - Details about the position of the object, compared to its "default" orientation.
* ''Rotation'' - Details about the rotation of the object.
* ''Collision'' - Details about the physical volume of the object.
* ''Markers'' - A set of detectable points that are subparts of the object.
* ''Pointers'' - A set of defined rays that point in directions of interest from the object.
to:
* '''Location''' - An absolute position in 3D space that is representative of the whole presence.
* '''Motion''' - Details about movement in 3D space that is representative of the whole presence.
* '''Direction''' - Details about where an object is facing.
* '''Orientation''' - Details about the position of the object, compared to its "default" orientation.
* '''Rotation''' - Details about the rotation of the object.
* '''Collision''' - Details about the physical volume of the object.
* '''Markers''' - A set of detectable points that are subparts of the object.
* '''Pointers''' - A set of defined rays that point in directions of interest from the object.
May 19, 2010, at 03:18 PM by 136.159.7.119 -
Changed lines 19-22 from:
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 handles network communication and updates, as well as the calculation of relationship data between objects.

Relationship data is calculated by request only
.
to:
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, and the ProximitySpace object handles Starting/Stopping of '''Monitors''' (desired relation information) and Adding/Removing '''Handlers''' (event callbacks when particular relation information changes). The ProximitySpace contains a default event callback for all updated Monitors which can be used to handle simple monitoring schemes, or act as a dispatcher for custom functions
.
May 19, 2010, at 03:13 PM by 136.159.7.119 -
Changed lines 13-16 from:
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 ProximityInputModule, the module will be instantiated and hooked into the server's input polling and processing pipeline.

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. 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.
to:
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 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.
May 19, 2010, at 03:11 PM by 136.159.7.119 -
Changed lines 15-16 from:
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.
to:
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. 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.
May 19, 2010, at 03:06 PM by 136.159.7.119 -
Changed line 49 from:
Each of the above PresenceBase and DecoratorBase specializations implement a common interface called '''IPresenceNode'''. These objects form a traversable data tree that goes from the ProximitySpace root, right down to the individual data properties of PresenceBase and DecoratorBase objects. The ''IPresenceNode.Parent'' property holds the parent node in the tree structure, while the ''IPresenceNode.Nodes'' structure holds the list of child nodes.
to:
Each of the above PresenceBase and DecoratorBase specializations implement a common interface called '''IPresenceNode'''. These objects form a traversable data tree that goes from the ProximitySpace root, right down to the individual data properties of PresenceBase and DecoratorBase objects. The ''IPresenceNode.Parent'' property holds the parent node in the tree structure, while the ''IPresenceNode.Nodes'' structure holds the list of child nodes. Data for any subtree can be accessed by using an indexer on the root node, and a dot-separated path string.
May 19, 2010, at 03:03 PM by 136.159.7.119 -
Changed lines 11-12 from:
The Proximity Server is a pre-built application that is responsible for collecting and processing raw data from 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 files that match the pattern "*Module.dll". If the .dll file contains a definition for a ProximityInputModule, the module will be instantiated and hooked into the server's input polling and processing pipeline.
to:
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 ProximityInputModule, the module will be instantiated and hooked into the server's input polling and processing pipeline.

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
.
Changed lines 19-49 from:
In most cases, application developers will use the client to connect to the server program on their local machine, or perhaps across a network.
to:
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 handles network communication and updates, as well as the calculation of relationship data between objects.

Relationship data is calculated by request only.

!!! Data Hierarchy

The root of the data hierarchy is the '''ProximitySpace''' class, which contains information about the dimensions of the capture area, and establishes the 3D coordinate system.

The Proximity Space deals with 4 different concepts of presence, that are specializations of the '''PresenceBase''' class:
* '''PresenceObject'''s - Detectable artifacts that can be changed or manipulated.
* '''DisplayPlane'''s - Rectangular areas that represent screens or monitors. Usually these are fixed in place, however we are planning to support mobile displays on devices such as tablets or phones.
* '''Volume'''s - Shapes that represent solid objects such as furniture, or hollow areas of interest.
* '''CaptureDevice'''s - Spacial information about input sensors that may be required for Input Modules to represent their collected data in the common coordinate space.

Features of presences are represented by the following, which are PresenceBase specializations in themselves:
* '''PresenceMarker''' - a detectable point in 3D space that in itself can possess Location and Motion information.
* '''PresencePointer''' - a ray that represents a direction of interest emitted from a part of an object.

PresencesObjects can contain any of the following data decorators, as specializations of the '''DecoratorBase''' class:
* ''Location'' - An absolute position in 3D space that is representative of the whole presence.
* ''Motion'' - Details about movement in 3D space that is representative of the whole presence.
* ''Direction'' - Details about where an object is facing.
* ''Orientation'' - Details about the position of the object, compared to its "default" orientation.
* ''Rotation'' - Details about the rotation of the object.
* ''Collision'' - Details about the physical volume of the object.
* ''Markers'' - A set of detectable points that are subparts of the object.
* ''Pointers'' - A set of defined rays that point in directions of interest from the object.

PresenceObjects require decorators because their set of proximity information may vary depending on the capabilities of the input technology used. Fixed objects such as DisplayPlane, Volume, and CaptureDevice do not contain decorators because their set of properties are already known at compile-time.

Each of the above PresenceBase and DecoratorBase specializations implement a common interface called '''IPresenceNode'''. These objects form a traversable data tree that goes from the ProximitySpace root, right down to the individual data properties of PresenceBase and DecoratorBase objects. The ''IPresenceNode.Parent'' property holds the parent node in the tree structure, while the ''IPresenceNode.Nodes'' structure holds the list of child nodes.
May 19, 2010, at 01:37 PM by 136.159.7.119 -
Changed lines 3-15 from:
Currently, our primary source of input is a Vicon motion tracking system, which provides higly accurate tracking on objects that are tagged with a combination of several infrared-reflective markers. Our plans are to expand the toolkit to include other input sources such as the ARToolkit (which tracks identity and position of 2D markers from webcam images) and Phidgets (which use low-level hardware devices and sensors to collect input).
to:
Currently, our primary source of input is a Vicon motion tracking system, which provides higly accurate tracking on objects that are tagged with a combination of several infrared-reflective markers. Our plans are to expand the toolkit to include other input sources such as the ARToolkit (which tracks identity and position of 2D markers from webcam images) and Phidgets (which use low-level hardware devices and sensors to collect basic input).

!!Toolkit Structure

The Proximity Toolkit uses a client-server model.

!!! Proximity Server

The Proximity Server is a pre-built application that is responsible for collecting and processing raw data from 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 files that match the pattern "*Module.dll". If the .dll file contains a definition for a ProximityInputModule, the module will be instantiated and hooked into the server's input polling and processing pipeline.

!!! Proximity Client

In most cases, application developers will use the client to connect to the server program on their local machine, or perhaps across a network.
May 19, 2010, at 01:23 PM by 136.159.7.119 -
Deleted lines 0-1:
!Proximity Toolkit
May 19, 2010, at 01:23 PM by 136.159.7.119 -
Added lines 1-5:
!Proximity Toolkit

The Proximity Toolkit is a catalyst for developing applications that make use of spatial information, and relations between objects in space. The toolkit is meant to deliver proximity data to applications during runtime which can be utilized as program input. It is designed to collect input from a number of potential input sources, then fuse the raw data into a set of generalized high-level presence objects that hide low-level implementation details.

Currently, our primary source of input is a Vicon motion tracking system, which provides higly accurate tracking on objects that are tagged with a combination of several infrared-reflective markers. Our plans are to expand the toolkit to include other input sources such as the ARToolkit (which tracks identity and position of 2D markers from webcam images) and Phidgets (which use low-level hardware devices and sensors to collect input).