A workaround is to explicitly set the renderer type to D3D11 instead of returning a failure:
if (!s_deviceType) {
s_deviceType = kUnityGfxRendererD3D11;
/* DebugLog("[OSVR Rendering Plugin] Attempted to create render manager, "
"but device type wasn't set (to a supported type) by the "
"plugin load/init routine. Order issue?");
return OSVR_RETURN_FAILURE;*/
}
I think D3D11 is the only working path in the rendering plugin anyway (until OpenGL is working), so this patch might be acceptable for now (but it hasn't been implemented yet). It works, but not sure if it will cause any other issues. I did see a white screen once after shutdown, which is unusual.
This seems to be a Unity bug -- failure to set the renderer type in x86 builds. We hit the same bug on the OpenGL path last year. I'd advise building for Windows x86_64. I'm assuming that the number of 32-bit Windows users running VR apps is small and that this isn't affecting many people in the wild, but I could be wrong...
In x86 builds and 32-bit editor, we get the "Failed to create RenderManager" error. Debugging reveals that it fails due to a null UnityRendererType at this line of the rendering plugin: https://github.com/OSVR/OSVR-Unity-Rendering/blob/master/OsvrRenderingPlugin.cpp#L397
A workaround is to explicitly set the renderer type to D3D11 instead of returning a failure:
I think D3D11 is the only working path in the rendering plugin anyway (until OpenGL is working), so this patch might be acceptable for now (but it hasn't been implemented yet). It works, but not sure if it will cause any other issues. I did see a white screen once after shutdown, which is unusual.
This seems to be a Unity bug -- failure to set the renderer type in x86 builds. We hit the same bug on the OpenGL path last year. I'd advise building for Windows x86_64. I'm assuming that the number of 32-bit Windows users running VR apps is small and that this isn't affecting many people in the wild, but I could be wrong...