ARCS/en
Un article de Wiki-evr@.
| Version du 20 juillet 2006 à 10:53 (modifier) Gi (Discuter | Contributions) (→Why programming with components ?) ← Différence précédente |
Version du 20 juillet 2006 à 13:07 (modifier) (défaire) Gi (Discuter | Contributions) Différence suivante → |
||
| Ligne 4 : | Ligne 4 : | ||
| The core of the framework is a general purpose component system cutomized to meet the requirements of augmented reality applications (mostly real-time constraints). A set of components is developped on top of this system for augmented reality applications. | The core of the framework is a general purpose component system cutomized to meet the requirements of augmented reality applications (mostly real-time constraints). A set of components is developped on top of this system for augmented reality applications. | ||
| - | == | + | == Motivations == |
| + | During the last years, AR (Augmented Reality) community | ||
| + | has proven the need of an infrastructure. Almost | ||
| + | 30 different projects of framework have been developed | ||
| + | for AR {{refa|Endres05}}. | ||
| + | |||
| + | Amongst these projects, the most remarkable ones are : | ||
| + | * [http://studierstube.icg.tu-graz.ac.at Studierstube], one of the oldest project relying on a ditributed scenegraph, | ||
| + | * [http://www.tinmith.net Tinmith], which is oriented for developpers, | ||
| + | * [http://ar.in.tum.de/Chair/ProjectDwarf Dwarf], developped for distributed augmented reality services, | ||
| + | * [http://www.amire.net AMIRE], which is the closest architecture to ARCS. | ||
| + | |||
| + | Our choice | ||
| + | is to develop or rely on a component system | ||
| + | that meets several requirements such as portability, a | ||
| + | variable granularity, some scalability, and a high level | ||
| + | of abstraction for end-users. As we will see, we will | ||
| + | introduce component life-cycle management mechanisms | ||
| + | in ours application developed with our framework. | ||
| + | We will also combined it with with a system | ||
| + | allowing on-line reconfiguration of data-flow. | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | == The ARCS Core == | ||
| === Components === | === Components === | ||
| According to Szyperski’s definition {{refa|Szyperski02}}, “A component | According to Szyperski’s definition {{refa|Szyperski02}}, “A component | ||
| Ligne 21 : | Ligne 46 : | ||
| we use, which is based on the signal/slot paradigm. | we use, which is based on the signal/slot paradigm. | ||
| - | === Signal/slots === | + | === Compositions of components === |
| + | === Underlying concept : the Signal/slots paradigm === | ||
| Our solution is based on the signal/slot communication | Our solution is based on the signal/slot communication | ||
| model between components. This paradigm, mainly | model between components. This paradigm, mainly | ||
| Ligne 42 : | Ligne 68 : | ||
| regard to the lifetimes of all objects involved. | regard to the lifetimes of all objects involved. | ||
| - | === Why programming with components ? === | ||
| - | During the last years, AR (Augmented Reality) community | ||
| - | has proven the need of an infrastructure. Almost | ||
| - | 30 different projects of framework have been developed | ||
| - | for AR {{refa|Endres05}}. | ||
| - | |||
| - | Amongst these projects, the most remarkable ones are : | ||
| - | * [http://studierstube.icg.tu-graz.ac.at Studierstube], one of the oldest project relying on a ditributed scenegraph, | ||
| - | * [http://www.tinmith.net Tinmith], which is oriented for developpers, | ||
| - | * [http://ar.in.tum.de/Chair/ProjectDwarf Dwarf], developped for distributed augmented reality services, | ||
| - | * [http://www.amire.net AMIRE], which is the closest architecture to ARCS. | ||
| - | |||
| - | Our choice | ||
| - | is to develop or rely on a component system | ||
| - | that meets several requirements such as portability, a | ||
| - | variable granularity, some scalability, and a high level | ||
| - | of abstraction for end-users. As we will see, we will | ||
| - | introduce component life-cycle management mechanisms | ||
| - | in ours application developed with our framework. | ||
| - | We will also combined it with with a system | ||
| - | allowing on-line reconfiguration of data-flow. | ||
| - | |||
| - | == The ARCS Core == | ||
| - | |||
| - | === Components === | ||
| - | |||
| - | === Compositions of components === | ||
| ==== The sheet, an explicit composition ==== | ==== The sheet, an explicit composition ==== | ||
Version du 20 juillet 2006 à 13:07
ARCS (for Augmented Reality Component System) is a framework dedicated to the design of augmented reality applications. The core of the framework is a general purpose component system cutomized to meet the requirements of augmented reality applications (mostly real-time constraints). A set of components is developped on top of this system for augmented reality applications.
Sommaire |
Motivations
During the last years, AR (Augmented Reality) community has proven the need of an infrastructure. Almost 30 different projects of framework have been developed for AR [Endres05].
Amongst these projects, the most remarkable ones are :
- Studierstube, one of the oldest project relying on a ditributed scenegraph,
- Tinmith, which is oriented for developpers,
- Dwarf, developped for distributed augmented reality services,
- AMIRE, which is the closest architecture to ARCS.
Our choice is to develop or rely on a component system that meets several requirements such as portability, a variable granularity, some scalability, and a high level of abstraction for end-users. As we will see, we will introduce component life-cycle management mechanisms in ours application developed with our framework. We will also combined it with with a system allowing on-line reconfiguration of data-flow.
The ARCS Core
Components
According to Szyperski’s definition [Szyperski02], “A component is a coherent package of software that can be independently developed and delivered as a unit, and that offers interfaces by which it can be connected, unchanged, with other components to compose a larger system”.
It means that, the way components will communicate with each other should be described, how they’re implemented, how they’re initialized and how we can use them to build applications.
Before detailing our components, we should introduce the main communication mechanism we use, which is based on the signal/slot paradigm.
Compositions of components
Underlying concept : the Signal/slots paradigm
Our solution is based on the signal/slot communication model between components. This paradigm, mainly used in user interfaces API, tends to reach other scopes of specific programming. Some libraries are implementing it, for example: QT [1], libsigc++ [2] derived from GTK+, sigslot [3] and boost [4]. Signals represent callbacks with multiple targets. Signals are connected to some set of slots, which are callback receivers. They are triggered when the signal is ”emitted”. Signals and slots can be connected and disconnected dynamically at runtime and are managed. That is to say, connections are tracked by objects owning signals and slots. They’re able to automatically disconnect signal/slot connections when one of the object involved in communication is destroyed. This allows the user to make signal/slot connections without expending a great effort to manage the lifetimes of those connections with regard to the lifetimes of all objects involved.
The sheet, an explicit composition
Initialisations of components
Other composition mechanism
Extending the sheet capabilities
Publications
J.Y. Didier, S. Otmane, M. Mallem - A Component Model for Augmented/Mixed Reality Applications with Reconfigurable Data-flow
Pdf