Open 3D Engine (formerly Lumberyard) Use in Second Life?

[Jaxon Wanderer]

Now that Amazon has open-sources Lumberyard (now called Open 3D Engine Open 3D Engine (o3de.org)), will Second Life make use of the engine?

[Coffee Pancake]

15 minutes ago, Jaxon Wanderer said:

Now that Amazon has open-sources Lumberyard (now called Open 3D Engine Open 3D Engine (o3de.org)), will Second Life make use of the engine?

No !

For the same reasons SL doesn't and can't make use of other game engines like Unreal, Unity or Godot (also open source).

SL does not work like a game. It only has superficial similarity' to games in that 3d assets are rendered using some kind of graphics card.

You might as well be asking why blender doesn't switch to a game engine.

[NiranV Dean]

1 hour ago, Coffee Pancake said:

No !

For the same reasons SL doesn't and can't make use of other game engines like Unreal, Unity or Godot (also open source).

SL does not work like a game. It only has superficial similarity' to games in that 3d assets are rendered using some kind of graphics card.

You might as well be asking why blender doesn't switch to a game engine.

The answer is because neither of these (or any other engine) would be able to do what is required to do for SL to function without changing so much of the engine that it is questionable whether you are still using said engine (aside from the tools/editors and QOL/features provided). You might as well rewrite SL's Viewer in its entirety, that would be a similar amount of work (although as said engines would offer some benefits like tools that would help potentially creating more stuff in the future faster)

It's like taking a racing game engine that was solely ever made for racing games and using it for a shooter, unless heavily modifed and extended you'll basically play a hacky shooter that feels like you're driving a car.

Edited July 6, 2021 by NiranV Dean

[Profaitchikenz Haiku]

On 7/6/2021 at 9:26 PM, Coffee Pancake said:

You might as well be asking why blender doesn't switch to a game engine.

Why would they when they have "Blender Game Engine" ? (OK, I heard they were thinking of dropping it but all my versions of Blender come with BGE)

[AlexandriaBrangwin]

Just opening up the taps so SL uses more power would solve a few problems.

You have people with Ryzen 9 cpus, RTX 3080 gpus....SL runs like mud....the load?

cpu 10%, gpu 12%

....just take the gloves off!

This hardware can run the biggest & baddest at 4K 120fps while barely cracking 90% on both cpu & gpu!

SL has ZERO excuse!

[CaithLynnSayes]

On 7/29/2021 at 9:02 AM, AlexandriaBrangwin said:

Just opening up the taps so SL uses more power would solve a few problems.

You have people with Ryzen 9 cpus, RTX 3080 gpus....SL runs like mud....the load?

cpu 10%, gpu 12%

....just take the gloves off!

This hardware can run the biggest & baddest at 4K 120fps while barely cracking 90% on both cpu & gpu!

SL has ZERO excuse!

You obviously have ZERO understanding of how SL works under the hood.

[AlexandriaBrangwin]

13 hours ago, CaithLynnSayes said:

You obviously have ZERO understanding of how SL works under the hood.

...now just reading that makes me so mad!

How DARE you say such an arrogant thing about me!!!!

And it didn't even accomplish anything, please can you never speak to me again if you're going to be like that!....I don;t need it!

[CaithLynnSayes]

 

The only one being arrogant here sweetie, is you. As i said, you have no clue how SL works, you think that throwing a big giant super duper mega fast computer is going to make SL run faster. Please, dissect SL, viewer code and server code and everything around it. Learn all about it, then come back to me. Mkay pumpkin?

 

I'm also not sure as to why that would make you mad. You demonstrate here that you have no idea of how SL works, how complicated it is and what is needed to make it all work smoothly (a little bit more than your "fast" computer). Interestingly that seems to be enough to totally throw you off the rails. Interesting, and hilarious, i'll be honest.

Edited July 30, 2021 by CaithLynnSayes

[Coffee Pancake]

On 7/29/2021 at 3:02 AM, AlexandriaBrangwin said:

Just opening up the taps so SL uses more power would solve a few problems.

You have people with Ryzen 9 cpus, RTX 3080 gpus....SL runs like mud....the load?

cpu 10%, gpu 12%

....just take the gloves off!

This hardware can run the biggest & baddest at 4K 120fps while barely cracking 90% on both cpu & gpu!

SL has ZERO excuse!

 

You have a fancy new multicore monster of a CPU, me too! .. really, it's several average-good CPUs all slapped side by side in the same chip. Multithreading seems like the way to really get the most from it, get all the cores working on different parts of the problem at the same time, but there's a catch and it's a big one.

All these threads have to come together once every frame, hand everything over to one core, that then tells your GPU what to render. So you have a 6 or 8 or 12 lane super highway, with one exit that everyone has to use. The end result is it's no faster than doing everything all on one core, probably a bit slower with all the messing about.

That last bit can't be done multicore as we're stuck with OpenGL rendering. If and when LL switch over to vulkan then maybe a true multi threaded client will make more sense.

But .. there is another catch .. SL isn't made like a game, which is exactly what a modern GPU is designed to accelerate. SL can't be made to run like a game and still allow everything that makes SL unique. So even with a fully threaded client ramping all the cores, rendering with multiple threads  .. it's still not going to run like a game.

Switching to a true multithreaded texture pipeline and render engine is a lot of work that will take months to get working, and even longer to debug. Assuming we can feed the texture pipeline fast enough, things should rez a perform a lot better, and we will get some really nice bonus features, like RTX lighting and effects.

However ...  Right now, SL only uses a single thread, that leaves all the other threads free to do everything else you're using the computer for, like chrome tabs, photoshop, blender, or a game on the side. Once we get a fully threaded client, it's not going to play so well with everything else and will really make your computer work for its supper.

Which leads into the final final catch .. and this one is a real deal breaker. The average computer in use for SL is a laptop with integrated graphics or an APU. How will those, especially older or more business orientated ones, handle this new beast of a client?

 

If this was as simple as taking the gloves off, someone would have done it already. The client is open source, there are performant open source game engines, and yet .. no one has managed to mash the two together.

[animats]

6 hours ago, Coffee Pancake said:

Which leads into the final final catch .. and this one is a real deal breaker. The average computer in use for SL is a laptop with integrated graphics or an APU. How will those, especially older or more business orientated ones, handle this new beast of a client?

Which is a big problem.

If we required the machine an average Steam user has, with an NVidia 1080, we could do pretty well on frame rate.

I'm working on an experimental rendering part of an SL viewer, using the latest and greatest technologies.Some TPV developers and graphics Lindens know what I'm trying and have seen video, but I'm not showing anything publicly. If you're seriously interested and understand this kind of thing, send me a message and we can talk. This is a high risk approach; it might work, or it might not. So far, frame rates are great because the GPU and a refresh thread are doing all the work. Update rates not so much because the asset fetch and LOD system are still very basic. It's just move and view; you can't do anything in world yet.

At this point I can say that yes, it is possible to do a higher performance viewer. It's a big job, it has technical risk, it won't support some older hardware, the minimum hardware requirement is higher than for existing viewers, and it requires a full rewrite of the code. I'm doing a proof of concept, not a full viewer, to see what performance i can get.

On 7/6/2021 at 1:26 PM, Coffee Pancake said:

For the same reasons SL doesn't and can't make use of other game engines like Unreal, Unity or Godot (also open source).

The problem with the big game engines is that they have their own built-in ideas of how game assets are supposed to be created, optimized, staged, and rendered. Those approaches are quite different from the way SL does things. Nobody even has an off the shelf game engine that can do a big, seamless, user-modifiable, near-photorealistic world out of the box, let alone do it the SL way. Which is why SL doesn't have a dozen competitors in the big, seamless. user-modifiable, near-photorealistic world business. (Yet. With all the money being thrown at "metaverse" stuff lately, that may change.)

You can get close if you give up one of those requirements. If you give up "user modifiable", you get Red Dead Redemption, which has a huge world and looks really good. If you give up "near-photorealistic", you get a voxel world like Roblox or Dual Universe, where the avatars look awful. If you give up "big, seamless" you get Sansar or Sinespace or Breakroom. Those have a big loading delay when you go somewhere, and then you're mostly running everything locally.

Now, what you can use is a good low-level cross-platform graphics library. Something that efficiently handles the differences between Vulkan, DX12, and Metal. That's almost available. I'm using WGPU and Rend3, neither of which is finished, and I'm in regular contact with their developers. That handles the low level stuff. I provide a mesh, material info, texture info, and position/rotation/size, and say to Rend3, "put this on screen", and it does that part of the job.

The rest involves a huge amount of SL specific stuff. SL has its own mesh format, its own material format, its own message format, its own marshaling format, its own network protocol, its own prim format ... (Those are just the parts I've rewritten so far. There's more.) Nothing in UE5, Unity, or Godot will help there. They all have ways of doing those things, but they're not compatible with SL servers.

It has to be SL-server compatible, or you have to develop a new set of users. That's far harder than advancing the technology compatibly. See Sansar, Sinespace, Facebook Horizons, etc., all of which failed to grow a user base. However, we do have flexibility on how to do things viewer side. As long as the viewer talks to the servers compatibility and it looks about the same to the user, what's under the hood can be quite different.

There's another, longer-term performance issue. In a way, we're doing this all wrong, rendering on the user's machine. It takes more bandwidth to send high-quality assets to the user's machine than it does to send video. 4K video is only 15-32 Mb/s, while an aggressive SL viewer would happily suck assets from the asset server at well over 50Mb/s if allowed to do so. We really should be running SL clients on machines in a data center, one per user, and sending video to the client, which could be anything capable of showing video. You could do that now on some "gaming cloud". Use SL from your 5G phone. But the per-hour cost! Companies have been starting up cloud gaming startups and going bust for the last 4 years or so. Set the price realistically, and nobody buys, set it low enough to get customers, and go broke or drop out of the business.

OK, more than most people wanted to know.

[CaithLynnSayes]

8 hours ago, Coffee Pancake said:

If this was as simple as taking the gloves off, someone would have done it already. The client is open source, there are performant open source game engines, and yet .. no one has managed to mash the two together.

Exactly my point...

[Henri Beauchamp]

2 hours ago, animats said:

I'm working on an experimental rendering part of an SL viewer, using the latest and greatest technologies.Some TPV developers and graphics Lindens know what I'm trying and have seen video, but I'm not showing anything publicly. If you're seriously interested and understand this kind of thing, send me a message and we can talk. This is a high risk approach; it might work, or it might not. So far, frame rates are great because the GPU and a refresh thread are doing all the work. Update rates not so much because the asset fetch and LOD system are still very basic. It's just move and view; you can't do anything in world yet.

.../...

while an aggressive SL viewer would happily suck assets from the asset server at well over 50Mb/s if allowed to do so.

You got me curious... Vulkan renderer ?... I'd love to try and adapt it to my viewer, which you would likely classify as ”hyper aggressive”, since I regularly see it suck up assets (meshes and textures, mostly) at over 250Mbps (true TCP/IP observed bandwidth) on a 1Gbps (ATM bandwidth) FTTH link after TPs in un-cached region...

Edited July 31, 2021 by Henri Beauchamp

[Nalates Urriah]

14 hours ago, AlexandriaBrangwin said:

...now just reading that makes me so mad!

How DARE you say such an arrogant thing about me!!!!

And it didn't even accomplish anything, please can you never speak to me again if you're going to be like that!....I don;t need it!

I guess it is embarrassing when people notice the OBVIOUS...

[NiranV Dean]

With all this talk about Multithreading and Optimization, i guess its time i should look into Multithreading again. Looked really fun and if you know the catches it is technically not all that complicated to implement, its just a lot of work.

Years ago i made an experiment to speed up the Preferences window creation because opening it for the first time (and potentially all subsequent ones that update the Avatar Render List) caused the Viewer to stall for quite some time (even more if your render list gets bigger), to reduce this to a minimum i moved the render list creation to an extra thread and only have the main thread fill in the list with the data collected in the extra thread, this significantly reduced the hitch to an absolute minimum. This ofcourse was a small scale test and the situation was perfect since all of this stuff was heavy work and was done in order and could be easily done all at the same time. But there are many parts in the Viewer that do things in order that do weight in quite a bit and could be offloaded into another thread, things that don't need to be up-to-date at all times due to SL's extreme sensibility which in turn has SL hardened for a lot of weird situations where information is not yet available, which in turn means multithreading could be easily applied as the Viewer won't care and will simply update the information whenever it is ready.

Single Thread

vs

Multithreading

[MarissaOrloff]

On 7/29/2021 at 3:02 AM, AlexandriaBrangwin said:

Just opening up the taps so SL uses more power would solve a few problems.

You have people with Ryzen 9 cpus, RTX 3080 gpus....SL runs like mud....the load?

cpu 10%, gpu 12%

....just take the gloves off!

This hardware can run the biggest & baddest at 4K 120fps while barely cracking 90% on both cpu & gpu!

SL has ZERO excuse!

If you give the viewer the right environment (example in photo is running ultra with long full shadows) where the GPU starts taking over is where you will see higher end equipment shining. See the 86% load on the cpu.

CPU: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz (2600 MHz)
Memory: 64037 MB
Concurrency: 12
OS Version: Linux 5.14.0-051400rc3-generic #202107252330 SMP Sun Jul 25 23:34:03 UTC 2021 x86_64
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce RTX 2080/PCIe/SSE2
Graphics Card Memory: 8192 MB

OpenGL Version: 4.6.0 NVIDIA 470.57.02

 

[NiranV Dean]

That's because the GPU unlike the CPU is not limited and can be used almost completely by Second Life via everything that is shader based.

[JeromFranzic]

17 minutes ago, NiranV Dean said:

That's because the GPU unlike the CPU is not limited and can be used almost completely by Second Life via everything that is shader based.

Yep.

And that's also why people like me with modest 1050 GPUs (but sport fast multi core processors, mine's a 8th gen intel i7) can run SL decently. 🙂

[MarissaOrloff]

9 hours ago, NiranV Dean said:

That's because the GPU unlike the CPU is not limited and can be used almost completely by Second Life via everything that is shader based.

A few months back in another thread (which I forgot which one) you gave an excellent explanation of what is going on with CPU vs GPU load in SL!

[Monty Linden]

On 7/31/2021 at 3:37 AM, animats said:

I'm doing a proof of concept, not a full viewer, to see what performance i can get.

I am very interested in seeing what comes out of this.