Thank you for the nudges. Here is what I got:
"I’ll try to answer as many of the questions as I can. Note that this would be a good question to post on the developer mailing list, since the questions and answers are probably worth archiving publicly. If you post something similar to your question on the mailing list, I’ll re-post my answers there too. http://osvr.github.io/mailing-lists/
The general API structure for client applications/game engines (client, as opposed to devices “serving” data or capabilities) is a C API/ABI, with a header-only C++ wrapper for optional use - what I recently learned is apparently called an “hourglass API design”. While there are more headers bundled with an OSVR built snapshot, only a few are actually used for client applications - most are for “internal” APIs. The main project you’d interact with is OSVR-Core, which provides the core functionality on both client and device sides (which share common code in addition to their separate APIs). You’d use headers in osvr/ClientKit, which depends only on others in that directory and on some headers in osvr/Util (corresponding to the osvrClientKit and osvrUtil libraries). In the source code, the API headers are under inc, so that’s inc/osvr/ClientKit - they install to include/osvr/ClientKit when the project is built. We’ve tried to keep headers topical so that client app devs need not consider functionality they aren’t using, as well as to reduce build time by allowing minimal include sets.
I’d recommend looking at the documentation that is generated from the source code and some additional text files in the repo: http://resource.osvr.com/docs/OSVR-Core/ - this is the “public” version that omits all the internal and “implementation detail” items. (Both versions are linked from the OSVR-Core section at http://osvr.github.io/contributing/ ) You might want to start at the “Writing a client application” section: http://resource.osvr.com/docs/OSVR-Core/TopicWritingClientApplication.html
Regarding platforms and binaries: At the moment I don’t know of any folks in the community working on Mac OS X support, but I do know it has built on OS X before and there are about 3 places I can think of that would need porting to run on OS X in the current source. It’s designed to be portable, including to Mac (and iOS), and the dependencies and underlying components work on Mac OS X, but nobody has stepped up and made those platforms a priority yet. It does build and run on Linux (in fact, building and testing on Linux is a part of our CI pipeline, so no OSVR-Core commit ends up approved to have a Windows binary uploaded unless it also builds and passes tests on Debian with both GCC and Clang), but we haven’t had any interest in uploading any pre-built binaries for generic Linuxes. It is subjectively easier to build on Linux than Windows (because of package management and prevalence of packages for dependencies), which might help a bit. I believe Valve is using a specific Ubuntu version as their “target” that they build Linux binaries on/for, but in general if you have the source it usually works best to have a native package for each distribution/version than a binary blob built against really old libraries that hopefully works on a range of systems. (We do have auto-built snapshots/binaries for Android being built and uploaded.)
The current rendering approach uses a generic (parameterized, with parameters supplied by the OSVR system) shader rather than a distortion mesh for applying any required distortion. The shader is fairly simple and can be found in a number of different languages (GLSL, Unity’s shader language, etc.) in various examples. I’m going to guess you’re wanting the OpenGL version, which is here: https://github.com/OSVR/distortionizer/blob/master/vizard/ShaderTest.frag and https://github.com/OSVR/distortionizer/blob/master/vizard/ShaderTest.vert (There’s a corresponding tool to determine the distortion/CA parameters used in the description and that shader interactively for arbitrary displays.) Hopefully that’s not too hard to integrate - there has been some interest in a mesh-based distortion option as well, but I’m not sure what timelines might be on that. Of course, you can generate a distortion mesh given the distortion model and/or shader, if that works better than using the shader directly.
Note that the current API has the client application responsible for parsing a JSON display descriptor and constructing appropriate matrices - while there are a number of implementations of such code you could model yours after, the matrix generation is being pulled into new APIs in ClientKit in the very near future - as in, I’m working on a standardized implementation in a branch, not quite done, but almost ready to merge. So, you might consider doing the input portion of your integration before the rendering portion, just stubbing out the rendering portion, given that you’ll have a much simpler time building your rendering implementation soon. It would be helpful to know what degree of “control” you want to maintain over your rendering setup, and what sorts of data your rendering system would expect to be output. (Pulling this functionality into core is more of a challenge of API design to suit a wide variety of client application architectures than it is a challenge of the actual implementation.)
By design, a client application doesn’t have to concern itself with plugins, etc. so don’t let the number of plugins and repos unnerve you. OSVR provides generic interfaces for a range of VR devices and a “path tree” structure of semantic names by which your app/engine can be independent of the hardware and configuration used to provide the data used. Hopefully this info is helpful - you should be able to find your way around the client examples given the Doxygen link above. Let us know if you have any additional questions, or feedback on rendering data, and I’ll do what I can! (And, if I see a variant of your email on the mailing list, I’ll put a variant of this response on it as well as a reply. If nothing else, let the list know of your progress!)
Thanks for getting involved in OSVR!
Ryan
–
Ryan A. Pavlik, Ph.D.
Senior Software Engineer, Sensics, Inc."
The biggest complications I saw in getting OSVR support is multiple headers & no OSX/Linux binaries. OpenVR just has one openvr_capi.h that includes everything & has Windows/Linux/MacOSX builds done automatically. OSVR is also really really big (I found it overwhelming actually) and the examples were not as straightforward as OpenVR’s “hellow world OpenGL” one.
Anyway, you will probably need to JNAerate a few header files to start. You might want to get intouch with Ryan yourself to get more direct assistance (support@osvr.com).
