Skip to main content
Participant
August 24, 2013

Unity Bug with Oculus Integration?

Hi. I'm making my first game for the Oculus using Unity and want to host the game on my website. So far it has been going very well but i have a problem with Oculus integration when i build my project using the "web player" option.

Background:

I have noticed that if i make a normal game (no oculus integration) i can build it and select the web player. After the game builds i can play it in my browser no problems.

However, if i add the Oculus Integration (adding the required Assets and using the OVR Player Controller) when i build the project and selecting web player, it builds successfully but then when i open it the web player crashes (see attached).


Note:

I noticed that when i import the Oculus Intergration Asset that a "Oculus" tab now shows in the toolbar across the top of unity with a build option.

However i don't actually need to use this tab in order to build a successful .exe with Oculus integration, i'm just using the standard File -> Build Settings -> Windows option to make my game and it works fine.


Has anyone else had this issue? I tried searching this forum but no hits.If it is a known bug, does the Oculus Integration pack for Unity just need to have a "build for web player" option added to it for this to work?

Thanks for your help!

Medium
    This topic has been closed for replies.

    10 replies

    New Participant
    August 24, 2013
    I was just trying to do the same thing with a simple scene and had the exact same problem. Glad to find I'm not the only one :roll:
    Inspiring
    August 28, 2013
    The web player won't work, since you can't load DLLs over the web.
    AMD Ryzen 7 1800X | MSI X370 Titanium | G.Skill 16GB DDR4 3200 | EVGA SuperNOVA 1000 | Corsair Hydro H110i Gigabyte RX Vega 64 x2 | Samsung 960 Evo M.2 500GB | Seagate FireCuda SSHD 2TB | Phanteks ENTHOO EVOLV
    MediumAuthor
    Participant
    August 28, 2013
    Thanks!

    After your post I did a bit more research on the unity forum


    You have to distinguish between native code dlls and managed code dlls. Managed code dlls (.NET libraries) can be used without any problems in a webbuild as long as it's a pure managed dll and not a mixed-mode dll. So if you try to use plugins or other native code function from a dll it won't work.

    100% managed dlls should always work as long as it doesn't use a class or a function that isn't supported by Unity or the webplayer. See the Mono compatibility page for a full list of all .NET classes / methods which are supported.


    I assume the dlls in the rift integration are not of the supported .net class type?
    Inspiring
    August 28, 2013
    Yes, I believe it uses a native DLL.
    AMD Ryzen 7 1800X | MSI X370 Titanium | G.Skill 16GB DDR4 3200 | EVGA SuperNOVA 1000 | Corsair Hydro H110i Gigabyte RX Vega 64 x2 | Samsung 960 Evo M.2 500GB | Seagate FireCuda SSHD 2TB | Phanteks ENTHOO EVOLV
    MediumAuthor
    Participant
    August 30, 2013
    Is that something that is changeable or will no one ever be able to publish their unity projects online for the rift?
    Inspiring
    August 30, 2013
    I don't think it's an easy fix, but let me see if I can find out more.
    AMD Ryzen 7 1800X | MSI X370 Titanium | G.Skill 16GB DDR4 3200 | EVGA SuperNOVA 1000 | Corsair Hydro H110i Gigabyte RX Vega 64 x2 | Samsung 960 Evo M.2 500GB | Seagate FireCuda SSHD 2TB | Phanteks ENTHOO EVOLV
    MediumAuthor
    Participant
    August 31, 2013
    Thanks for all your help with this :)

    Are you aware of other game engines that allow publishing to web?
    Inspiring
    September 5, 2013
    There are some other engines with web support, but I doubt any of them would allow unrestricted access to the PC hardware (for example, to communicate with the head-tracker). What some people have done (and what you can probably do with Unity) is create a simple server app (in C++) that communicates with the tracker and then sends network messages that can be read within the web player. Might be something worth looking into.
    AMD Ryzen 7 1800X | MSI X370 Titanium | G.Skill 16GB DDR4 3200 | EVGA SuperNOVA 1000 | Corsair Hydro H110i Gigabyte RX Vega 64 x2 | Samsung 960 Evo M.2 500GB | Seagate FireCuda SSHD 2TB | Phanteks ENTHOO EVOLV
    MediumAuthor
    Participant
    September 5, 2013
    Thanks for that!

    At the end of the day head tracking to me seems no different from a keyboard and mouse, its just data from hardware. Obviously a keyboard and mouse have been around a lot longer than a rift, but long term hopefully this data from hardware will be able to be used more freely.
    Up and Coming
    February 7, 2014
    I just ran into this too, but I didn't think too much of it going in because my intent is to use vr.js on the web page to send HMD info into the Unity scene, and I figured I'd just take out the OVRDevice and replace it with the data coming in from vr.js.
    Really, all the webplayer needs is the ability to render properly stereo cams with appropriate warping and whatnot, shaders etc., should not have to depend on access to the device, therefore not have to depend on an unmanaged DLL.

    So I edited OVRDevice.cs, conditionally remove the API's which access the DLL directly, replace that with ones which just return local variables. Those local variables are set via another set of public functions by which the web page sends data in via SendMessage to the object containing OVRDevice. It's not perfect, as the DLL has functions for prediction and acceleration and so forth that vr.js does not expose, but it could (it's open source).

    Not sure how well Fraunhofer's InstantIO will work as that uses a web socket, but that might be worth a try too.