Difference between revisions of "Plans for Merging X3D AR Proposals"

From Web3D.org
Jump to: navigation, search
(plain http)
 
(10 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
This page is for discussing plans for merging X3D AR proposals, compared in [[Comparison of X3D AR Proposals]].
 
This page is for discussing plans for merging X3D AR proposals, compared in [[Comparison of X3D AR Proposals]].
  
−
== Yvonne ==
+
These are the steps we will take as a process of merging the X3D AR proposals:
  
−
== Gerard Kim ==
+
1. Discuss general strategy/policy/guidelines
 +
* General design guidelines in Web3D consortium level? → Not in explicit form, but there are in the concept sections of node specifications.
 +
* Notes from Don and Dick:
 +
** When a new field is added to a node, carefully choose a default value for backward compatibility.
 +
** For consistency, mixing multiple functions into a single node is not recommended.
 +
** Device independence is taken for granted.
 +
** For identifying devices, URNs could be a proper way to describe them.
 +
** Metric for names - We have the right name if nobody asks about it anymore.
 +
** Start with designing abstract functionality first and then move on to the node specification.
 +
** Build examples/use cases and use them as a test for integrity.
 +
* Rule of thumb
 +
** From the scene writer's point of view, preferably less code for commonly/frequently used features, while detail control available for special cases.
 +
** From the user's (viewer's) point of view, the scene should be adopted to the hardware/software environment (tracker, camera device, browser, etc.) given user has. In other words, scene writer should not specify hardware/software environment in the scene, which is on the users' side.
  
−
== Gun ==
+
2. Produce a merged proposal for each functional components
−
 
+
* Investigate each functional features stepwise: [[Discussions for Merging X3D AR Proposals]]
−
1. Discuss general strategy/policy/guidelines
+
** Camera video stream image into the scene (texture and background)
−
* General guidelines in Web3D consortium?
+
** Tracking (including support for general tracking devices)
−
* From the scene writer's point of view, preferably less code for commonly/frequently used features, while detail control available for special cases.
+
** Camera calibration (viewpoints)
−
* From the user's (viewer's) point of view, the scene should be adopted to the hardware/software environment (tracker, camera device, browser, etc.) s/he has. In other words, scene writer should not specify hardware/software environment in the scene, which is on the users' side.
+
** Others (color-keying, depth occlusion)
  
−
2. Investigate each functional features stepwise
+
[http://docs.google.com/document/d/1BXkeaj0RVdoLpj-vBzuVRlpgF7UbQDNtpTCUF5ocQqw/edit Merged proposal - Working Draft]
−
* Camera video stream image in the scene (texture and background)
+
−
* Tracking (including support for general tracking devices)
+
−
* Camera calibration (viewpoints)
+
−
* Others (color-keying, depth occlusion)
+
  
−
3. Integration of functional features
+
3. Check Integrity of the merged proposal
−
* Conflicts between individual components
+
* Check and resolve conflicts between individual functional components
−
* Merging components
+
* Merge overlapping features between individual functional components
  
−
4. Specification writing
+
4. Write specification
  
 
5. Review
 
5. Review

Latest revision as of 21:18, 1 February 2013

This page is for discussing plans for merging X3D AR proposals, compared in Comparison of X3D AR Proposals.

These are the steps we will take as a process of merging the X3D AR proposals:

1. Discuss general strategy/policy/guidelines

  • General design guidelines in Web3D consortium level? → Not in explicit form, but there are in the concept sections of node specifications.
  • Notes from Don and Dick:
    • When a new field is added to a node, carefully choose a default value for backward compatibility.
    • For consistency, mixing multiple functions into a single node is not recommended.
    • Device independence is taken for granted.
    • For identifying devices, URNs could be a proper way to describe them.
    • Metric for names - We have the right name if nobody asks about it anymore.
    • Start with designing abstract functionality first and then move on to the node specification.
    • Build examples/use cases and use them as a test for integrity.
  • Rule of thumb
    • From the scene writer's point of view, preferably less code for commonly/frequently used features, while detail control available for special cases.
    • From the user's (viewer's) point of view, the scene should be adopted to the hardware/software environment (tracker, camera device, browser, etc.) given user has. In other words, scene writer should not specify hardware/software environment in the scene, which is on the users' side.

2. Produce a merged proposal for each functional components

  • Investigate each functional features stepwise: Discussions for Merging X3D AR Proposals
    • Camera video stream image into the scene (texture and background)
    • Tracking (including support for general tracking devices)
    • Camera calibration (viewpoints)
    • Others (color-keying, depth occlusion)

Merged proposal - Working Draft

3. Check Integrity of the merged proposal

  • Check and resolve conflicts between individual functional components
  • Merge overlapping features between individual functional components

4. Write specification

5. Review

Retrieved from "https://web3d.org/wiki/index.php?title=Plans_for_Merging_X3D_AR_Proposals&oldid=6563"