VRG3D Requirements: Difference between revisions
Jump to navigation
Jump to search
New page: == VRG3D Requirements == * documentation ** "make doc" makes doxygen style documentation ** it's possible to make introduction page... * examples ** lowest-level events * have short-term ... |
No edit summary |
||
| (10 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== High-level goals == | |||
# Software should be open-source (e.g., on SourceForge) | |||
# Let new users get started in a few minutes through online documentation | |||
## Implementation idea: regular diagnostics at the hardware and support-library levels to minimize undetected failures that block users (this needs rephrasing and possibly division into multiple requirements) | |||
# Create rich immersive virtual worlds with high update rates and low-latency | |||
# Interoperate (to some degree) with geometry and color calibration system | |||
# Provide input and output devices (e.g., tracked glasses, wands, audio, tracked paintbrushes, joysticks, spaceball, Wiimote, etc.) | |||
# Easily let applications run on a spectrum of displays ranging from a single conventional monitor to a Cave consisting of 40-60 tiles. | |||
# Easy to make applications run on other universities systems (dhl: maybe implies small dependencies) | |||
## implementation idea: binaries and as source code (what is plan for data distribution?) | |||
# Reduce/minimize “code rot” so apps continue to run and can easily be turned into “demos” | |||
## implementation idea: provide support for regular testing of applications to minimize code rot | |||
# Capture and disseminate experience | |||
## implementation idea: outside of software, e.g., stereo pair, stereo video, session state over time, ... | |||
# Need a scripting interface (e.g., for testing without all hardware available, sharing, "slowing down time", etc.) | |||
# Desktop debugging and development environment (so you can run it without a Cave) | |||
## implementation idea: A simulator (probably inside VRG3D) | |||
== VRG3D Requirements == | == VRG3D Requirements == | ||
| Line 13: | Line 30: | ||
* multiple OS's | * multiple OS's | ||
* testability | * testability | ||
* " | * "ease-of-use" | ||
* code repository & code access | * code repository & code access | ||
Latest revision as of 15:49, 19 January 2010
High-level goals
- Software should be open-source (e.g., on SourceForge)
- Let new users get started in a few minutes through online documentation
- Implementation idea: regular diagnostics at the hardware and support-library levels to minimize undetected failures that block users (this needs rephrasing and possibly division into multiple requirements)
- Create rich immersive virtual worlds with high update rates and low-latency
- Interoperate (to some degree) with geometry and color calibration system
- Provide input and output devices (e.g., tracked glasses, wands, audio, tracked paintbrushes, joysticks, spaceball, Wiimote, etc.)
- Easily let applications run on a spectrum of displays ranging from a single conventional monitor to a Cave consisting of 40-60 tiles.
- Easy to make applications run on other universities systems (dhl: maybe implies small dependencies)
- implementation idea: binaries and as source code (what is plan for data distribution?)
- Reduce/minimize “code rot” so apps continue to run and can easily be turned into “demos”
- implementation idea: provide support for regular testing of applications to minimize code rot
- Capture and disseminate experience
- implementation idea: outside of software, e.g., stereo pair, stereo video, session state over time, ...
- Need a scripting interface (e.g., for testing without all hardware available, sharing, "slowing down time", etc.)
- Desktop debugging and development environment (so you can run it without a Cave)
- implementation idea: A simulator (probably inside VRG3D)
VRG3D Requirements
- documentation
- "make doc" makes doxygen style documentation
- it's possible to make introduction page...
- examples
- lowest-level events
- have short-term milestones & then get guinea pigs to test it (is it actually easy to use?)
- synching
- interaction
- 3D graphics
- multiple displays
- multiple OS's
- testability
- "ease-of-use"
- code repository & code access