Comparison of X3D AR Proposals - Revision history

Flux: full spelling of month name

2012-08-17T15:58:14Z

full spelling of month name

Flux: properwikifzation of internal link-no need to treat it as HTML external link, no excessive carriage return/new line occurrences - they only waste page resourcew while not doing anything when displayed

2012-07-10T20:02:26Z

properwikifzation of internal link-no need to treat it as HTML external link, no excessive carriage return/new line occurrences - they only waste page resourcew while not doing anything when displayed

Show changes

Endovert at 19:53, 23 April 2012

2012-04-23T19:53:50Z

Endovert at 19:47, 23 April 2012

2012-04-23T19:47:23Z

Endovert at 19:46, 23 April 2012

2012-04-23T19:46:45Z

Endovert at 19:46, 23 April 2012

2012-04-23T19:46:10Z

Yjung at 12:08, 20 March 2012

2012-03-20T12:08:12Z

Endovert at 00:32, 20 March 2012

2012-03-20T00:32:45Z

Endovert at 00:22, 20 March 2012

2012-03-20T00:22:33Z

Endovert at 23:17, 19 March 2012

2012-03-19T23:17:29Z

@@ Line 1: / Line 1: @@
 By [[X3D and Augmented Reality|Augmented Reality Working Group]], Web3D Consortium
-Mar 21, 2012
+March 21, 2012
 == 1. Introduction ==

@@ Line 1: / Line 1: @@
 By [http://www.web3d.org/x3d/wiki/index.php/X3D_and_Augmented_Reality Augmented Reality Working Group], Web3D Consortium
@@ Line 496: / Line 495: @@
 |-
 | Using tracking information to change 3D scene
-| routing from '''CameraSensor''' node
+| routing tracking data from '''CameraSensor''' node
-| routing from '''ImagePatch''' and '''GPSSensor''' nodes + Events generated by  '''VisibilitySensor''' and '''RangeSensor''' nodes
+| routing tracking data from '''ImagePatch''' and '''GPSSensor''' nodes + events generated by  '''VisibilitySensor''' and '''RangeSensor''' nodes
-| routing from '''IOSensor''' node
+| routing tracking data from '''IOSensor''' node
 |-
 | Retrieving camera calibration (internal parameters) information

← Older revision		Revision as of 19:47, 23 April 2012
Line 1:		Line 1:
−	~~= Comparison of X3D AR Proposals =~~
−

	By [http://www.web3d.org/x3d/wiki/index.php/X3D_and_Augmented_Reality Augmented Reality Working Group], Web3D Consortium		By [http://www.web3d.org/x3d/wiki/index.php/X3D_and_Augmented_Reality Augmented Reality Working Group], Web3D Consortium

← Older revision		Revision as of 19:46, 23 April 2012
Line 1:		Line 1:
−	= Comparison of X3D AR Proposals ~~- Working Draft~~ =	+	= Comparison of X3D AR Proposals =

@@ Line 499: / Line 499: @@
 | Using tracking information to change 3D scene
 | routing from '''CameraSensor''' node
-| '''VisibilitySensor''' and '''RangeSensor''' nodes
+| routing from '''ImagePatch''' and '''GPSSensor''' nodes + Events generated by  '''VisibilitySensor''' and '''RangeSensor''' nodes
 | routing from '''IOSensor''' node
 |-

@@ Line 152: / Line 152: @@
 To make the polygon for the background fill the viewport, the PolygonBackground's field fixedImageSize is used for describing the aspect ratio of the image, and the mode field is set to "VERTICAL" or "HORIZONTAL" which describes the way the polygon fits the viewport.
@@ Line 483: / Line 485: @@
 | '''MovieBackground''' node ( or optionally with routing from '''CameraSensor''' node)
 | '''LiveCamera''' node + ''TextureBackground'' node
-| '''IOSensor''' node + '''PolygonBackground''' node
+| '''IOSensor''' node + '''PolygonBackground''' node (or optionally '''ImageBackground''' node)
 |-
 | Supporting color keying in texture
@@ Line 498: / Line 500: @@
 | routing from '''CameraSensor''' node
 | '''VisibilitySensor''' and '''RangeSensor''' nodes
-| routing form '''IOSensor''' node
+| routing from '''IOSensor''' node
 |-
 | Retrieving camera calibration (internal parameters) information
@@ Line 508: / Line 510: @@
 | '''MatrixViewpoint''' node
 | ''Viewpoint'' node
-| '''Viewfrustum''' and ''Viewpoint'' nodes
+| '''Viewfrustum''' and ''Viewpoint'' nodes (alternatively '''MatrixTransform''' node)
 |-
 | Specifying nodes as physical object representatives
 | '''GhostGroup''' node
 | N/A
-| '''ColorMaskMode''' and ''Appearance'' nodes
+| '''ColorMaskMode''' and ''Appearance'' nodes (together with sortKey field)
 |}
@@ Line 523: / Line 525: @@
 In the browser implementors' point of view, encapsulating the functions into higher-level components gives more room to choose their own way to implement the given function. However, if further detail control is required and added later for other applications, this could affect the ways how previous higher level components are implemented and may result in need for change in implementation level. Testing each function would be more complicated if low level details are accessible to scene authors, since there are more cases to test in order to make sure each combination of low level components work together in general case.
-Providing both options could be an alternative, providing multiple choices to the content authors. However, this would give more burdens to the browser implementors, and the specification development would take more effort.
+Providing both options could be an alternative, providing multiple choices to the content authors. However, this would give more burdens to the browser implementors, and the specification development would take more effort. Especially when considering the fact, that AR and tracking methods are still a moving target that is far from standardization.

← Older revision		Revision as of 00:32, 20 March 2012
Line 465:		Line 465:

	=== 9.4 Discussion ===		=== 9.4 Discussion ===
−	While proposal KC1 suggests a high level, simple to use approach for a specific application in AR/MR, proposal IR ~~provides more~~ detail ~~controllable~~, general ~~purpose approach~~.	+	While proposal KC1 suggests a high level, simple to use approach for a specific application in AR/MR depth occlusion visualization, proposal IR suggest general purpose detail control of the rendering process. Proposal KC1 directly deals with depth buffer values, providing general-case solution for depth occlusion problem. In comparison, proposal IR uses color masking technique to mimic the depth occlusion effect, which could have limitations with incorrect results in dynamic scenes.

@@ Line 517: / Line 517: @@
-While all of the proposals suggest and cover similar set of functionalities required for supporting AR and MR visualization in X3D, Proposal KC1 and KC2 take the path of relatively higher level control, that provides simpler syntax that could be applied for specific cases for AR and MR. On the contrary, proposal IR introduces more generic purpose nodes and suggests to combine them to implement required functions, making AR and MR visualization a special use case of proposed extension. Considering the difference between the proposals, trade off between simplicity and flexibility/extensibility leads to a need for further discussion.
+While all of the proposals suggest and cover similar set of functionalities required for supporting AR and MR visualization in X3D, Proposal KC1 and KC2 take the path of relatively higher level control, that provides simpler syntax that could be applied for specific cases for AR and MR. On the contrary, proposal IR introduces more generic purpose nodes and suggests to combine these nodes to implement required AR functions, dealing AR and MR visualization as a special use case of proposed extension. Considering the difference between the proposals, trade off between simplicity and flexibility/extensibility needs further discussion as AR WG proceeds to develop specifications for AR visualization components.
-In the content authors' point of view, providing higher-level abstracted control gives more simpler and easy to use syntax. However, detail control might be missing which could be necessary for applications other than AR/MR.
+In the content authors' point of view, providing higher-level abstracted control gives more simpler and easy-to-use syntax. However, detail control might be missing which could be necessary for applications other than common AR/MR visualization.
-In the browser implementor point of view, encapsulating the functions into higher level apis gives more room to choose their own way to implement the given function. On the other hand, if further detail control is required and added later for other applications, this could affect the ways how previous higher level components are implemented and may result in need for change in implementation level. Testing each function would be more complicated if low level details are accessible to scene authors, since there are more cases to test in order to make sure it works in general case.
+In the browser implementors' point of view, encapsulating the functions into higher-level components gives more room to choose their own way to implement the given function. However, if further detail control is required and added later for other applications, this could affect the ways how previous higher level components are implemented and may result in need for change in implementation level. Testing each function would be more complicated if low level details are accessible to scene authors, since there are more cases to test in order to make sure each combination of low level components work together in general case.
-Providing both in parallel could be an alternative, however, this would give more burdens to the browser implementors.
+Providing both options could be an alternative, providing multiple choices to the content authors. However, this would give more burdens to the browser implementors, and the specification development would take more effort.

← Older revision		Revision as of 23:17, 19 March 2012
Line 2:		Line 2:


−	by [http://www.web3d.org/x3d/wiki/index.php/X3D_and_Augmented_Reality Augmented Reality Working Group], Web3D Consortium	+	By [http://www.web3d.org/x3d/wiki/index.php/X3D_and_Augmented_Reality Augmented Reality Working Group], Web3D Consortium

	Mar 21, 2012		Mar 21, 2012