Difference between revisions of "Plans for Merging X3D AR Proposals"
From Web3D.org
(plain http) |
|||
| (8 intermediate revisions by 2 users not shown) | |||
| Line 4: | Line 4: | ||
1. Discuss general strategy/policy/guidelines | 1. Discuss general strategy/policy/guidelines | ||
| − | * General guidelines in Web3D consortium? | + | * General design guidelines in Web3D consortium level? → Not in explicit form, but there are in the concept sections of node specifications. |
| − | * From the scene writer's point of view, preferably less code for commonly/frequently used features, while detail control available for special cases. | + | * Notes from Don and Dick: |
| − | * From the user's (viewer's) point of view, the scene should be adopted to the hardware/software environment (tracker, camera device, browser, etc.) | + | ** 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 | 2. Produce a merged proposal for each functional components | ||
| − | Investigate each functional features stepwise: | + | * Investigate each functional features stepwise: [[Discussions for Merging X3D AR Proposals]] |
| − | * Camera video stream image into the scene (texture and background) | + | ** Camera video stream image into the scene (texture and background) |
| − | * Tracking (including support for general tracking devices) | + | ** Tracking (including support for general tracking devices) |
| − | * Camera calibration (viewpoints) | + | ** Camera calibration (viewpoints) |
| − | * Others (color-keying, depth occlusion) | + | ** Others (color-keying, depth occlusion) |
| + | |||
| + | [http://docs.google.com/document/d/1BXkeaj0RVdoLpj-vBzuVRlpgF7UbQDNtpTCUF5ocQqw/edit Merged proposal - Working Draft] | ||
3. Check Integrity of the merged proposal | 3. Check Integrity of the merged proposal | ||
| Line 19: | Line 30: | ||
* Merge overlapping features between individual functional components | * Merge overlapping features between individual functional components | ||
| − | 4. | + | 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
