Oculus Go - what's the LL strategy?

[animats]

The Oculus Go VR headset came out yesterday, priced at $200. Any response from Linden Labs?

[Callum Meriman]

It's a snapdragon 821 Animats, SL doesn't run on ARM tech.

(Edit: At best this device will let Facebook harvest what sort of VR-Porn the wearer enjoys, and possibly play a few simple phone-quality games like Clash of Clans)

Edited May 3, 2018 by Callum Meriman

[Klytyna]

51 minutes ago, animats said:

The Oculus Go VR headset came out yesterday, priced at $200. Any response from Linden Labs?

1. See Callum's post above...

2. They already said, some time ago, that SL's UI is inherently unsuitable for Vomit-Cam, that's why they dropped the Vomit-Cam Project Viewer.

3. Nobody gives a damn.
 

[Coffee Pancake]

6 hours ago, animats said:

The Oculus Go VR headset came out yesterday, priced at $200. Any response from Linden Labs?

Oculus Go is a Samsung Gear VR with an integrated screen and second gen optics. It provides access to the same limited mobile VR portal and apps. 

It can not be used with a PC, streaming VR might be technically possible via VRidge .. but of little practical value - the only experience you are guaranteed involves nausea and a thumping headache.

It's a fair entry point into stand-alone VR and maybe a nice way to watch a movie or experience a scenic location or the odd simple game.

[animats]

Today, Facebook announced Half Dome, their prototype next-generation VR headgear. Things are picking up in this area.

[Qie Niangao]

Half Dome is interesting for the extent to which it further degrades prospects for Magic Leap.

Oculus Go, on the other hand, is pretty yawn-worthy. Oculus should have had something in that part of the VR market years ago and this is a disappointing also-ran, but with Facebook's deep pockets, it may not matter. (On the other hand, with Facebook's other problems, its VR dabbling is looking pretty silly.)

The rumors around Apple's headset plans are confusing, so it's hard to know whether to ascribe to them much hope of a VR market revival. They might be AR only -- sorta Google Glass with more visual field and a design for mass appeal -- and developers say ARkit is well behind the curve. (Which reminds me: we can measure VR/AR's market prospects by how much attention they get in the developer features and talks in Mountain View next week.)

And yet, however disappointing the VR market has been, it's way bigger than SL's market. Meanwhile SL has 3D social content more sophisticated and extensive than anything else out there, so it seems like a natural fit -- surely more compelling than building a whole new, empty platform and hoping players will emerge from the cornfields. If there is an opportunity there,  the Lab won't do anything about it until they make it to the "acceptance" stage of grief for Sansar.

I'm guessing LL viewer developers are desperately hoping some third party will see past the smoke and build a high-end VR viewer for SL. 

Edited May 3, 2018 by Qie Niangao

[Callum Meriman]

2 hours ago, Qie Niangao said:

the Lab won't do anything about it until they make it to the "acceptance" stage of grief for Sansar.

They are - sadly - still at the sunk cost falacy stage.

When it hits home there are normally just 15 concurrent users then Ebbe might progress though the other stages.

[Bree Giffen]

The OcGo can't work with SL because VR needs high frame rates or else it causes nausea when moving around. SL is of course an un-optimized lag fest. Non-moving 360 degree snapshot photos could possibly work. Maybe a special SL viewer that loads everything within a small draw distance, and nothing beyond that, would make it possible to have a small slice of SL with very fast frame rates.

[Coffee Pancake]

7 hours ago, Qie Niangao said:

And yet, however disappointing the VR market has been, it's way bigger than SL's market. Meanwhile SL has 3D social content more sophisticated and extensive than anything else out there, so it seems like a natural fit -- surely more compelling than building a whole new, empty platform and hoping players will emerge from the cornfields. If there is an opportunity there,  the Lab won't do anything about it until they make it to the "acceptance" stage of grief for Sansar.

I'm guessing LL viewer developers are desperately hoping some third party will see past the smoke and build a high-end VR viewer for SL. 

SL is not suited to VR. Not even a little bit. It requires complex interactions with the end user, it is heavily CPU bound processing asset management, the lack of a static environment prevents the render engine dancing like a game engine.

LL did make a VR SL viewer. It was beset by problems that were fundamental to the basic platform operation of Second Life. To resolve these issues would mean drastic changes to the product as presented to end users. This is why Sansar is very much not Second Life.

really, applications fort VR have to designed from the ground up.

32 minutes ago, Bree Giffen said:

SL is of course an un-optimized lag fest.

This is not the reason. SL is very optimized. Lag and poor render performance have their roots in fundamental aspects of the service, and changing those aspect of the service would change Second Life in ways we would not be prepared to accept. Second Life's founding strengths are also it's biggest weaknesses, there are some very good reasons that it has no like for like competitors that aren't direct clones of the service dependent on LL's own open source technology - No one else is daft enough to make this mess on purpose!

[Qie Niangao]

44 minutes ago, CoffeeDujour said:

SL is not suited to VR. Not even a little bit. It requires complex interactions with the end user, it is heavily CPU bound processing asset management, the lack of a static environment prevents the render engine dancing like a game engine.

It seems to me that the challenges posed by SL represent baby steps towards the kind of intensely dynamic interactivity we're let to expect we'll be doing in AR in a few years. I do see an architectural hurdle in the volume of data assumed to stream in real time over the network, but even so, we're led to expect virtual interpersonal interactions that will gobble orders of magnitude more bandwidth with even tighter synchrony requirements. So if even little SL is asking too much, the promised tomorrow is very far away.

If all we can expect is gaming, AR/VR tech really isn't worth following.

[ChinRey]

53 minutes ago, CoffeeDujour said:

This is not the reason. SL is very optimized.

No, it's not actually. With well optimized, efficient content, it's fairly easy to make scenes more complex and rich than the average SL scene and still keep the gpu load low enough a high end gaming computer can easily manage 100+ fps. The gpu load in SL is twenty percent what you have to accept in any virtual reality simulation, ten percent inevtiable because of SL's unique qualities, twenty percent due to poorly optimized software and fifty percent due to poorly optimized content.

When it comes to the poorly optimized software, the standard excuse is that SL is so old. That's understandable of course and nobody would be rude enugh to point out that UE (the cutting edge top dog graphics engine today that leaves both SL and Sansar so far behind it's not even funny) is five years older.

As for poorly optimized content, the standard excuse is that everything is made by happy amateurs who only do it for fun and don't make any money from it.

But with all that being said, SL also has - and needs to have - some fairly complex interaction between server and client. That puts a lot of strain on cpu and bandwidth, especially for those who live far away from west coast USA. There's no easy solution to that, not even in theory, and it may well be enough to make SL unsiutable for VR headsets regardless of the gpu load.

[ChinRey]

6 hours ago, Callum Meriman said:

When it hits home there are normally just 15 concurrent users then Ebbe might progress though the other stages.

Sorry for posting two replies in a row here but, Callum, are you seriously saying the Sansar concurrency is that low???

[Coffee Pancake]

31 minutes ago, ChinRey said:

No, it's not actually. With well optimized, efficient content, it's fairly easy to make scenes more complex and rich than the average SL scene and still keep the gpu load low enough a high end gaming computer can easily manage 100+ fps. The gpu load in SL is twenty percent what you have to accept in any virtual reality simulation, ten percent inevtiable because of SL's unique qualities, twenty percent due to poorly optimized software and fifty percent due to poorly optimized content.

You're misunderstanding how SL differs from a game engine and the huge impact that has on the resulting final performance. Games engines work to a a very simple premise. The scene being rendered, no matter how large or complicated, is static. The number of dynamic objects in a scene is limited. This is also true of Sansar. Game engines get to pre-calculate lighting, occlusion and dump everything onto the GPU .. which is tailored specifically to work with this kind of load. This alone can result in rendering that is an order of magnitude faster than SL for an identical scene.

SL on the other hand has to treat every single object as dynamic, anything can get up and move at any time, prim geometry can be manipulated between frames. Lighting and occlusion have to be calculated in real time, the GPU has the CPU holding it's hand .. and it's just not as good. 

SL's graphics performance woes are entirely due to the unique nature of the platform. It's more akin to realtime 3D vis than game rendering.

It is certainly not because "the render engine is old". Just because the platform has been around for 15 years does not mean nothing has changed.

 

The client has been open source for a long time now, and in all those years, none of us involved with viewer dev have replaced the render engine, and it's not for lack of skill .. remember that materials was created with substantial contributions from TPV devs.

The source code is public, if you feel you can do better, by all means - LL would be VERY receptive to such a project.

[animats]

36 minutes ago, ChinRey said:

No, it's not actually. With well optimized, efficient content, it's fairly easy to make scenes more complex and rich than the average SL scene and still keep the gpu load low enough a high end gaming computer can easily manage 100+ fps....

When it comes to the poorly optimized software, the standard excuse is that SL is so old. That's understandable of course and nobody would be rude enugh to point out that UE (the cutting edge top dog graphics engine today that leaves both SL and Sansar so far behind it's not even funny) is five years older. ...But with all that being said, SL also has - and needs to have - some fairly complex interaction between server and client. That puts a lot of strain on cpu and bandwidth, especially for those who live far away from west coast USA. There's no easy solution to that, not even in theory, and it may well be enough to make SL unsuitable for VR headsets regardless of the gpu load.

Yes. Much of SL's graphics load is unnecessary. Every object hidden inside a building within draw range gets sent to the graphics card and rendered at some level of detail. It goes all the way through the rendering pipeline and then is thrown out at the end, at the Z buffer. The viewer has no notion of "inside". SL needs some automated system that wraps a textured box around distant buildings, parcels, and entire sims, then skips drawing the insides of the boxes. That would get the frame rates way up. As Chin points out, Unreal Engine does stuff like that. This is all well-known game technology.

SL doesn't have that much interaction between server and client. Avatars are bounding boxes to the sim. Object movement updates are a minor part of traffic. Viewer to server traffic is mostly keystrokes and mouse moves. Most network traffic is pumping geometry and textures out to the viewer, and most of that comes from the CDN that stores textures and geometry.

The big problems sim-side seem to be from some design decisions that made sense in 1999 but are way out of date. Back then, the typical server had one 32-bit CPU and maybe 512MB of memory. Multi-threading was not a win. Today, you get at least 8 CPUs on a server, and more if you want them. SL can't use such hardware effectively. Amazon AWS will rent you 112 CPUs and 2TB for $4 per hour. If SL could use that hardware effectively, Fashion Week and big events would just fly.

Technically, what's probably needed sim side is a division into "motion control" and "object management". Motion control has the physics engine, gets the incoming actions on objects, outputs object updates, and that's all. Motion control sees only physics geometry - it knows nothing about textures or more complex geometry. It's hard real time and has priority over the rest of the system. "Object management" does everything else. If object management lags, it's not as visible. Running on multiple CPUs, an SL divided that way could handle far more users in a space.

If SL had a growing user base, all this would be worth doing. For a shrinking user base, why bother? That's why this isn't happening.

[Coffee Pancake]

37 minutes ago, animats said:

If SL had a growing user base, all this would be worth doing. For a shrinking user base, why bother? That's why this isn't happening.

That and the lab wont do anything that breaks old content .. no matter how old.

[ChinRey]

2 hours ago, CoffeeDujour said:

You're misunderstanding how SL differs from a game engine and the huge impact that has on the resulting final performance. Games engines work to a a very simple premise. The scene being rendered, no matter how large or complicated, is static. The number of dynamic objects in a scene is limited. This is also true of Sansar. Game engines get to pre-calculate lighting, occlusion and dump everything onto the GPU .. which is tailored specifically to work with this kind of load. This alone can result in rendering that is an order of magnitude faster than SL for an identical scene.

You're right. Make it 20 percent caused by the unique properties of SL.

But those percentages were just to illustrate my point of course and the point is that in almost every SL scene there are far more texture pixels, vertices and triangles than are necessary to render the visuals. Get rid of that overhead and a high end gaming graphics card will have no problems keeping a steady fps well into the hundreds, enough to run a VR headset.

Unfortunately, the only way I could prove it would have been to buy a sim and spend a month or so building optimized content from scratch (since there's hardly anything of that available off the shelf) and I can't imagine anybody are willing to pay for that - I sure won't.

It's easy enough to get an indication what I'm talking about though. Check the triangle, vertice and pixel counts of various objects and how they affect your fps. Then examine a typical scene thoroughly and look at all the pixels and vertices and triangles that add nothing whatsoever to how it looks: Sculpts using only a handful of its 1024 vertices, meshes so dense they look solid in wireframe mode, surfaces and textures hidden inside other objects, tiny objects with 1024x1024 textures, baked textures using only a fraction of the UV map, duplicate textures, cube prims with four vertices along each edge (no wait, that is actually a software flaw, not the builder's fault), rogue alphas, sculpts and meshes with LoD so poor they force you to increase your LoD factor, ridiculously detailed meshes (how about a house where the holes in the power outlets are made from highly detailed mesh?) etc., etc.

Most of it is of course culled out before it reaches the end of the render pipeline but it still gives both the gpu and the cpu a lot of extra work downloading and sorting out all that excessive data. Even today, the fastest cpus on the market can manage 100+ fps in SL under good conditions and it doesn't actually take much before they can do it consistently.

Not regular cpus though. That would be asking for too much. And of course, if the scene is filled with mesh avatars, the fitmesh LoD bug will ruin it all.

 

2 hours ago, animats said:

If SL had a growing user base, all this would be worth doing. For a shrinking user base, why bother? That's why this isn't happening.

It's a bit more complicated than that. If Linden Lab had started taking client side performance seriously in 2004 rather than 2014 and done what was necessary to ensure the best possible experience for the widest possible user segment, SL might still have been growing, it might still have been sexy and attractive to new users. But that train left the station long ago and it might not have been enough anyway.

Today I think it's far more important for LL to keep their old customers as long as possible than to try to recruit new ones. And that means keep loading it down more and more because the old-timers want a steady stream of new shinies or they get bored and leave, and those shinies are come at a cost.

Edited May 3, 2018 by ChinRey

[animats]

32 minutes ago, ChinRey said:

Today I think it's far more important for LL to keep their old customers as long as possible than to try to recruit new ones

LL's CEO, Ebbe Altberg, seems to agree with you. Although he talks about "growth", he doesn't really seem to believe SL can grow in usage again. Nothing he talked about seems aimed at new user acquisition or retention. The big new feature is last names, which is pathetic.

I still wonder if VR is going anywhere. It could be the next 3D TV. Works fine, too much of a hassle, nobody cares. There's heavy industry interest because there's no other Next Big Thing in sight in consumer electronics. That doesn't mean it will be a success.

[ChinRey]

51 minutes ago, animats said:

LL's CEO, Ebbe Altberg, seems to agree with you.

That only means he's sensible.

Seriously, yes I get the same impression too. I really feel sorry for poor Ebbe. He took over a sinking ship and has performed miracles to keep it afloat. But when it finally goes down, he's probably the one who gets the blame.

 

51 minutes ago, animats said:

Nothing he talked about seems aimed at new user acquisition or retention.

He did mention something about marketing SL to DJs. That's not a bad idea at all. If we only could come up with 10,000 more such ideas, everything would be fine.

 

51 minutes ago, animats said:

The big new feature is last names, which is pathetic.

No, it's spot on. It doesn't cost anything - it actually gives LL a nice little extra revenue stream - and the old-timers love it. The fact that more recent Residents and newcomers couldn't care less doesn't matter since it doesn't do us any harm either.

And, perhaps most important, SL does actually have serious growth potential in one field: former SL'ers. It's very likely many of those will want to return to the passtime of their youths as the kids grow up, family life takes less and as the nostalgia level raises. Those guys are used to having a "proper last name" and may not be happy about joining the big Resident family.

Edited May 3, 2018 by ChinRey

[Klytyna]

3 hours ago, animats said:

Much of SL's graphics load is unnecessary. Every object hidden inside a building within draw range gets sent to the graphics card

You know and I know that if you put a statue of a sad clown inside a windowless concrete bunker, people outside the bunker cannot see the sad clown...

Rendering engines such as that found in SL, do NOT know this. They have to work it out, where is the "camera" and where is the "sad clown", what if anything is in the way, ah, "concrete bunker", ok this "concrete" is it see through?

Then it has to check the texture on the concrete, and whoops, some talentless clown uploaded their solid concrete wall texture as a damn 32 bit rgba, so the rendering engine has to check PIXEL by bloody PIXEL to see if any of the concrete is see through, and if so, is that see through bit the bit between the "camera" and the "sad clown".

Then theres's the "de-rendering" problem, what if the user de-renders the "concrete bunker" then it's invisible and everyone can see the "sad clown"

Nature of the SL environment, can't be helped. Game engines can avoid this because game content isn't anything like as dynamic.

3 hours ago, animats said:

The viewer has no notion of "inside". SL needs some automated system that wraps a textured box around distant buildings, parcels, and entire sims, then skips drawing the insides of the boxes.

Very few computerised systems have a viable definition of "inside", and even if SL did have some miracle code that let it identify "inside", that still wouldn't help with the whole "something in the way, is any of it see through" problem.

Onew ofthe WORST prim builders I ever met in SL, loudly stated that she was reducing lag (that she never experienced because her pc was 'leet') by putting up walls to block the view of the many objects outside the landing area...

The dumb fool never accepted that her blocking walls with 32 bit rgba textures set to alpha blend MADE more lag then they removed.

3 hours ago, animats said:

Unreal Engine does stuff like that. This is all well-known game technology.

Yeah it's GAME technology, static environment. You need to stop thinking of SL's engine in tewrms of "standard issue "all the content pre downloaded on your drive" 30 gb only computer games. SL isn't that, never can be, never will be.

Everything in your SL environment could change at any time, appear, disappear, change colour or texture or shape, or size, or anything, at any time. You could download 10's of gb of data just because you saw a bunch of people wearing new skins, and new clothes, and new hair, while you were driving around past some new Madlands housing project.

Hell, this Bake-Fail-on-Mesh rubbish, where the bake servers have to resend 3 1024 x 1024 textures EVERY SINGLE TIME anyone in your draw distance adds or removes a system layer, is going to push bandwidth up.

Have you ever stopped to consider how much bandwidth you actually use being in SL

6 years ago when I was on a lot more, I was typically using 1 gb a night, for the textures of the system avis that wandered past me, and for the builds I wandered past. That means your graphics load in a single month involves more mesh data and texture data than most of the "computer games" you are comparing it to, install at all.

People need to STOP thinking of SL as just another game, that can be magically fixed with game technology, SL is radically different in structure, and you are 14.5 years too late to cripple it into "just a game engine".

Why do you think LL decided to spend 4 years mucking about making Project Stupid, rather than spending 4 years ripping the guts out of SL to make it Vomit-Cam compatible?

 

[ChinRey]

5 minutes ago, Klytyna said:

Why do you think LL decided to spend 4 years mucking about making Project Stupid, rather than spending 4 years ripping the guts out of SL to make it Vomit-Cam compatible?

You gotta love Klytyna's subtle arch-English style of understatement. It's always so gentle and discreet, yet somehow she still manages to get her point through.

[ChinRey]

1 hour ago, Klytyna said:

Hell, this Bake-Fail-on-Mesh rubbish, where the bake servers have to resend 3 1024 x 1024 textures EVERY SINGLE TIME anyone in your draw distance adds or removes a system layer, is going to push bandwidth up.

Three textures? I'm afraid you're overdoing your understatements there. There's the skirt layer texture too remember. They are planning to use that to make room for separate textures for each arm. And...

Let me tell you the a story from (virtual) reality:

A while ago I happened to meet Arton on his way to one of those idle chat lagfests LL holds a couple of times a week. Usually I try to avoid those but I was just procrastinating in a sandbox so I decided I might as well hop along. One of the Lindens - I think it was Oz but it's hard to say when it's voice chat - told us about the clever skirt layer trick, then he went on to talk about 1024x1024 pixel textures for the eyes. He wasn't sure if that plan was still on but they had been discussing it seriously. I left shortly after that. I decided procrastinating in a sandbox was a far more fruitful way to spend my time and besides, I was a bit afraid whatever they had caught might be contagious.

Edited May 3, 2018 by ChinRey

[Penny Patton]

A part of SL's performance woes comes from the fact that so many SL users know a little bit about how game rendering works. Ever hear the saying "a little bit of knowledge can be a dangerous thing"? If you only know a little bit about a topic, you can easily jump to the wrong conclusions. 

Yes, videogames have features like pre-rendered light maps and object culling that simply aren't feasible in SL, but this is not the whole reason performance in SL is so bad.  The fact that so many game optimization tools are not feasible in a dynamic environment like Second Life only makes optimization MORE important. This is why you DO see startling improvements to rez times and framerates in Second Life when visiting sims designed by people who understand that importance.

[ChinRey]

55 minutes ago, Penny Patton said:

A part of SL's performance woes comes from the fact that so many SL users know a little bit about how game rendering works..

I don't know why but for some reason the term "cargo cult" springs to mind here.

[Callum Meriman]

7 hours ago, ChinRey said:

Sorry for posting two replies in a row here but, Callum, are you seriously saying the Sansar concurrency is that low???

I'm not, wagner james au is.

http://nwn.blogs.com/nwn/2018/04/sansar-social-vr-linden-lab-user-numbers-concurrency.html

See how the bulk of the line is 15 people, with spikes to 40-ish.

Recent-ish Daily Averages

 

Edited May 4, 2018 by Callum Meriman

[Coffee Pancake]

Well .. disabling that API is going to be the Lab's next step.

Those numbers are damming .... from the perspective of a Second Life user where online concurrency can easily be all day every day.

Sansar is a different platform. Creation is not done in Sansar, just assembled. VR by it's very nature is a short duration, I very much doubt anyone is sitting with a VR hat on for more than 4 hours at a time. Almost none of the social tools are in place. There is simply no much to do ... yet.

I think in part this is more about the Labs failure to manage expectations, they have never been really clear what the intended use case for Sansar actually is and just kind of opened the doors to see what people would do.

Although they have been fairly clear about one thing, we are not really it's target audience.