VR API Evolution, Generic Interfaces, and Factoring
1 like1,063 views
The document discusses the evolution of VR APIs and the complexities of vendor-specific versus generic interfaces, emphasizing the need for a balance between too generic and too specific configurations. It highlights the challenges faced by application developers in handling input devices and the practice of creating aliases to simplify device mapping. Additionally, it introduces the OSVR framework as a means to facilitate more meaningful application interactions with VR input devices.
VR API Evolution, Generic Interfaces, and Factoring
- 1. VR API Evolution, Generic Interfaces and Factoring Ryan A. Pavlik, PhD Sensics, Inc. July-2015
- 2. First Level ● Vendor-specific API/SDK ● Everything from one vendor, through one SDK ● Using more than what the vendor provides requires mix+match: complexity put on the app developer
- 3. Next Level: Some Genericity ● Commonly invented or re-invented ● Sometimes modeled on a specific implementation (vs. fully generic) ● Input devices numbered ● Convention (implied or explicit) on the meaning of those indices
- 4. Genericity and Factoring ● Concieve of the most generic form of a kind of device ● Devices often factor into multiple interfaces ○ Like a multifunction printer: One device is simultaneously a printer, a scanner, a fax machine… ● Try to keep device-specific aspects out of the generic interface.
- 5. Factoring Decisions ● Careful balance: ○ overly-generic (“series of bits!”) ○ too specific - if each device is its own generic interface, it’s no longer generic ● Guidance in judgement ○ What applications want this data, and what would it be interested in? ○ Would an application using an existing interface want to use this data that way too?
- 6. Back to SDKs: Configuration/Aliases ● Configuration often the most painful part of VR ○ But, for industrial systems, only done a few times in the life of the system, so it didn’t get a lot of attention ● Among others, the need to map/remap input devices ○ New device with different buttons ○ So, you assign names to the numbers
- 7. Aliases ● Existing practice -> New convention -> new practice ● So you get aliases like “Button0” or “YellowButton” ● Effect is that application developers take on complexity in internally mapping input at another level
- 8. The next step - as found in OSVR ● Aliases with no depth limit ● First level goes from number to device- specific meaning (button name, etc) ● Intermediate levels ● Application interacts with an interface with a semantic name ○ A name based on what it means in the app, not on what hardware provides the information
- 9. ... See Path Tree slides for logical continuation
- 10. For additional information: ● OSVR developer portal ○ http://osvr.github.io ● Sensics – Founding contributor to OSVR, experts working in VR/AR for over a decade ○ http://www.sensics.com