Would Second Life Benefit from an Engine Rebuild?

[MrBalloone]

Would Second Life benefit, If Linden was willing to do so, From a complete rebuild. Fixing the numerous problems with numerous aspects of SL. Like LSL. LSL, why doesn't LL allow the use of JavaScript, Python or what might be SL's codebase; C#, In addition to LSL (for compatibility). 

LL should do their best to dramatically improve SL, Since without such improvement, SL will keep declining in Active Users. A Rebuild of Second Life would reinvigorate interest in LL's platform, Giving Linden Lab more Resources and increased financial stability if something was to go wrong, like a recession. It would close any gaps in SL that competition could use to pull the metaphorical rug out from Linden's behind.  

So the question is, should Linden Lab rebuild SL? & would it be worth it for everyone involved?

Edited December 5, 2020 by MrBalloone
grammar

[Mollymews]

i think that this was the original impetus for Linden to begin the Sansar project. But as they got further into it, it ended up diverging quite a lot

altho the divergence had more I think to do with the choice of the VR headset as the primary interface than anything other one thing

the phrase "Like Second Life but better" at the time was I thought quite good and I was quite supportive of the effort, but it only ended up Like Second Life because it had avatars and stuff

i think that had Linden automagically ported Second Life accounts to Sansar for identity/login purposes (with L$ balance to follow) then the user uptake might have been higher, at least initially 

[MrBalloone]

17 minutes ago, Mollymews said:

i think that this was the original impetus for Linden to begin the Sansar project. But as they got further into it, it ended up diverging quite a lot

altho the divergence had more I think to do with the choice of the VR headset as the primary interface than anything other one thing

the phrase "Like Second Life but better" at the time was I thought quite good and I was quite supportive of the effort, but it only ended up Like Second Life because it had avatars and stuff

i think that had Linden automagically ported Second Life accounts to Sansar for identity/login purposes (with L$ balance to follow) then the user uptake might have been higher, at least initially 

I must agree, however with things like EEP it appears that Linden is trying to build on top of the now 17 year old Havok engine. It doesn't seem to be working well for them. Linden Should do two things. 

Internally Split into 2 teams. One team comprising the majority of the development resources will work on a true successor to Second Life, A Second Life 2.0, with a major leap in Graphics, Stability, GUI, Creative Process Improvements and a COMPLETE redo of the LSL language incorporating compatibility with JavaScript & Python, Incorporating the OG LSL to "grandfather" LSL based items & Improve on every single pitfall with second life. 

The Other team would work on the Legacy Second Life, Abandoning New features and Focusing on Stability, Performance, Reliability and compatibility.

SL 2.0 should stay true to SL 1.0 & incorporating the things that made SL a success, improving on said things. SL accounts should be Interchangeable, SL 1.0 would eventually be relegated to Backwards Compatibility once the New Second Life takes centre stage. All Avatars, Scripts, L$, inventories, Outfits, Preferences, etc, etc. would be unchanged. 

Finally Linden should Improve the front & backend, Upgrading Servers, increasing capacity. Personally I believe a good name for the reworked engine would be Nebula.

[Alwin Alcott]

3 minutes ago, MrBalloone said:

Upgrading Servers,

what servers?.. think you missed some of the latest happenings.

[Profaitchikenz Haiku]

They say fish don't see the water they swim in, maybe the gentleman doesn't see the clouds he moves through...

[Ardy Lay]

Build your own.

[Aishagain]

I see suggestions that we need an SL2.0.  Really?  LL tried that already, it was called Sansar and we all know how well THAT went!

Don't get me wrong SL WOULD be better if it was rebuilt around a new, better base programme.  The simple fact is that no one can or will spend the resource to make asset transfer between the "old" and the "new" SL possible, and as a result it is a non-starter.

[Profaitchikenz Haiku]

SL is now full of things people have created or purchased that they love and cherish. These things would have to persist into whatever replacement is being hypothesised. It's no good telling them that over that hill and beyond is the promised land that is filled with wonderful replacements for everything they're going to have to leave behind. The thing that stopped me trying Sansar was mostly that I couldn't take my stuff with me, and I couldn't make my own stuff there.

I can't see any commercial benefit to a major rewrite of SL that would have to focus a significant effort on simply supporting what we already have: small incremental improvements cost a lot less and could probably accomplish enough to keep people happy.

[bigmoe Whitfield]

17 year old havok?   it's not that old at all all, we went from prehavok, to havok 1, to havok 4 and now are 2012 or 2014,  one of the lindens might be able to chime in, I do know we are way onto mostly current havok libraries and engine code.

[Wulfie Reanimator]

For what it's worth; Mono, which is what the new iteration of LSL runs on, is C#.

Many years ago when LL was first implementing the Mono version of LSL, they were seriously considering to allow us to write scripts in C# and even showed us some relevant scripts. It can be done, and almost was, but it was never made available for reasons unknown to me.

I don't know about the "decline of active users" though, if I recall, SL has been surprisingly stable over the past few (3-5?) years. I might misremember, I think @Chaser Zaks had a website that tracked those statistics.

Edited December 6, 2020 by Wulfie Reanimator

[Qie Niangao]

1 hour ago, Wulfie Reanimator said:

For what it's worth; Mono, which is what the new iteration of LSL runs on, is C#.

Not exactly, although Mono comes with C#, as well as bindings to Visual BASIC and IL assembler. Third party language support in Mono includes LUA and JavaScript, and at one point while Babbage was still working on Mono those two were mentioned as possible alternatives to C#, but of course it's not as simple as merely exposing a language binding, but all the Linden library routines must be callable from any target language. (Oh, and Python too, because the OP mentioned it.)

You're spared my usual rant about how language is the very least of LSL's problems, but I have an analogous reaction to this thread: "engine" is the very least of SL's limitations, especially if all it means is Havok.

[Penny Patton]

17 hours ago, Aishagain said:

I see suggestions that we need an SL2.0.  Really?  LL tried that already, it was called Sansar and we all know how well THAT went!

Sansar failed for a number of reasons that boil down to LL fundamentally misunderstanding why Second Life managed to have the staying power it has. They failed to recognize the importance of avatar customization, dynamic world building, and, yes, even adult content, among other things. They also focused way too hard on the VR experience.

Personally, I still believe an "SL 2.0" could be successful, but whoever developed it would have to understand what works in SL, and what holds SL back. That said, I don't believe we'll see a next gen SL anytime soon.

[Ardy Lay]

(Not particularly directed at MrBalloone)  Seems to that whenever somebody comes in and starts saying Second Life Viewer should be ported so some new game engine they are overlooking the fact that Second Life Viewer does not currently use any game engine.  That abstraction level does not currently exist in Second Life Viewer.  The "Havok" is only used for physics in the Second Life Simulator and for mesh physics decomposition at the time of upload in the Second Life Viewer.  Viewers do not need any code from Havok if they do not upload mesh.  There may even be viewers uploading mesh without Havok code, by using alternative methods to accomplish the task.  I haven't looked.

I remember Andrew Linden telling a group gathered on Simon Linden's land in Second Life that he would like to see a new simulator written that still uses Second Life accounts and inventory.  He indicated that by very selectively leaving out support for a few very problematic types of content, other, more capable replacements could be provided.  I do not recall what types of content he had in mind.  He said the idea would be to design for performance first, then backwards compatibility second, where it does not compromise performance, then see what existing content got broken and decide what to do about it.  Some support could possibly be added for some particularly widely used content, if it doesn't compromise the performance too much.

Anyway, I think he thought he was going to get to do that sort of thing with Sansar but we all saw where Sansar deviated from the initial announced roadmap and ran off into the Aether to chase golden dreams and glittering generalities.

Edited December 6, 2020 by Ardy Lay

[bigmoe Whitfield]

1 hour ago, Ardy Lay said:

(Not particularly directed at MrBalloone)  Seems to that whenever somebody comes in and starts saying Second Life Viewer should be ported so some new game engine they are overlooking the fact that Second Life Viewer does not currently use any game engine.  That abstraction level does not currently exist in Second Life Viewer.  The "Havok" is only used for physics in the Second Life Simulator and for mesh physics decomposition at the time of upload in the Second Life Viewer.  Viewers do not need any code from Havok if they do not upload mesh.  There may even be viewers uploading mesh without Havok code, by using alternative methods to accomplish the task.  I haven't looked.

I remember Andrew Linden telling a group gathered on Simon Linden's land in Second Life that he would like to see a new simulator written that still uses Second Life accounts and inventory.  He indicated that by very selectively leaving out support for a few very problematic types of content, other, more capable replacements could be provided.  I do not recall what types of content he had in mind.  He said the idea would be to design for performance first, then backwards compatibility second, where it does not compromise performance, then see what existing content got broken and decide what to do about it.  Some support could possibly be added for some particularly widely used content, if it doesn't compromise the performance too much.

Anyway, I think he thought he was going to get to do that sort of thing with Sansar but we all saw where Sansar deviated from the initial announced roadmap and ran off into the Aether to chase golden dreams and glittering generalities.

sansar went "hey we are going to go this, make sure your accounts and stuff are working and build it like sl should of been" but then some one got a fork in the road and it went so fart right, that it was never retrackable to where it should of been.  

[animats]

1 hour ago, Ardy Lay said:

Seems to that whenever somebody comes in and starts saying Second Life Viewer should be ported so some new game engine they are overlooking the fact that Second Life Viewer does not currently use any game engine. 

That's correct. The LL viewer has its own networking system, its own marshaling system (three of them,  no less), its own database system, its own rendering system, its own HTTP system, its own cache system, its own 2D user interface system, its own futures system, its own math library... Most of those things are off the shelf parts today. They weren't 20 years ago.

UE4 wouldn't help much.  UE4 is all about preprocessing content when building a game level. UE5, maybe. It does more at run-time. Their LOD and animation engines are very interesting. We'll know more around mid-2021.

1 hour ago, Ardy Lay said:

He (Andrew Linden) indicated that by very selectively leaving out support for a few very problematic types of content, other, more capable replacements could be provided.

I wonder what those were. Inside the viewer code are special cases for "Demon", "Bird", and "Rock". Those, like Linden trees, are built-in objects. I wonder if any still exist in world.

[MrBalloone]

20 hours ago, bigmoe Whitfield said:

17 year old havok?   it's not that old at all all, we went from prehavok, to havok 1, to havok 4 and now are 2012 or 2014,  one of the lindens might be able to chime in, I do know we are way onto mostly current havok libraries and engine code.

Yes havok is 17 years old. Havok 2 and onwards are Updates, Revisions and Upgrades to the original Engine. Just like how every Rockstar game post-2006 is run on the RAGE engine, which was introduced in Rockstar Games Presents Table Tennis, You wouldn't think that RDR2 is running on the same engine, but it is. An Engine is only as good as it's Mechanics. An Engine that is maintained well, can last as long as it needs to. When it is Upgraded it doesn't mean that it is a brand new engine. If you put a turbo in your car, your engine while upgraded is still the same fundamental engine as before. When an Engine is Succeeded, It isn't by an Upgraded one but a completely brand new one.

[MrBalloone]

1 hour ago, animats said:

That's correct. The LL viewer has its own networking system, its own marshaling system (three of them,  no less), its own database system, its own rendering system, its own HTTP system, its own cache system, its own 2D user interface system, its own futures system, its own math library... Most of those things are off the shelf parts today. They weren't 20 years ago.

UE4 wouldn't help much.  UE4 is all about preprocessing content when building a game level. UE5, maybe. It does more at run-time. Their LOD and animation engines are very interesting. We'll know more around mid-2021.

I wonder what those were. Inside the viewer code are special cases for "Demon", "Bird", and "Rock". Those, like Linden trees, are built-in objects. I wonder if any still exist in world.

Well having all those aspects in-house certainly is applaudable and gives LL more control over the codebase But it could also be one of factors that causes SL's performance penalties. however couldn't the majority of that (together) still be classed as the game engine. Also LL would probably want to make the majority of the codebase in-house, to keep control and compatibility. The SL 2.0 that I have imagined would still be Second Life both in name and community, but underneath would be dramatically different. It wouldn't go unnoticed however as the service when you log on would be night and and day, it would be strikingly unfamiliar yet still familiar. It's Graphical User interface would be redesigned to be both Simple and Advanced. It would run smoothly and be compatible with older items and avatars. SL 2.0 would be the true successor, unlike Sansar which was more like a spiritual successor. All those Systems, Libraries, engines, etc. would be rebuilt & would simply be bundled as SL's engine. (I think Nebula would be a fitting name for this new engine as it Nebula is literally Latin for Mist. Something in the background that like glue, holds things together) 

[animats]

23 minutes ago, MrBalloone said:

 it would be strikingly unfamiliar yet still familiar. It's Graphical User interface would be redesigned to be both Simple and Advanced.

One approach would be to have User and Creator modes. In User mode, you have a clean screen, with very little 2D user interface. Switch to Creator mode, the 3D pane shrinks and toolbars appear around the 3D window.

[bigmoe Whitfield]

1 hour ago, MrBalloone said:

Yes havok is 17 years old. Havok 2 and onwards are Updates, Revisions and Upgrades to the original Engine. Just like how every Rockstar game post-2006 is run on the RAGE engine, which was introduced in Rockstar Games Presents Table Tennis, You wouldn't think that RDR2 is running on the same engine, but it is. An Engine is only as good as it's Mechanics. An Engine that is maintained well, can last as long as it needs to. When it is Upgraded it doesn't mean that it is a brand new engine. If you put a turbo in your car, your engine while upgraded is still the same fundamental engine as before. When an Engine is Succeeded, It isn't by an Upgraded one but a completely brand new one.

LL is not changing their underlying engine it took us years and years to get here, it works fine how it is, nothing needs done.   13 years here, trust me, you do not break what works. 

[Ardy Lay]

9 hours ago, animats said:

Inside the viewer code are special cases for "Demon", "Bird", and "Rock". Those, like Linden trees, are built-in objects. I wonder if any still exist in world.

Lindenworld leftovers

I doubt any survived the purge that occurred prior to the first Second Life beta period.

[MarissaOrloff]

Switching from OpenGL to Vulkan, possibly rewrite the engine to be multi threaded and take full advantage of the computers GPU (not the fractional amount it uses now) would be a great start to future proof the viewer. But I have no idea if that's technically possible.

Edited December 7, 2020 by MarissaOrloff

[Wulfie Reanimator]

24 minutes ago, MarissaOrloff said:

Switching from OpenGL to Vulkan, possibly rewrite the engine to be multi threaded and take full advantage of the computers GPU (not the fractional amount it uses now) would be a great start to future proof the viewer. But I have no idea if that's technically possible.

Sure it is. The viewer is just that -- a viewer. It receives information about the world and does something with it. Whether we use OpenGL or Vulkan (or none, for text-viewers) is just a matter of actually doing it. It doesn't have to be done by LL either, writing a good/stable renderer just doesn't happen to be easy, especially if you want the world to appear exactly the same. (Remember LL's stance on the shared experience and not breaking content.)

[MarissaOrloff]

Technically possible also includes financially possible as well!

[Qie Niangao]

It's not only the cost of developing and deploying a change, but also the share of revenue lost when users are left behind because, for example, their PCs are so old they can't handle Vulkan, which I gather LL found to be a scary large share of their customers. (I don't know whether they've decided what to do about that.)

[ETA: This from Inara Pey's blog:

Quote

• It now turns out that a rather high number of users (up to a 1/3 of all users) are running Second Life systems that do not have support for Vulkan (e.g. those 5+years old, and notably systems with Intel integrated graphics).

I'm realizing that my current PC might be over five years old. Not sure how to know if it would handle Vulkan, but may be a moot point anyway.]

Edited December 7, 2020 by Qie Niangao

[Love Zhaoying]

On 12/5/2020 at 6:17 AM, MrBalloone said:

Would Second Life benefit

No.