VR Expert Explains Max-Planck's "Holodeck" -- and How Poor FPS Plagues Second Life for Oculus Rift

Here's an interesting look at the virtual reality "holodeck" of the Max Planck Institute -- yes, they have one:

That's interesting in itself, and then at around 8 minutes in, the Max-Planck VR expert mentions he's tried the Second Life for Oculus Rift viewer, but couldn't use it, because the low framerate made him nauseous:

"At home I was playing around with Second Life [for Oculus Rift]... but I got really bad frame rate, and I was really then sick for half an hour." He recommends 60 frames per second, as opposed to the 10-20 FPS that's more typical for most Second Life users. (Which is why the Institute's holodeck is using Unity, he goes on, and not SL.) So that's a pretty big stumbling block for Second Life integrated with the Rift. At the risk of sounding like a commercial (because I sometimes consult for the company), this could be a great opportunity for OnLive's SL Go service, which typically does get SL running at 60 FPS and greater.

Hat tip: Cube Republic and /secondlife on Reddit.

Please share this post:

Tweet

Comments

[Hitomi Tiponi]

He is quite right (and Oculus will never be used by any more than a handful of SL's population) - but please stop saying that SL Go is the answer until you have tried it at typical low Wi-Fi connection speeds where it is completely unusable because of latency and screen refocusing issues.

[Darien Caldwell]

he must haev crappy hardware if he's only getting 20-30 FPS. Anyone with a decent video card should be getting 50-60+ FPS in SL, even with full shadows and advanced lighting on. By Decent I don't mean "The cheapest card you can get" but at least a 650/750 or better.

If you are going to use the Oculus, you need the hardware to use it. You can't blame SL for your poor hardware.

[Hamlet Au]

"please stop saying that SL Go is the answer until you have tried it at typical low Wi-Fi connection speeds"

I have. But if you're having trouble, plz hit up the support team.

[Arcadia Codesmith]

It's entirely possible that one of the motivators behind LL's new wirtual world project is the technical difficulty of getting the SL platform to deliver acceptable performance stats with the Oculus on average/subaverage client systems. If something like SL Go helps bridge that gap, I'm all for it.

I know some people like to downplay the significance of the Oculus Rift, but the concept of immersive VR has pretty much driven the whole history of virtual world development from the beginning. Oculus may not be the mass-market breakthrough that its backers hope, but even modest success in this arena will pave the way for the next generation of Virtual Retinal Displays.

A true "holodeck" environment with which you can fully interact is a tall order, because, well, physics. I don't expect it in my lifetime... but I'm open to being pleasantly surprised.

[UCMO]

I have the latest greatest Mac Pro with killer graphics - and SL runs awesome... until I turn on HMD. It slows down to about 10-15 fps, at best while using the Rift. I think it is an issue with the code used to split the screen and display it from two camera angles... I have also tried the CtrlAlt viewer, and while it is still not as fast as viewing a flat 2d SL, it is noticeably faster than the 'official' LL viewer. So, I really do not believe that SLGo would improve the experience at all. The viewer code used to power the Rift's display is possibly at fault.

[Ezra]

Since the consumer version of the Oculus Rift isn't due until 2015-2016, the same time frame as the SL2's beta and release, Oculus Rift for SL as more than a niche thing is probably a lost cause anyway. Any early adopters for Oculus Rift will more than likely be willing to be early adopters for SL2.

[Gwyneth Llewelyn]

I love necroposting! It's such a delight to look back 11 years at what looked to be an awesome solution to SL's low FPS 'plague' — SL Go.

I never figured out why that technology was 'abandoned', so to speak. At a time when we started seeing so many fantastic changes in SL (and Sansar was just around the corner...), which, unfortunately, the majority of us couldn't see (@UCMO above had exactly the same Mac that I still use every day to log in to SL; aye, 15 FPS is still possible — not with an Oculus, though — but, wow, all that in glorious meshed avatars, super-advanced lighting and PBR materials... it's a completely different SL experience than what I had when my Mac was brand new, several orders of magnitude better... nevertheless... the hardware is old and outdated, but SL still runs it as it used to run).

Well, we have Zero now. I seriously hope it continues to be around, although it has been harder and harder to log in — I ought to use Firestorm's variant instead. The big difference is that, with SL Go, LL had far less control over what exactly was being streamed and how. The technology behind Zero leverages on LL's 'new relationship' with Amazon's AWS cloud services: it's not just a massive cut in running costs, it's also access to new technology directly via Amazon's complex APIs. In this specific case, LL is using a service provided by AWS to stream content directly from the SL Viewer, running on a virtual server, while residents only need a browser to access a static HTML5 page with a bit of JavaScript which sends keystrokes/mouse movements to the remote SL client, and streams everything back.

Actually, it just needed the smallest amount of coding ever, a few fixes here and there, and that was 'it'. Probably the biggest issue with LL's solution is the requirement of paying a bit extra for a special Windows licence (included in the Amazon charges, obviously) on top of which the SL client is running. But LL is seriously considering to 'revive' the Linux client (it was never abandoned — after all, Firestorm, Cool VL Viewer, among many others, still support the Linux version, and that comes from LL's source code; it's just that LL ceased to give support to Linux, that's all; you can still compile it on your own and enjoy it fully), because — like Firestorm is able to do — this would enable them to save a few cents every time an SL viewer is spawned on AWS's cloud.

One fantastic advantage of this solution is that traffic between the client and the SL Grid happens at the blindingly fast speed of AWS' internal network. And, if I'm not mistaken, AWS doesn't charge anything for that, either — it means that, for all purposes, it's as if the remote SL client is on the same network as the Grid, without any throttling, jitter, or any other networking issues. That's why it can also start with a completely empty texture cache each time, but the overall texture loading speed remains mind-boggling fast — no wonder, if it's all inside the same cloud, physically in the same network, and so forth.

There is just the streaming exiting the AWS cloud, and that can be adequately controlled; what always astonishes me is the negligible delay between pressing a key and getting the remote client to respond, considering that my keystrokes have to travel 12,000 km at the speed of light to reach Amazon's cloud in Oregon (where allegedly most of LL's virtual servers are located).

That said, I'll be delighted to come back to this article in a decade again, and see what innovations have been implemented by LL that made all of the above totally and utterly obsolete.

And I imagine that even my 11-old Mac won't last another decade...