Imagine I sold you this wonderful word processor but that it could print only on Epson printers. You might say "That's ok, I have an Epson printer today and I really like it", but then you'd worry: what happens if I get an HP printer next year? Will I need to buy a new version? Will this wonderful word processor support HP in the future? So maybe you'd be reluctant to buy this word processor from me.
Same in VR.
What if you buy a game and it works only on one HMD? Will you need a new version next year when you get a new HMD next year? Will the game support this HMD? What if you buy a shiny new hand sensor next year. Will the game work on it?
and... what if you are building an experience such as a large-scale public VR project for which you need to take 'best of breed' components from various vendors? Maybe your HMD is from one vendor, and the gaming weapon is from another and your wide-area tracking system is from a third. You'd like to find a way to support all of these, while giving you the ability to upgrade them in the future. What if your wide-area tracking system is on order, or on development, but you need to develop with another tracking system in the interim?
That's one problem that the OSVR software platform can solve. OSVR supports over 100 devices today, and allows you to mix and match devices as you please. Changing from one device to another is as simple as changing a configuration file, almost like selecting which printer you want to print the document on.
For instance, we just returned from the I/ITSEC training and simulation show in Orlando. We wanted to show the OSVR HMD (BTW, check out this great video showing multi-user training using the OSVR HDK). We also wanted to show the dSight, a higher-end HMD. These two HMDs are quite different:
- The OSVR HDK has a single HD1080 input, the dSight has inputs.
- The OSVR HDK has a circular field of view of just over 90 degrees. The dSight has a rectangular field of view of about 120x64 degrees.
- The two units use different IMUs: an internal IMU (based on a Bosch chip) for the HDK, a YEI tracker for the dSight.
- They have different distortion functions
- and so forth
Using OSVR, we just had to change the configuration file of the OSVR service, and could run the same demo without changing a single line of code. In fact, if a new combination of HMD and tracking system came out tomorrow, we would not need to bother the application developer. Just get a plugin or a configuration file for OSVR and run with it.
This concept also works for wide-area systems that have multiple players in them. You might have a centralized tracking system (for instance, from ART), that tracks multiple players and objects. Each OSVR client (e.g. the per-user application) can be configured to receive just the particular players of interest and then use this data to render on the HMD of choice. You might even have different HMDs in the same space.
This flexibility is a win for everyone:
- Game developers can develop knowing that their games will work on many different hardware platforms.
- Hardware developers know that as soon as they configure or develop an OSVR plugin, their new hardware will work on pre-existing OSVR-based games
- End-users and integrators have the peace of mind knowing that their investments are future-friendly.
or you can settle for always printing on Epson.
No comments:
Post a Comment