Community Ideas For Moveing SL to an modern engines (Unreal Engine Or Unity 3D)

[CrazyLaraCroft]

Hello Second Life Community and Linden Lab's Staff i have a question about modernize The Second Life World to a more modern engines and if itcould be possiable one day in the future or something along those lines 

[Mollymews]

according to the SLB19 Linden conversation summaries then the answer is No, not on any forseeable roadmap at this time

if you do want to see how a different engine can work-ish then have a look at this OpenSim project here

https://github.com/opensim/opensim-viewer

which is built on the Stride/Xenko engine found here

https://www.stride3d.net/blog/xenko-opensource-mit/

 

[Bree Giffen]

What exactly would be necessary to switch over to a new engine? Is it difficult?

[Artorius Constantine]

I've built games in UE4 and really don't see any way to take all the user created content and easily remake it into a format UE4 (or UE5) would accept. That's the biggest issue. You would have to migrate every script that exists written in lsl and other SL exclusive format objects and user created mesh objects and transmute it all into the billions of files that would be cross compatible.

Considering the sheer number of things users have created I don't see that happening anytime soon.

Not that it wouldn't be great to see. UE5 although, is beyond my PC's power and I hope they don't get that high end with it.

Edited June 30, 2022 by Artorius Constantine

[Sprout Evergarden]

moving to a new engine would be completely impossible closest they could ever do is move the client to a new Graphics library which is an inevitability given the fact that ever Modern GPU vender is deprecating OpenGL

[Jenna Huntsman]

I doubt that SL would move in that direction, simply because it would likely mean breaking a lot of legacy content, which LL just does not want to do, even with the existing engine.

The most likely thing to happen is modernization of the existing engine, for example the upcoming PBR implementation, and somewhere further down the line swapping over to another graphics API (most likely Vulkan).

if LL went down the road of swapping over to a new engine, I'd have thought they'd move towards using Godot as it's a very well supported open-source game engine, as opposed to Unity and Unreal which are both closed-source.

[bigmoe Whitfield]

user created content is the whole reason LL is not moving.  

[animats]

I've written about this before, and I have a video here, which many of you have seen, of SL content with a completely new renderer.

So why isn't LL doing this? I've talked to a few people on the Linden and Firestorm side.

• It's high-risk. There's much bleeding edge technology involved. I'm using Rust (the language, not the game), WGPU (which supports cross-platform graphics using Vulkan or Metal as needed), Egui (which does the 2D menu part), and Winit (which does cross-platform windowing for Linux, Windows, and Mac). None of this is mature technology. I'm in regular communication with the devs for those projects and have bug reports and feature requests in their queues. There's an active Rust game development community trying to get the tooling finished, but you can't base your main business on that stuff yet. There are no AAA titles in Rust as yet, despite a few starts. On the other hand, there is much pre-built lower level machinery, even if it's not perfect. The SL viewers have their own everything - their own renderer, their own networking, their own cache management, their own file formats. You had to do all that custom in 2001.
• You're going to need a gamer-level GPU with at least 6GB in the GPU to run this well. My goal is to make SL and Open Simulator work like AAA titles on machines that can run modern AAA titles. The average Steam user has the hardware for this, but the average SL user does not. Go look at the SL recommended hardware list. Everything there is at least a decade old and no longer manufactured or supported. I figure the hardware will become cheaper, and I'm looking ahead. LL can't afford to make that assumption. There was a recent announcement that LL is working on a "cloud gaming" option, where you rent server time to run the viewer and just ship video to the user. This works, and it's a way to get SL on mobile and Chromebook-class machines. But you have to pay a monthly charge of $10 - $25 per month for the gamer PC you're renting in some data center. That may or may not be a viable business model.
• UE5 and Unity have very elaborate content creation and polishing tools. Artists create art in Blender, Maya, etc. Game devs then work with that content, optimize, and polish, and then create output files. There's a fundamental assumption with those systems that you're using their desktop tools. If you buy into the UE or Unity ecosystem, you have to do things their way.
• Many SL viewer side problems aren't renderer-based. Asset loading and management are big problems. Plus there's the whole social side - group messages, notecards, and all that.

LL is working to increase viewer performance. The new "performance viewer" is in test. That's mostly low-level graphics tweaks, plus more concurrency in image decompression. (A huge fraction of viewer time goes into decoding JPEG 2000 images.) The asset loading order problem, where you wait and wait and wait for some image to load, is mostly because Project Interesting was never finished viewer side. There's a forgotten LL project viewer where one can see the remnants of an attempt at properly prioritized asset loading.

More generally, all this can make SL look better, but not more fun. The fun part is really hard.

 

 

[Chic Aeon]

I agree that created content is the biggest issue. And from a creator point of view it would be a game killer for many to most. I tried for weeks to work in Unity == with help from devs on the platform involved. All I got was frustration and the Unity software taking over my computer in a very nasty way. I talked to several other long-time creators who had come and gone to said platform and they agreed that they hated to work in Unity and that is why they left the platform.   The only people that actually stayed were ones that had been working in Unity for years and of course some folks that DIDN'T create :D.   

 

LL has already taken their big risk for this century I think. And on a more wide angled view of the topic -- it really is the people and the community that makes a platform work, much more than the engine. 

[Coffee Pancake]

11 hours ago, Bree Giffen said:

What exactly would be necessary to switch over to a new engine? Is it difficult?

sadly yes

The problem isn't the content or what's being asked to render. SL content is no more complicated than the stuff you can see in triple-A game titles, it might not tick all the "professional quality" or "streamlined" check boxes, but there is nothing inherently bad about the content itself.

it's all the processing and mess that has to happen to decode the content and get it into a fit state to be rendered. Game engines are typically spoon feed perfectly ready content so all they have to do is worry about rendering and a tiny amount of game control logic. We have a huge mess to unpick every frame and then only after all that's done, does the render engine get a crack at making it pretty.

Games very intentionally don't work the way SL works, and you can't change how SL works without loss of "SL defining" features and capabilities.

EG You could just take a static scene from SL and dump it in a game engine and it would be fast and beautiful .. but the ability to dynamically rez something never seen before gets lost.

As computers have gotten more powerful, it has become more feasible to get a game engine to do pretty rendering and all the processing guff and not completely implode, so I wouldn't rule out someone managing to jam a square peg in a round hole, I just wouldn't expect it to perform even close to the engines full capability.

 

Looking at it from the other direction, there are also other things that SL does that aren't the same such as how physics are calculated. SL is entirely server side, games will do that locally as it makes things far more responsive. It's entirely possible to dump and recreate game content in SL, but it's almost impossible to make SL feel like the original game.

[CrazyLaraCroft]

thank you everyone for these who gave feeback on the Topic 

[Codex Alpha]

14 hours ago, CrazyLaraCroft said:

Hello Second Life Community and Linden Lab's Staff i have a question about modernize The Second Life World to a more modern engines and if itcould be possiable one day in the future or something along those lines 

It was called Sansar but was rejected by SL users.

I and 5 other people in my network did not reject Sansar.

Edited June 30, 2022 by Codex Alpha

[Coffee Pancake]

1 minute ago, Codex Alpha said:

It was called Sansar but was rejected by SL users.

It was rejected by everyone, regardless of them being from SL or elsewhere.

[Nalates Urriah]

13 hours ago, Bree Giffen said:

What exactly would be necessary to switch over to a new engine? Is it difficult?

You have read the answers. Animats got into a bit of the tech issues. Coffee explained a bit of the viewer side. But the shear size of SL and the massive inventory multiply the problems by orders of magnitude.

Years ago Andrew Linden asked the operating team how big the asset database was. At the time it was about 200+ terabytes. It grows every year.

Coffee mentions the complications of taking all the stuff and preparing it for render. But there is also the amount of interaction that has to happen between the asset database and render and physics engines which has to be coordinated. Most games just grab what they need from the computer's hard drive or a local DVD. Handling this coordination problem is woven through the server and viewer code. So, swapping out the render and physics engines is a massive task that touches every part of the SL system.

The decision to build Sansar was made because it was easier and cheaper to build a whole new system than attempt to upgrade SL to a render engine that could provide VR level performance.

My personal thinking on Sansar's failure is that they tried to control the developers so Sansar would have a socially acceptable environment. That resulted in fewer developers building for Sansar. Those that were, built the things that interested them. Since moving from place to place in Sansar was so hard and slow developers seemed develop self contained environments. No need to teleport. Which resulted in small... tiny communities.

[Love Zhaoying]

1 hour ago, Codex Alpha said:

I and 5 other people in my network did not reject Sansar.

I hope the maximum concurrent user count is > 6!

[ChinRey]

22 minutes ago, Nalates Urriah said:

Since moving from place to place in Sansar was so hard and slow developers seemed develop self contained environments.

Yes, I think this is one of the main reasons, maybe even the Main Reason, Sansar could never be a replacement for Second Life.

Mobility is an overlloked but immensely important aspect of SL/OS and maybe the one that would be most difficult to replicate on any other platform. Yes, we can complain about sim crossing and teleport problems and delays but imagine if it took not one minute but five or even ten to tp to that club you got an invite to or that romantic private space you wanted to share with your newfound best friend.

I think transfer time is also the big challenge for any future metaverse and one none of the current candidates seem to have even recognised yet.

[animats]

2 hours ago, ChinRey said:

I think transfer time is also the big challenge for any future metaverse and one none of the current candidates seem to have even recognised yet.

Interesting.

There's a class of metaverse system I call "game level loaders". When you go someplace, you wait while it downloads a game level, and then you're viewing locally stored content with good performance. Examples are Sansar and Sinespace. Unless you have gigabit fiber, you spend a lot of time looking at Loading...

Right now, non-SL metaverses come in three flavors - game level loaders, low-rez (Decentraland, Cryptovoxels), and voxel systems (Dual Universe, Minecraft). Nobody yet has user content, big, looks good, and runs fast in one system. Roblox, Improbable are working on that.

From my own work, It looks like we can  get all four for non avatar objects, for users with reasonably good game PC hardware. Avatars, though...

 

[CaithLynnSayes]

I've seen this debate a lot and it always has the same (correct) answers. SL is user content, so having to change all that is too hard to do. I get that but this limitation (amongst others) will eventually make SL in it's current form just too old. You can't keep patching it forever. It comes with the nature of how SL is, and its age.

[Love Zhaoying]

20 minutes ago, animats said:

Interesting.

There's a class of metaverse system I call "game level loaders". When you go someplace, you wait while it downloads a game level, and then you're viewing locally stored content with good performance. Examples are Sansar and Sinespace. Unless you have gigabit fiber, you spend a lot of time looking at Loading...

Right now, non-SL metaverses come in three flavors - game level loaders, low-rez (Decentraland, Cryptovoxels), and voxel systems (Dual Universe, Minecraft). Nobody yet has user content, big, looks good, and runs fast in one system. Roblox, Improbable are working on that.

From my own work, It looks like we can  get all four for non avatar objects, for users with reasonably good game PC hardware. Avatars, though...

Kind of cool how we are "spoiled" that it only takes a minute or so to load a whole "world" for Second Life.

[animats]

Something needs to be done to create more efficient avatars for everybody you're not face to face with. SL has beautifully detailed avatars. As one creator tells me, only slightly joking, it's essential SL functionality that you be able to count the facets on the jewels in someone's jewelry. Really. If the eyelets in your boots aren't 3D modeled, the product is inferior. The trouble is, all that detail is being processed every frame for everybody in the room, not just someone close enough to touch.

Good SL clothing is often created in Clo or Marvelous Designer, programs which are intended for Hollywood and the real-world rag trade. You can almost zoom in close enough to critique the stitching. All that data needs to be squeezed down to game-level models for avatars other than the two or three to which you are closest, if we want to not have SL choke every time there's a crowd. Fixing this requires solving some problems that result in SIGGRAPH papers and PhD theses. However, there's now enough work going on in this area, at places such as Roblox, that the theory is advancing. Some of the areas that need work are:

• Better mesh reduction. Which is really hard for thin objects such as cloth. Most of the algorithms are terrible on thin objects. The new mesh reducer in the uploader is an improvement, but it's still basically the same as limited dissolve in Blender. There are better mesh reducers, such as Simplygon and the new one in Unreal Engine 5. (I tried out some mesh reducers once. They come in three flavors: bad, expensive, and brittle. By brittle, I mean academic code which breaks on imperfect mesh.)
• Mesh to texture conversion. Close up, the ruffles on the dress, the eyelets on the boots, and the wrinkles in the T-shirt are 3D mesh modeled. Further away, those need to become automatically generated textures that have the normals from the original but are mostly flat surfaces. SL's separation of textures from meshes kills off that class of optimization possibilities. It may be necessary to rethink that separation.
• Layering. When you get dressed in SL, there are many triangles hidden by outer layers that are no longer visible. They still get drawn, and waste CPU and GPU resources. What's needed is something where, when you get dressed, all the mesh layers get baked down to a simplified game-type model. Roblox is now doing this. Layered clothing used to be unique to SL, but it's going mainstream. This means there will be technology to license or copy.

Systems such as Epic's Metahuman begin to address these issues.

Edited June 30, 2022 by animats

[bigmoe Whitfield]

6 hours ago, Nalates Urriah said:

You have read the answers. Animats got into a bit of the tech issues. Coffee explained a bit of the viewer side. But the shear size of SL and the massive inventory multiply the problems by orders of magnitude.

Years ago Andrew Linden asked the operating team how big the asset database was. At the time it was about 200+ terabytes. It grows every year.

Coffee mentions the complications of taking all the stuff and preparing it for render. But there is also the amount of interaction that has to happen between the asset database and render and physics engines which has to be coordinated. Most games just grab what they need from the computer's hard drive or a local DVD. Handling this coordination problem is woven through the server and viewer code. So, swapping out the render and physics engines is a massive task that touches every part of the SL system.

The decision to build Sansar was made because it was easier and cheaper to build a whole new system than attempt to upgrade SL to a render engine that could provide VR level performance.

My personal thinking on Sansar's failure is that they tried to control the developers so Sansar would have a socially acceptable environment. That resulted in fewer developers building for Sansar. Those that were, built the things that interested them. Since moving from place to place in Sansar was so hard and slow developers seemed develop self contained environments. No need to teleport. Which resulted in small... tiny communities.

Nal,



it was multi petabyte in 2011.   imagine what it is now.