There's no reason you couldn't write a scene graph that presents the Second Life scenes, using Unreal Engine as the renderer. There's also support for dynamically paging landscapes, re-centering the rendering/simulation origin, and so forth. It's not what it's optimized for, but with modern destruction and modern multi-player worlds and modern real-time global illumination and shadows, it's slowly moving in that direction. You can build a scene of entirely movable actors with a variety of meshes. Build levels in the editor, let the editor chew on all the assets, and spit out fully-optimized game levels. Is there machinery in UE4 for this kind of world, dominated by dynamic loading?įirst: Unreal generally prefers pre-calculated geometry. But nobody has gone all the way to multithreaded rendering on Vulkan yet, offloading as much to the GPU as possible.
The code base is 15 years old.Įvery attempt to seriously speed this up has failed. Always out of main thread time, not enough drawn per draw call, underutilizes the GPU. The existing viewer is mostly single thread, OpenGL based, and it's just too slow. Caching content locally is possible, but can't do it all there's petabytes of content out there. So the viewer may be forced to load assets constantly to keep up, while displaying a reasonably decent view of the world even when it's not caught up. The player can get into a vehicle and drive moderately fast, up to about 100km/hr.
So a fast viewer needs to combine objects for faster rendering and be prepared to redo that work if someone opens a door or something. The viewer doesn't know which objects are going to move.Assets are created by tens of thousands of different users, and there's very little duplication. Some are far more complex than they need to be.
There are other third-party viewers, using much of the standard SL open source code, so it's not necessary to reverse engineer. There have been several efforts to make a client viewer for Second Life using UE4. Thankfully LL got out ahead and did it server-side. We had implemented out own viewer side throttling that would have killed the scrolling message toys, but it would have taken time to migrate out to other TPV's and even then people might choose not update. Once it was made clear we did reach out to many vendors informing them and suggesting they cease selling and consider refunding sales (weeks ago), but apparently making gobs of quick cash was more important. We did also not fully anticipate what was happening server side, seems it's not as simple / lacks the caching we had expected. We were not anticipating people changing the group role so as to create constantly scrolling messages and literally hammering the region with group role commands as fast as their script would allow in perpetuity. we were primarily anticipating RP orientated uses and having different visible roles depending on your characters situational context. That use case is still more or less ok with the throttling as put in by LL. The feature as added was to enable group role changes via RLV.