No Regions Loaded Unreal Engine 5
Joke Grinman
I recently ran into this bug in UE 5.3 where unreal refused to unload my landscape that I had imported via a heightmap from Gaea. This is especially strange because the landscape regions will appear as loaded in the editor even when they are marked as unloaded in the world partition minimap. Loading and unloading the regions manually from there does not help.
I was not able to determine what causes this to happen, but I did find a workaround. In order to get your landscape to unload in the editor, first go to the World Settings tab and uncheck enable streaming:
Then save your level and restart the editor. Finally, go back to the World Settings tab and check enable streaming. The editor may lock up for a few seconds, but once it is finished re-enabling streaming, your landscape should be properly unloaded. At this point, you should be able to manually load and unload individual regions from the world partition minimap.
There have been several efforts to make a client viewer for Second Life using UE4. All have failed. No idea why. I'd like comments from UE4 experts. There are other third-party viewers, using much of the standard SL open source code, so it's not necessary to reverse engineer. Just implement.
The existing viewer is mostly single thread, OpenGL based, and it's just too slow. Always out of main thread time, not enough drawn per draw call, underutilizes the GPU. The code base is 15 years old.
Every attempt to seriously speed this up has failed. But nobody has gone all the way to multithreaded rendering on Vulkan yet, offloading as much to the GPU as possible. Is there machinery in UE4 for this kind of world, dominated by dynamic loading?
You can build a scene of entirely movable actors with a variety of meshes. 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. There's also support for dynamically paging landscapes, re-centering the rendering/simulation origin, and so forth.
You can build a scene of entirely movable actors with a variety of meshes. 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.
Second Life is picking up a bit, by the way, For three years, Linden Lab was focusing on Sansar, their sharded VR world. It was a total flop. Got about 20 users on Steam. Discontinued last month. Sansar had a staff of about 100 at peak, and Second Life, which is quite profitable, was being used as a cash cow to fund it. So now they're refocusing on Second Life. The basic problem with Second Life being that it's slow. That needs to be fixed, somehow.
And store pointers where our data ended up? When something is removed, we use these pointers to cut out this object out of our large linear buffer. Then use some memory management techniques to defragment this buffer.
Multithreading is more fun if you share the data at a fine level.
SL's scene graph has a transform at every node. Most of those change infrequently, but the current renderer does a draw call for each transform, loading a new transform, rather than pre-transforming them down to vertex arrays. Each object has its own textures; there are no multiple-object texture atlases. So there's a lot of texture switching, an expensive operation in OpenGL. (I hear that's faster in Vulkan. Comments?)
What makes this hard is that any transform can change at any time (but usually won't) any texture can be reloaded at a different resolution (which happens infrequently per texture but constantly as a scene loads or the viewpoint changes) and meshes are constantly being loaded at low levels of detail and then reloaded at higher levels as the network catches up.
This is what Second Life and Open Simulator should look like. No more standing in front of a blurry object and waiting for it to load. Waiting, and waiting. And wondering if it's worth the wait. This changes the whole SL experience, for the better. Now Second Life looks like an AAA game.
What's going on here? This is an all-new viewer, with no Linden Lab code. It's written in Rust, and uses Vulkan for graphics. It has physically-based rendering. It's multi-threaded. One CPU is just refreshing the screen, at 50 to 60 FPS here. The other CPUs are making changes to the scene as the camera moves. All those high-detail textures are being loaded from cache just before the camera gets close enough to see them. If everything is in cache, this viewer can stay ahead of camera movement, even for very high detail content like this. If the content has to come from the server, the objects that cover the most screen area are always loaded first. So what's in front of you is never blurry for more than a very brief period.
I'm working through the hard problems of building a high-detail metaverse here. The underlying technology is cutting-edge - the Rust programming language, Vulkan, WGPU for cross-platform graphics, and Rend3 to make WGPU usable. The lower levels libraries are not yet stable or complete. (For example, WGPU doesn't implement rigged mesh yet, so there are no avatars shown.) I'm doing this to see what's possible medium-term, not to produce a new SL viewer in the near term.
I don't want to get end users too excited about this. Many viewer devs, both inside and outside Linden Lab, know what I'm up to. After a year of work, and some good results, I decided to put out a progress report.
This is partly in response to recent comments about excessively large textures. Those are not a real problem if you don't load all those pixels until you really need them. If you get close enough to a 2048x2048 texture to fill your screen, it will get loaded, but not otherwise.
the Lucky Fuzzy Game was quite popular. Go to a shop to play the Lucky Boards. Can't see the prize textures. Can't see the letters either. So click the board and get lucky. And if get lucky because is your letter that you can't see then win a prize, which you can't see either. But! is better to win a Fuzzy than not win anything at all. So \o/ thankyou! Click the next board which you can't see and try to get lucky again and win another Fuzzy!
Project Interesting broke the Lucky Fuzzy Game, which I "complained" about at the time. Blinking Lindens. Breaking my game! Whatever were they thinking! Going round breaking content as if that was a good thing!
while it may not have been continued to perfection, Project Interesting viewer released in 2014, a culmination of several years work, totally changed for the better what the world had become since the prior introduction of mesh
SL is many things including a game. It's a 3D virtual environment, a chat platform, a building simulator, a multiplayer roleplaying game. Last time I looked "the sims" was a video game. The opinion that SL is not a game is simply an opinion. In fact, most people treat it as one big Roleplaying game for the most part.
That's not how this works. That's an illusion. The viewer is in a race with the user to load content before the user gets close enough to see through the illusion. High-resolution textures are constantly being loaded as the camera moves around, and distant textures are being dropped to lower resolution to keep the frame rate up. There's a lot going on behind the scenes to create the illusion that nothing is happening. Pay no attention to the man behind the curtain.
Here's another example, from an earlier, lower performance version of the system. This shows what it looks like when textures are not in local cache. This is a tour of a shopping event. Booth after booth of high-detail objects. You'll see some small or distant grey objects that haven't loaded yet, and some objects with fuzzy, low detail textures. As the camera gets close, the grey objects turn to textures, and fuzzy textures go to higher resolution. You never see a fuzzy texture in close-up for more than a second or two. The shopping experience improves. You can see the merchandise.
Next problem is getting rid of grey. What I'd like to do there is have a per-region list of objects, faces, and average colors. Download that and use it as the initial color for each object. Here's a test of what that would look like.
The plan is to show something like this when you first enter a new area for which textures are not yet available. The amount of data needed to do this is small, and so this info can be cached for a very large number of regions. Texture loading will quickly follow, starting, of course, with the objects occupying the most screen space loaded first.
I think this is great, I've always been a fan of making the current viewer an "editor" for builders and having a lightweight, high performance viewer for people who don't want to build. The vast majority of users would be very happy with a lightweight viewer that just ran well, let them move a few things around, manage inventory, change appearance, and of course be social. I am a builder but I would use the lightweight viewer most of the time. I'm sure most builders would agree with me.
e59dfda104