Revision as of 05:12, 4 October 2011

Working Draft

Comparison between existing proposals

Augmented Reality Working Group Web3D Consortium

July 20, 2011

1. Introduction

This document compares the existing proposals for extending X3D to support augmented and mixed reality visualization. Three (?) main proposals are compared in terms of requirements – two from Korean chapter and one from Instant Reality.

2. Using Live Video stream as a texture

2.1 Proposal A This proposal proposed a new sensor node, CameraSensor (previously named LiveCamera node), for retrieving live video data from a camera device, and then routing the video stream to a PixelTexture node. The X3D browser is in charge of implementing and handling devices and mapping the video data to the CameraSensor node inside the X3D scene. The video stream itself is provided as a value (SFImage) field of the node which is updated every frame by the browser implementation according to the camera data.

CameraSensor:X3DDirectSensorNode {
 SFImage [out] value
 SFBool [out] on FALSE
 SFMatrix4f [out] projmat "1 0 0 0 … “
 SFBool [out] tracking FALSE
 SFVec3f [out] position
 SFRotation [out] orientation 
}

While this straight forward, routing SFImage values might lead to performance and implementation problem. As an alternative, the same proposal also proposed to extend the behavior of the existing MovieTexture node to support live video stream within the node. The proposed behavior X3D browser is to allow users to select a file or a camera device for the MovieTexture node in the scene, if the url field of the node is empty (or filled with special token values, such as ‘USER_CUSTOMIZED’).

<Appearance>

     <MovieTexture loop='true'   url=/> 

</Appearance>

While this approach avoids performance problems by not exposing SFImage fields updated in real-time, it lacks of supports for using live video stream data for other purposes, such as background. This is to be solved partially by adding a new node MovieBackground, which behaves similarly to the MovieTexture but uses the user selected movie file or live video stream from a camera for filling the background of the 3D scene.

2.2 Proposal B The proposal from Gerard Kim, in Korea Chapter, proposed a new sensor node, , …

2.3 Proposal C

The proposal from Instant Reality proposed a new sensor node, …

2.4 Discussion These three proposals included similar structures and nodes …

3. Using Live Video stream as a background

3.1 Proposal A The proposal proposed a MovieBackground node, extended from Background node to support ‘liveSource’ field which is assigned with a CameraSensor node (as described in 2.1) from which the Background node receives the live video stream data. Once the ‘liveSource’ field is assigned with a validate CameraSensor node, the background image is updated according to the live video stream from the CameraSensor node, assigned. For other purpose of use, it could also have a url field on which general source of movie clip could be assigned an used as a background.

MovieBackground:X3DBackgroundNode {

    ... // same to the original Background node
    SFString    [in] url
    SFNode 	[in] liveSource

}

Similar to the case in 2.1, the proposal also suggests a different approach where the MovieBackground node doesn’t explicitly need a CameraSensor node, but to let the browser to ask the user to choose the movie source (including camera device) when the url field is left empty (or filled with special token values, such as ‘USER_CUSTOMIZED’).

4. Supporting color keying in texture

4.1 Proposal A This proposal proposed to add a ‘keyColor’ field to the MovieTexture node, which indicates the color expected to be rendered as transparent, in order to provide chroma key effect on the movie texture. The browser will be in charge of rendering the parts of the MovieTexture with as transparent, and those browser that does not support this feature could simply fall back with rendering the MovieTexture in a normal way (i.e. showing the texture as is).

MovieTexture:X3DBackgroundNode {

    ... // same to the MovieTexture node described in 2.1

SFColor [in] keyColor }

5. Retrieving tracking information

5.1 Proposal A This proposal does not define an explicit way to interface tracking information, but suggests using the same CameraSensor node, used for retrieving live video stream, for retrieving tracking information. As described in 2.1, the proposed CameraSensor node includes ‘position’ and ‘orientation’ fields that represent the tracking information of the camera motion. The method has its limitations with not supporting tracking information of general objects other than the camera sensor.

6. Using tracking information to change 3D scene

6.1 Proposal A This proposal does not propose any new node or function, but to use routing method to link tracking information from the CameraSensor node to a Viewpoint node’s position and orientation, in general. This could be also extended by a MatrixViewpoint node (to be described in 8.1) which could have a field to identify the corresponding CameraSensor node, causing the same results without explicitly routing the corresponding fields.

7. Retrieving camera calibration information

7.1 Proposal A This proposal doesn’t define an explicit way to interface tracking information, but suggests using the same CameraSensor node, used for retrieving live video stream, for retrieving camera calibration information. As described in 2.1, the proposed CameraSensor node includes a ‘projmat’ field which represents the calibration information of the CameraSensor.

8. Using calibration information to set properties of (virtual) camera

8.1 Proposal A This proposal suggests a MatrixViewpoint node, which is a child of a scene node which represents a virtual viewpoint calibrated according to the corresponding physical live video camera (on the user's computer). The 'projmat' field represents the internal parameters (or projection matrix) of the MatrixViewpoint. The ‘position' and ‘orientation’ fields represent three dimensional position and orientation of the viewpoint within the virtual space. The ‘cameraSensor’ field represents a CameraSensor node, from which the viewpoint parameters (including projmat, position and orientation fields) of the MatrixViewpoint are updated according to. Once the ‘cameraSensor’ field is assigned with a validate CameraSensor node, the viewpoint parameters are updated according to the values from the CameraSensor node, assigned. Otherwise, it could be also used with routing each parameter of the MatrixViewpoint node from corresponding source of calibrated values.

MatrixViewpoint : X3DViewpointNode{

    SFMatrix4f 		[in,out]	projmat
    SFVec3f 		[in,out]	position
    SFRotation 		[in,out]	orientation
    SFNode 		[in,out]	cameraSensor

}

9. Specifying nodes as physical object representatives

9.1 Proposal A This proposal suggests a GhostGroup node for indicating its child nodes being representatives of physical objects for visualizing correct occlusion. The proposed node is extended from Group node to support those geometries of its child nodes are rendered as ghost objects. The browser should render the child nodes only into the depth buffer and not into the color buffer. As a result, the portion of the live video image corresponding to the ghost object is visualized with correct depth value, forming correct occlusion with other virtual objects.

Group: X3DGroupingNode{

    ... // same to the original Group node

}