ARCS/en

Un article de Wiki-evr@.

Version du 20 juillet 2006 à 13:07 (modifier) Gi (Discuter | Contributions) ← Différence précédente		Version actuelle (17 novembre 2011 à 22:19) (modifier) (défaire) Gi (Discuter | Contributions)
(6 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 43 :		Ligne 46 :
	applications.		applications.
-	Before detailing our components, we should introduce the main communication mechanism	+	==== Signal/slots ====
-	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		Our solution is based on the signal/slot communication
	model between components. This paradigm, mainly		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 ],		it, for example: QT [http://www.trolltech.com ],
	libsigc++ [http://libsigc.sourceforge.net] derived from		libsigc++ [http://libsigc.sourceforge.net] derived from
Ligne 59 :		Ligne 58 :
	triggered when the signal is ”emitted”. Signals and		triggered when the signal is ”emitted”. Signals and
	slots can be connected and disconnected dynamically		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	+	==== Component representation ====-->
-	connections when one of the object involved in communication	+	<!--[[Image:ARCS_component.png|right|thumb|ARCS Component representation]]--><!--
-	is destroyed. This allows the user to make	+	A component in ARCS is an entity
-	signal/slot connections without expending a great effort	+	or object able to export by itself its interface which is
-	to manage the lifetimes of those connections with	+	made of signals and slots. As we will see,
-	regard to the lifetimes of all objects involved.	+	we will often use both the terms of components
		+	and objects to refer to the same thing, since the components
		+	we will develop are objects.
		+
		+	==== Component libraries ====
		+	Components are compiled pieces of code stored in dynamic
		+	libraries with three specific entry points:
		+	* one for describing objects stored in the library,
		+	* one for instantiating an object contained in the library,
		+	* one for destroying an object instantiated from this library.
		+
		+	Once components are stored in dynamic libraries, we
		+	can load and use them on demand. Therefore, a component
		+	may require some configuration so we need a
		+	system to set component properties.
		+
		+	==== 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 with only one parameter which to a list of simple types such as
		+	strings, numerical values and other components.
		+
		+	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''
		+	that are performed before the component is
		+	connected with others and we have a second category
		+	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 how they communicate to each other.
		+
		+	=== 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.
-	==== The sheet, an explicit composition ====	+	==== 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.
-	==== Initialisations of components ====	+	==== 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.
-	==== Other composition mechanism ====	+	===== 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.
-	=== Extending the sheet capabilities ===	+	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.

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