Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Unable to load dll "libOni" on UWP
#1
Hi,

I am trying to use Obi Rope in a Windows Universal Application. I am aware that Obi Rope is not officially supported and does not build out of the box since ConvertAll is not available for Windows Phone (and thus Windows Universal). I was able to get around this and successfully build by creating my own ConvertAll method and replacing all instances with it.

However, when I try to run the application on the device the rope does not move because libOni is not loaded correctly. The exact error is
Code:
DllNotFoundException: Unable to load DLL 'libOni': The specified module could not be found
. Is there anyway I can make sure the Dll gets copied correctly?

Thanks in advance,
Fernando
Reply
#2
(16-08-2017, 06:43 PM)trujano Wrote: Hi,

I am trying to use Obi Rope in a Windows Universal Application. I am aware that Obi Rope is not officially supported and does not build out of the box since ConvertAll is not available for Windows Phone (and thus Windows Universal). I was able to get around this and successfully build by creating my own ConvertAll method and replacing all instances with it.

However, when I try to run the application on the device the rope does not move because libOni is not loaded correctly. The exact error is


Code:
DllNotFoundException: Unable to load DLL 'libOni': The specified module could not be found
. Is there anyway I can make sure the Dll gets copied correctly?

Thanks in advance,
Fernando

Hi there, 

UWP is an entirely different platform. As such, libraries compiled for Windows won´t work in an UWP environment. Getting it to work would involve recompiling the entire library, probably adjusting the existing code to get it to compile correctly. Specifically, there are some extra linker flags that must be added when compiling the library for it to work.

Also, chances are your target architecture is ARM (mobile) in which case the included .dll doesn't even contain remotely suitable code.

There's currently no way to make Obi run in UWP, sorry.
Reply
#3
I've been building a project using Obi Rope, designed to run in VR on Windows Mixed Reality (not on Hololens – on one of the 3rd party VR headsets). Up until now I've been testing the project from the Unity Editor, with the platform set to Universal Windows Platform, and everything's been working just fine. 

But now I've tried making a build of the project, got a bunch of errors, and discovered this thread. 

To say that I'm disappointed would be an understatement. This is something of a disaster. I have a public exhibition that opens in a few days; it has to run for a month, and now I realize that I won't be able to build a standalone application. I'll have to run it from the editor, which will be more difficult to manage (the staff of the gallery will have to keep it running), and I assume it will be less stable and less robust. And unfortunately it's way too late to consider an alternative.

While I understood that ObiRope couldn't run on a Hololens, I had no idea that it couldn't run on UWP at all; this was hardly clear from the documentation (this thread is pretty much the ONLY mention of the problem) – and especially because it runs perfectly well in the editor with UWP as the selected platform. I mean, a WMR VR headset is simply a peripheral for a PC (running Windows 10). And while I now realize that "Universal Windows Platform" isn't "Windows", this is not an obvious distinction (it has "Windows" in the name, after all). So I think this limitation should have been made MUCH more obvious, because now I'm pretty much screwed.

Don't get me wrong, I think ObiRope is brilliant, but now I kind of wish I'd never discovered it.

Anyway, I strongly encourage you to support UWP and WMR as soon as possible.
Reply
#4
(16-02-2018, 03:23 AM)phoberman Wrote: I've been building a project using Obi Rope, designed to run in VR on Windows Mixed Reality (not on Hololens – on one of the 3rd party VR headsets). Up until now I've been testing the project from the Unity Editor, with the platform set to Universal Windows Platform, and everything's been working just fine. 

But now I've tried making a build of the project, got a bunch of errors, and discovered this thread. 

To say that I'm disappointed would be an understatement. This is something of a disaster. I have a public exhibition that opens in a few days; it has to run for a month, and now I realize that I won't be able to build a standalone application. I'll have to run it from the editor, which will be more difficult to manage (the staff of the gallery will have to keep it running), and I assume it will be less stable and less robust. And unfortunately it's way too late to consider an alternative.

While I understood that ObiRope couldn't run on a Hololens, I had no idea that it couldn't run on UWP at all; this was hardly clear from the documentation (this thread is pretty much the ONLY mention of the problem) – and especially because it runs perfectly well in the editor with UWP as the selected platform. I mean, a WMR VR headset is simply a peripheral for a PC (running Windows 10). And while I now realize that "Universal Windows Platform" isn't "Windows", this is not an obvious distinction (it has "Windows" in the name, after all). So I think this limitation should have been made MUCH more obvious, because now I'm pretty much screwed.

Don't get me wrong, I think ObiRope is brilliant, but now I kind of wish I'd never discovered it.

Anyway, I strongly encourage you to support UWP and WMR as soon as possible.

Hi there,

First of all we're really sorry for you experience with Obi. But as you have discovered UWP and Windows standalone are completely different platforms. They even are separate build targets inside Unity. It runs fine inside the editor because the editor is running in Windows, and it uses the Windows-compatible version of the physics library. It will in fact always work in the editor regardless of your target platform. But there just isn't a compatible version of the library for UWP yet.

Even if we jumped into porting to UWP immediately it would take quite a while as we have to: set up a toolchain for building the library, polish any platform-specific issues that could arise, test it, and deploy it. It would take several weeks to do, so it's very unlikely we'd help you in any way by jumping straight into it.

We are working on adding support for more platforms though, and UWP is in the list. Once we add support for it we will announce it.

cheers,
Reply