ARCS/en
Un article de Wiki-evr@.
< ARCS(Différences entre les versions)
| Version du 24 juillet 2006 à 11:41 (modifier) Gi (Discuter | Contributions) (→Component Initializations) ← Différence précédente |
Version actuelle (17 novembre 2011 à 22:19) (modifier) (défaire) Gi (Discuter | Contributions) |
||
| (2 révisions intermédiaires masquées) | |||
| 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 == | + | [http://arcs.ibisc.univ-evry.fr ARCS has now its own website.] |
| + | |||
| + | |||
| + | <!--== Motivations == | ||
| During the last years, AR (Augmented Reality) community | During the last years, AR (Augmented Reality) community | ||
| has proven the need of an infrastructure. Almost | has proven the need of an infrastructure. Almost | ||
| Ligne 57 : | Ligne 60 : | ||
| at runtime and are managed. | at runtime and are managed. | ||
| - | ==== 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 | A component in ARCS is an entity | ||
| or object able to export by itself its interface which is | or object able to export by itself its interface which is | ||
| Ligne 79 : | Ligne 82 : | ||
| ==== Component Initializations ==== | ==== Component Initializations ==== | ||
| - | [[Image:ARCS_Preconnexion.png|thumb|250px|Pre-connexion initialization. Since components are not connected, initializations cannot propagate]] | + | --><!--[[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]] | + | <!--[[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 | Components initializations are performed through | ||
| slots with only one parameter which to a list of simple types such as | slots with only one parameter which to a list of simple types such as | ||
| Ligne 101 : | Ligne 104 : | ||
| Since a component can be connected to other components, | Since a component can be connected to other components, | ||
| - | we will see | + | we will see how they communicate to each other. |
| - | + | ||
| === Compositions of components === | === Compositions of components === | ||
| - | ==== The sheet | + | An explicit composition let us know exactly how components are connected. |
| - | [[Image:ARCS_sheet.png|right|350px|thumb]] | + | 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. | ||
| + | |||
| + | ==== Macro-blocks ==== | ||
| + | A sheet can also be used to represent a subset of components | ||
| + | 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. | ||
| - | ==== | + | ===== 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. | ||
| - | + | 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. | ||
| - | + | 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 == | == Publications == | ||
| {{bibtex|Didier06}} | {{bibtex|Didier06}} | ||
Version actuelle
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.
[modifier] Publications
J.Y. Didier, S. Otmane, M. Mallem - A Component Model for Augmented/Mixed Reality Applications with Reconfigurable Data-flow
Pdf