ARCS/en

Un article de Wiki-evr@.

< ARCS(Différences entre les versions)

Version actuelle

Vers la version française

A view of the graphical editor.

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.

ARCS has now its own website.

[modifier] Publications

J.Y. Didier, S. Otmane, M. Mallem - A Component Model for Augmented/Mixed Reality Applications with Reconfigurable Data-flow

8th International Conference on Virtual Reality (VRIC 2006) pp. 243-252, Laval (France), April 26-28, 2006

Pdf Bibtex

Récupérée de « http://evra.ibisc.univ-evry.fr/index.php/ARCS/en »

 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 ==
+[http://arcs.ibisc.univ-evry.fr ARCS has now its own website.]
+<!--== Motivations ==
 During the last years, AR (Augmented Reality) community
 has proven the need of an infrastructure. Almost
 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
+used in user interfaces API, reaches other scopes
-of specific programming. Some libraries are implementing
+of programming. Some libraries are implementing
 it, for example: QT [http://www.trolltech.com ],
 libsigc++ [http://libsigc.sourceforge.net] derived from
 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
+at runtime and are managed.
-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.
-==== Component representation ====
+==== Component representation ====-->
-[[Image:ARCS_component.png|right|thumb|ARCS Component representation]]
+<!--[[Image:ARCS_component.png|right|thumb|ARCS Component representation]]--><!--
 A component in ARCS is an entity
 or object able to export by itself its interface which is
 ==== Component Initializations ====
+--><!--[[Image:ARCS_Preconnexion.png|thumb|250px|Pre-connexion initialization. Since components are not connected, initializations cannot propagate]]-->
+<!--[[Image:ARCS_Postconnexion.png|thumb|250px|Post-connexion initialization. When components are connected, if a slot triggers a signal, then the initialization may propagate through components]]-->
+<!--
 Components initializations are performed through
-slots. However, these slots must meet a few requirements.
+slots with only one parameter which to a list of simple types such as
-They must have only one parameter and this
-parameter belongs to a list of simple types such as
 strings, numerical values and other components.
-Further, we will establish a distinction between two
+We establish a distinction between two
 kinds of initializations depending on when they’re triggered.
 Indeed, a slot call can also trigger a signal that
 belongs to the same component; this last one may call
 another slot if a signal/slot connection is established
-between them. So, we have Pre-connection initializations
+between them. So, we have ''Pre-connection initializations''
 that are performed before the component is
 connected with others and we have a second category
-we call post-connection initialization that are triggered
+we call ''post-connection initialization'' that are triggered
 after the component is connected to other ones. This
 second one allows propagating initializations through
 connections.
 Since a component can be connected to other components,
-we will see the different solutions we have to
+we will see how they communicate to each other.
-connect components.
+=== Compositions of components ===
+An explicit composition let us know exactly how components are connected.
+It is performed by connecting signals to slots.
+==== The sheet concept ====-->
+<!--[[Image:ARCS_sheet.png|right|350px|thumb]]-->
+<!--We introduce here the concept
+of sheet. In a component based framework, an application
+could be seen as a set of components working (or
+more properly communicating) together. We choose
+to name this set a “sheet”.
+A sheet is storing components initialization and
+components signal/slots connections.
-=== Compositions of components ===
+==== Macro-blocks ====
-==== The sheet, an explicit composition ====
+A sheet can also be used to represent a subset of components
-[[Image:ARCS_sheet.png|right|350px|thumb]]
+working together. They will be called macroblocks.
+They are defined by global slots and
+signals to which classical components of our system
+can connect and interact. These global inputs/outputs
+are mapped to internal components of the macroblock.
+==== Extensions of composition mechanism ====
+We will introduce two more mechanisms, the first is
+consisting in using a state machine and the second is
+dedicated to components life-cycle management.
-==== Initialisations of components ====
+===== Adding a statemachine =====
+Indeed, a sheet reflects a state of an application.
+An application could be seen as a stack of sheets. We
+then need a mechanism to switch between sheets: its core is a statemachine.
-==== Other composition mechanism ====
+A state machine
+is, in our case, composed of states and transitions.
+The transitions are described by an initial state,
+a token and a final state.
+Sheets are modified to send tokens to the statemachine
+relying on one specific component for it.
+Each token sent to the state machine
+can make it switch to another application state
+that will be represented by another sheet.
+The new
+state can be a terminal state that will shutdown components.
+If we suppose a sheet (current sheet) is active and
+that the state machine has received an identified token
+triggering a transition, the sheet switch mechanism
+will follow these steps:
+# ''Disconnections:'' each signal/slot connection of the current sheet is destroyed. All components specifically instantiated for the current sheet are destroyed. All components communications are stopped,
+# ''Change of current sheet:'' the final state of the triggered transition becomes the current sheet. Each object that needs to be specifically set up for the sheet is instantiated,
+# ''Pre-connection initializations:'' before connecting signal/slot couples of the current sheet, components can be initialized separately,
+# ''Connections:'' each signal/slot connection described in the current sheet is activated. New communication links between components are established,
+# ''Post-connection initializations:'' reserved to initializations that propagate through different components when they’re connected to each other.
-=== Extending the sheet capabilities ===
+This described mechanism allows us to change the
+data path between components. We then have a reconfigurable
+data-flow. At the same time, life-cycle component management during the application run time is introduced
+in steps 1 and 2.-->
 == Publications ==
 {{bibtex|Didier06}}

ARCS/en

Un article de Wiki-evr@.

Version actuelle

[modifier] Publications

Affichages

Outils personnels

Navigation

Rechercher

Boîte à outils