AR Proposal Public Review - Revision history

Flux: typos

2013-04-02T11:54:40Z

typos

Endovert at 02:02, 27 February 2013

2013-02-27T02:02:13Z

Endovert at 02:01, 27 February 2013

2013-02-27T02:01:48Z

Endovert at 02:01, 27 February 2013

2013-02-27T02:01:07Z

Endovert at 01:49, 27 February 2013

2013-02-27T01:49:08Z

Endovert at 22:37, 26 February 2013

2013-02-26T22:37:57Z

Endovert at 22:12, 26 February 2013

2013-02-26T22:12:21Z

Endovert at 17:57, 25 February 2013

2013-02-25T17:57:31Z

Endovert at 17:51, 25 February 2013

2013-02-25T17:51:27Z

Endovert at 17:49, 25 February 2013

2013-02-25T17:49:06Z

@@ Line 1: / Line 1: @@
 By [[X3D and Augmented Reality|Augmented Reality Continuum Working Group]], Web3D Consortium
@@ Line 10: / Line 9: @@
 ** Use the "discussion" tab on the top of this page to give feedback and start discussions.
 ** If you prefer e-mails, please mail your feedback to Gun Lee (ARC WG co-chair, endovert[at]postech.ac.kr)
 = Extending X3D for MR Visualization - Unified Proposal =
 == 1. Introduction ==
 This document describes an overview of the unified proposal for extending the X3D standard to support Mixed Reality (MR) visualization. Mixed Reality includes both, Augmented Reality (AR) and Augmented Virtuality (AV). The extension of the X3D standard proposed in this document is based on the comparison of three proposals: two from Web3D Korea Chapter (KC1 and KC2) and one from InstantReality (IR), Fraunhofer IGD. The details of the comparison can be found in the following public wiki page: http://web3d.org/x3d/wiki/index.php/Comparison_of_X3D_AR_Proposals.
@@ Line 25: / Line 22: @@
 * Supporting correct occlusion between virtual and physical objects (Ghost object from Proposal KC1 and Color Mask + sortKey from IR)
 * Supporting generic type of sensors including those are not directly related to AR/MR visualization (Direct sensor nodes in IR)
 == 2. Sensors ==
@@ Line 68: / Line 64: @@
 | Camera that is facing towards the user’s view direction.
 |}
 === 2.2 TrackingSensor node ===
@@ Line 105: / Line 100: @@
 == 3. Rendering video stream from camera ==
 To visualize a MR scene, the video stream image acquired from a sensor node should be rendered in the X3D scene. For AR visualization, the video stream should be rendered as a background of the virtual environment, while in the AV visualization, the video stream is used as a texture of a virtual object.
 === 3.1 Using video stream as a Texture ===
@@ Line 117: / Line 111: @@
 <ROUTE fromNode='camera' fromField='image' toNode='tex' toField='image'/>
 </pre>
 === 3.2 Using video stream as a Background ===
@@ Line 147: / Line 140: @@
 The ImageBackdropBackround will automatically scale the image and fit the width or height of the image to that of the viewport while retaining the aspect ratio. As a result, the background image will fill the entire viewport so that there are no blank region left uncovered by the image background.
 == 4. Camera calibration ==
@@ Line 169: / Line 161: @@
 In order to keep backward compatibility with the current specification, we propose having a “fovMode” field which designates what does the value of the “fieldOfView” field represent. The “fovMode” field can have one of the following values: MINIMUM, VERTICAL, HORIZONTAL, or DIAGONAL. The value MINIMUM is the default value for the “fovMode” field which represents the value of the “fieldOfView” is considered as a minimum FOV (either vertical or horizontal), as it is in the current specification. When the “fovMode” field has the value of VERTICAL, HORIZONTAL, or DIAGONAL, the “fieldOfView” is considered as specific values of FOV in vertical, horizontal, or diagonal direction, respectively.
 In addition to the “fovMode” field, the aspect ratio of the FOV in real cameras might not necessarily follow the aspect ratio of the image size it produces. To accommodate this feature, the “aspectRatio” field is introduced which represents the ratio of vertical FOV to the horizontal FOV (vertical/horizontal).
 == 5. Use cases ==
 The following example X3D scene shows how a simple AR scene can be described using the proposed nodes.
 <pre>
@@ Line 185: / Line 175: @@
 <ROUTE fromNode=”camera” fromField=”fovMode” toNode=”arview” toField=”fovMode”/>
 <ROUTE fromNode=”camera” fromField=”aspectRatio” toNode=”arview” toField=”aspectRatio”/>
 <TrackingSensor DEF=”tracker1” description=”OBJECT_FROM_VIEWPOINT” />

← Older revision		Revision as of 02:02, 27 February 2013
Line 1:		Line 1:

−	By [[X3D and Augmented Reality\|Augmented Reality Working Group]], Web3D Consortium	+	By [[X3D and Augmented Reality\|Augmented Reality Continuum Working Group]], Web3D Consortium

	Feb 26, 2013		Feb 26, 2013

← Older revision		Revision as of 02:01, 27 February 2013
Line 1:		Line 1:
−	~~-Working draft~~

	By [[X3D and Augmented Reality\|Augmented Reality Working Group]], Web3D Consortium		By [[X3D and Augmented Reality\|Augmented Reality Working Group]], Web3D Consortium

@@ Line 3: / Line 3: @@
 By [[X3D and Augmented Reality|Augmented Reality Working Group]], Web3D Consortium
-Feb 25, 2013
+Feb 26, 2013
 The Augmented Reality Continuum Working Group (ARC WG) has been developing a proposal for extending X3D to support augmented and mixed reality visualization. As the proposal is reaching the state of its completion, the working group has decided to open the proposal into public and collect feedbacks from others, including our Web3D members, other working groups, and generally from anyone who is interested in AR and Web3D technology. The ARC WG would like to welcome all kinds of feedback that would be helpful to consolidate the proposal and advance into next level of extending the X3D specification to support AR and MR visualization.

@@ Line 7: / Line 7: @@
 The Augmented Reality Continuum Working Group (ARC WG) has been developing a proposal for extending X3D to support augmented and mixed reality visualization. As the proposal is reaching the state of its completion, the working group has decided to open the proposal into public and collect feedbacks from others, including our Web3D members, other working groups, and generally from anyone who is interested in AR and Web3D technology. The ARC WG would like to welcome all kinds of feedback that would be helpful to consolidate the proposal and advance into next level of extending the X3D specification to support AR and MR visualization.
-* Reviewing period: Feb 27 ~ Apr 10, 2013
+* Reviewing period: March, 2013
 * How to give feedback:
 ** Use the "discussion" tab on the top of this page to give feedback and start discussions.

@@ Line 54: / Line 54: @@
 	SFString [out]		fovMode
 	SFFloat	 [out]		aspectRatio
+}
 </pre>
@@ Line 86: / Line 85: @@
 	SFBool	 [out]		isPositionAvailable	FALSE
 	SFBool	 [out]		isRotationAvailable	FALSE
+}
 </pre>

← Older revision		Revision as of 22:12, 26 February 2013
Line 190:		Line 190:


−	<TrackingSensor DEF=”tracker1” ~~purpose~~=~~”urn:web3d:tracking_sensor_purpose:object_to_viewpoint”~~ />	+	<TrackingSensor DEF=”tracker1” description=”OBJECT_FROM_VIEWPOINT” />

	<Transform DEF=”tracked_object”>		<Transform DEF=”tracked_object”>

@@ Line 40: / Line 40: @@
 === 2.1 CalibratedCameraSensor node ===
-The CalibratedCameraSensor node provides an interface to a camera device. The main information provided into the X3D scene through this node is an image stream captured with the camera. The ‘image’ field of the node provides the image stream captured with the camera device. In addition to the image stream, the node should also provide internal parameters of the camera for calibration of the Viewpoint parameters to achieve correct composition of the MR scene. Four fields (focalPoint, fieldOfView, fovMode, and aspectRatio) provides such parameters that corresponds to those fields used in the Viewpoint node. The detailed description of each field is in section 3 where the Viewpoint node is described.
+The CalibratedCameraSensor node provides an interface to a camera device. The main information provided into the X3D scene through this node is an image stream captured with the camera. The ‘image’ field of the node provides the image stream captured with the camera device. In addition to the image stream, the node should also provide internal parameters of the camera for calibration of the Viewpoint parameters to achieve correct composition of the MR scene. Four fields (focalPoint, fieldOfView, fovMode, and aspectRatio) provide such parameters that correspond to those fields used in the Viewpoint node. Detailed descriptions of each field are in section 3 where the Viewpoint node is described.
 <pre>
@@ Line 97: / Line 97: @@
 |-
 | VIEWPOINT_FROM_WORLD
-| For tracking viewpoint relative to the world coordinate. (Useful in immersive displays.)
+| For tracking viewpoint relative to the world coordinate. (e.g., useful for immersive displays to track user's viewpoint.)
 |-
 | OBJECT_FROM_WORLD
-| For tracking an arbitrary physical object relative to the world coordinate. (Useful in immersive displays.)
+| For tracking an arbitrary physical object relative to the world coordinate.
 |-
 | OBJECT_FROM_VIEWPOINT
-| For tracking an arbitrary physical object relative to the viewpoint coordinate. (Useful in computer vision based AR tracking system.)
+| For tracking an arbitrary physical object relative to the viewpoint coordinate. (e.g. useful for computer vision based AR tracking systems.)
 |}
@@ Line 176: / Line 176: @@
 == 5. Use cases ==
-The following example X3D scene shows how to describe a simple AR scene using the proposed nodes.
+The following example X3D scene shows how a simple AR scene can be described using the proposed nodes.
 <pre>
 ...

@@ Line 33: / Line 33: @@
 In this proposal, two new nodes, CalibratedCameraSensor and TrackingSensor nodes, are proposed for representing interfaces for sensors that are essential for MR visualization.
-Since different end users view the X3D scene on different browsers and have different setups of hardware and software, it is not appropriate to describe specific devices or tracking technology to use within the scene. In fact, the author of the X3D scene can have no knowledge of what kind of hardware or software setup is available on the user’s side. Therefore, the X3D scene should only include the high-level description of the purpose of the use of sensor, in order to give hint to the browser and the user to choose appropriate hardware or software on the user’s setup that could meet the intended use. The “description” field is used to describe such intention of using the sensor. At run-time, the browser will show the value of the "description" field to the user through user interface (e.g. a dialog box), asking to choose an appropriate one from the list of sensors available in the local hardware/software setup. The user chooses the appropriate hardware to use for the sensor node, and in this way, users can view the X3D scene with the best option of hardware/software sensors available in his/her environment.
+Since hardware and software setup (including X3D browser) vary between end users, it is not appropriate to describe specific devices or tracking technology to use within the scene. In fact, the author of the X3D scene can have no knowledge of what kind of hardware or software setup is available on the user’s side. Therefore, the X3D scene should only include the high-level description of the purpose of the use of sensor, in order to give hint to the browser and the user to choose appropriate hardware or software on the user’s setup that could meet the intended use. The “description” field is used to describe such intention of using the sensor. At run-time, the browser will show the value of the "description" field to the user through user interface (e.g. a dialog box), asking to choose an appropriate one from the list of sensors available in the local hardware/software setup. The user chooses the appropriate hardware to use for the sensor node, and in this way, users can view the X3D scene with the best option of hardware/software sensors available in his/her environment.
 In addition, the browser can be configured to use specific sensor hardware for the sensor nodes with certain predefined values in the “description” field. Each type of sensor node can have different set of predefined values for the description field, and these values are used by the browser to automatically map the default sensors that are preconfigured by the user. Another way to determine default sensors to use is to keep the history of the sensors chosen by the user. The browser can record the mapping of the sensors and sensor nodes chosen by the user, and when the same X3D scene is loaded later, the browser can use the mapping saved from the previous instance.

@@ Line 31: / Line 31: @@
 To achieve MR visualization, sensing the real environment is crucial. Two types of sensor that are necessary to support MR visualization are those for acquiring video stream images from a real camera and motion tracking information of physical objects. While the sensors could be generalized to acquiring any type of information from the real world, in this proposal, we focus on these two sensors that are crucial for MR visualization.
-Two new nodes, CalibratedCameraSensor and TrackingSensor nodes, are proposed for representing interfaces for these types of sensors.
+In this proposal, two new nodes, CalibratedCameraSensor and TrackingSensor nodes, are proposed for representing interfaces for sensors that are essential for MR visualization.
 Since different end users view the X3D scene on different browsers and have different setups of hardware and software, it is not appropriate to describe specific devices or tracking technology to use within the scene. In fact, the author of the X3D scene can have no knowledge of what kind of hardware or software setup is available on the user’s side. Therefore, the X3D scene should only include the high-level description of the purpose of the use of sensor, in order to give hint to the browser and the user to choose appropriate hardware or software on the user’s setup that could meet the intended use. The “description” field is used to describe such intention of using the sensor. At run-time, the browser will show the value of the "description" field to the user through user interface (e.g. a dialog box), asking to choose an appropriate one from the list of sensors available in the local hardware/software setup. The user chooses the appropriate hardware to use for the sensor node, and in this way, users can view the X3D scene with the best option of hardware/software sensors available in his/her environment.