Oculus Rift and Cloud Party

Inara and Hamlet have just written about Cloud Party and Oculus. I am happy to see that Cloud Party is thinking Oculus Rift. But… really!?! In a web browser?

If you saw my previous post you know that browser-makers are dropping plugins. Right now they can’t drop all of them because the replacement, HTML5, is not advanced enough to be able to provide the same functionality and performance. So, adding Oculus Rift support doesn’t seem practical to me. After all the system has to render twice as many frames to create 3D display for Oculus. Browser based 3D rendering is just barely performing at acceptable 2D display levels now. And that is with many rendering features dropped to keep performance acceptable.

If you try to use shutter glasses you soon learn that you must have a monitor and video card capable of generating 120 FPS. Sixty frames for the left eye and sixty for the right. The same sort of thing is true for Oculus.

But, there is a huge push to get Oculus to mobile devices. The movers and shakers in the game field think it is possible and that the large money is in mobile. I have my doubts, but lots of money is being thrown at the problem. So, we are likely to see some type of solution emerge. A big question is: ‘When?”

See: Cloud Party Becomes First Virtual World to Officially Support the Oculus Rift; Ex-Linden Cyn Skyberg: “We Are Getting Very Close to the Original Concept of VR”

See: Cloud Party: Oculus Rift support and more.

And with Oculus, I hear performance is everything. Poor performance often results in simulator sickness. May be I could market sim-sickness bag attachments for the Oculus… Money Mouth

Ha Ha

3 thoughts on “Oculus Rift and Cloud Party

  1. “But… really!?! In a web browser?”

    You know, a web browser is just a native application the same way Second Life is a native application. When it comes to rendering 3D, the only difference between Chrome and Second Life is that Chrome uses WebGL and Second Life uses a much older OpenGL version. It shows.

    As far as performance implications of Cloud Party running in the browser goes, there aren’t any of note unless something is written in Javascript that shouldn’t be; like say, a physics engine. For something like the Unreal demo which works in Firefox now, there are performance implications even when using asm.js because things like physics are handled client-side and there’s no web standard for physics that’ve allowed browsers to come packaged with physics written in native code.

    For virtual worlds like Second Life and Cloud Party where physics and most other things are handled server-side, what’s the browser have to do with anything? To accuse performance issues, you’d have to point out a feature that’s running in Javascript that shouldn’t be. Things like OpenGL rendering are happening in the GPU, it isn’t Javascript deciding pixels. Things like processing uploaded assets are happening server-side, the decompression of images are happening in native code; networking is happening over native HTTP libraries the likes of what Linden Lab has been trying to catch up to in recent years. And so on.

    You’d be hard pressed to identify any inherent weakness Cloud Party has vs. Second Life due to being in a browser. It has plenty we all want; stateful scripting, materials enabled at every graphics level, custom animated skeletons for NPCs, custom avatars and most important of all, the fact that this was all achievable by 5 people because the whole part of building and distributing the native application is done by thousands of employees at places like Google and Firefox.

    A browser is a lot of things, but in the case of Cloud Party, it’s just a scripted game-engine, which is what Unity, UDK, and etc. are. There’s game engines with embedded Javascript runtimes that would suffer as well if used wrong. If one were to write a physics engine in Boo (Unity’s version of Javascript) rather than use the physics engine built into the native code of Unity, it’d suffer too. Sensible developers don’t script what native code needs to handle though, and the Cloud Party devs have been sensible about this.. There’s nothing like Javascript avatar baking or anything else to point out as egregious.

    “If you saw my previous post you know that browser-makers are dropping plugins. Right now they can’t drop all of them because the replacement, HTML5, is not advanced enough to be able to provide the same functionality and performance. So, adding Oculus Rift support doesn’t seem practical to me. ”

    Cloud Party recommends OculusBridge over plugins, so this won’t matter. It will be great if one day though web standards advance enough that Oculus Rift is plug and play supported by all browsers.

    “After all the system has to render twice as many frames to create 3D display for Oculus.”

    Not true. We can even see in the pictures of the blog post they’re just displaying the stereoscopic 3D render. It wouldn’t make sense to render the regular monitor view and then a 3D stereoscopic view. There’s no reason to assume they aren’t just rendering the 3D stereoscopic view once and just showing it in two places, like every Oculus Rift demo we’ve seen so far does.

    “Browser based 3D rendering is just barely performing at acceptable 2D display levels now.”

    Also completely not true. Again, browsers are native applications like every native application. 2D drawing in browsers, like all native applications, haven’t always been GPU accelerated. Photoshop for example a few versions ago couldn’t support things like real-time liquify or smooth zooming until it became a GPU accelerated application. Most browsers are GPU-accelerated now and so HTML5 features like Canvas are as fast as any native application (there’s exceptions like very, very tuned SIMD using applications, but even a lot of C++ applications don’t use SIMD math).

    Could someone use jQuery to animate DOM objects for a very slow 2D browser experience? Yes. But only in the same way someone could use the Windows API to animate panels rather than use something like Direct2D. Could someone write a javascript renderer of 3D that’d be pathetically slow? Yes, but only in the same way developers have always been able to write software renderers that didn’t use the GPU.

    When it comes to GPU-acceleration there’s no difference between the browser and other native applications; canvas and WebGL are as fast as anything.

    “And that is with many rendering features dropped to keep performance acceptable.”

    WebGL is just OpenGL ES 2. It has all the important features of OpenGL 4.X. The only features its lacking is very old ones like fixed-function pipeline from the 90s that are irrelevant. Something like this isn’t an advantage when GLSL shaders are superior. Lacking features like this just means the latest Deus Ex can be built in OpenGL ES 2 but an old 90’s game’s OpenGL code couldn’t be ported.

    • Oh and I just got what you meant by rendering twice. You meant for the stereoscopic view. For Cloud Party it should be much, much less an issue than with Second Life since Cloud Party is built to run at 60 FPS already via limiting how many resources creators can bog the system down with. I don’t have a Rift to see if it gets 60 FPS in each view though, one could “/show_fps 1” to see.

  2. The newest ctrl+alt studio now has GUI enabled in the rift view, it’s an amazing development that no one seems to have blogged about. I have spent last two days in SL with the rift, chatting and using inventory etc. While its not perfect, it means that you no longer need to switch back and forth but can use for most common things. I have not tried it in cloud party yet, but this is a pretty big step for SL imo.

Leave a Reply

Your email address will not be published. Required fields are marked *