Discussion: Managed-OSVR Overhaul (new lib?)

[JeroMiya]

The Managed-OSVR library was originally created as a quick means to get Unity support. There are a few things I'd like to refactor, but can't due to backward compatibility.

So, I'm suggesting we can start fresh with a new library, keeping the current code in maintenance mode for compatibility. With the new library, we can apply the following major changes:

• Properly namespace code. Each DLL/lib with bindings gets its own namespace, and ONLY bindings from that DLL use that namespace. Currently most of the bindings are in OSVR.ClientKit for both client kit and osvr util functions.
  • OSVR for top-level classes (not specific to any given OSVR-Core library)
  • OSVR.ClientKit to be used ONLY for bindings within the actual osvrClientKit dll/lib.
  • OSVR.Util to be used for bindings within the osvrUtil DLL/lib.
• Make all P/Invoke bindings private. The public API should hide native cruft not relevant to managed code (e.g. IntPtr data elements in custom callbacks).
• Use .NET naming conventions consistently throughout.
• Hierarchical data structures instead of (or at least in addition to) flat C-Like API. For example, the DisplayConfig API should result in an object tree instead of a flat API that mirrors the C API (which is just a flattening of the corresponding internal hierarchical structure).
• Design for no-alloc control flows. Methods meant to be called every frame must not alloc.
• Rename the managed assembly to reflect the fact that it is binding more than just the osvrClientKit library.

The new library would be separate, and renamed to avoid conflicts. Possible names:

• OSVRSharp (more popular convention recently, e.g. CocosSharp, QtSharp, but doesn't look as good with a capitalized brand acronym as the base)
• OSVR.NET (older convention, out of style, but looks a little better than OSVRSharp)
• OSVR (just leave out the suffixes. Might be confused with the native OSVR library)
• ??? Open to suggestions.

[chanibal]

Is there any progress with this? Has anything superseded Managed-OSVR, or is it just a dead project and there are no current .NET bindings for OSVR if you want to use direct mode?

[JeroMiya]

Managed-OSVR isn't a dead project - it's used in the actively maintained OSVR-Unity plugin. It is, however, still missing osvrRenderManager bindings (either OpenGL or Direct3D). OSVR-Unity uses its own native Renderer plugin system for interacting with osvrRenderManager so managed bindings haven't been a big priority (for us at least). The other items in this list are technical debt, but not necessarily high priority. Most of the core API is still good enough.

If you still have requirements for using osvrRenderManager in a non-Unity application using Managed-OSVR, my recommendation at this point would be to create your own thin native code library that manages rendering, with some simple P/Invoke bindings you can access from your managed application. This is similar to what we do for OSVR-Unity.