Meanwhile, over in metaverse land, there are petabytes of content in the big worlds.
I've been working on a faster Second Life / Open Simulator client. Those have a
reputation for being sluggish. That's rapidly changing.
All content is loaded on demand. Textures are stored in JPEG 2000 format.
JPEG 2000 decoders come in several flavors - slow and flaky, fast but need the GPU, and midrange but expensive. If you want to rewrite OpenJPEG in Rust, go for it. You can download part of a JPEG 2000 file and get a lower resolution texture, and that's what's done for distant objects. The general idea is to download textures at a size that gets one texel per screen pixel. (Yes, subpixel textures would be better.) Textures are locally cached to SSD. Background threads are frantically loading and unloading textures in the GPU at different resolutions as the viewpoint moves. The highest resolution is compressed losslessly; the others are lossy.
In metaverse systems with user generated content, there's not much instancing. So the texture load is much higher. Wander around Cyberpunk 2077 and you'll see the same railing show up in completely different contexts. This doesn't happen in worlds with user-created content.
There's no producer or art director to insist on reusing content.
If your game downloads content on the fly, you need substantial content delivery capacity.
Second Life front-ends Amazon AWS with Akamai. Open Simulator, on the other hand, often just hosts the content on a single game server, along with the the simulator itself. My own viewer pulls about 200Mb/s from the content servers for about 15 seconds when you first connect. Then it's done until the viewpoint moves.
Check out HTJ2K if you haven't already, it's J2K with SIMD instructions, it will have solid support because the medical industry is (slowly) moving towards adopting it. Sounds like you already saw NVIDIA's J2K decoder. There are FPGA solutions as well that are insanely fast (CAST and some others).
HTJ2K has support in OpenJPEG (master branch at least), might need to compile with a specific flag or something I can't remember.
I think JPEG-XL is ideal for these types of applications in my opinion, even if you ship the decoder with your client. Their progressive encoding/decoding is much better than J2K in my opinion.
I used to love Second Life back in the day. Can you tell us more about your "game" , and less about the technical details? I know this is HN, but what would you tell a prospective player about your game?
I'm interested in metaverses that work. The NFT industry has crashed and burned [1], and Facebook/Meta has bombed in that space [2]. With the clown car out of the way, it's now possible to make progress.
The lesson of these failures is that there's not much of a role for ads or brands in the metaverse.
They're distracting and don't fit in. The successes, from Roblox to Fortnite to Second Life, charge users a modest fee each month.
A metaverse is not a game. Games can be built within it by users. This has been done in Second Life, but the games are 1) sluggish, and 2) space-constrained, because land is expensive. Those are scaling problems which can be solved.
This requires solving the scaling problems that led to the original article here. You can't just download everything in advance. There's too much stuff in the larger games.
Open Simulator is an open source re-implementation of Second Life servers, written in C#. It's been around for a while, and now it's getting a bit more developer attention. There are multiple federated grids of Open Simulator servers, and content stores where you can buy items, all under different management.
Land is much cheaper than in Second Life, but servers tend to be under-resourced and slow. There are some people working quietly on trying to improve the Open Simulator technology to work better.
Other attempts to solve this problem include Improbable's system. Improbable managed to blow through $400 million on the scaling problem, producing a system that's too expensive to run.[3] (They're funded by SoftBank.) Some good indy games tried to use their system, but the server bill was too high. Their approach is a general-purpose distributed object manager, which seems to be the wrong tool for the job. Otherside uses Improbable, and they only turn on their world maybe twice a year for a few hours for special events.
I've been working on a faster Second Life / Open Simulator client. Those have a reputation for being sluggish. That's rapidly changing.
All content is loaded on demand. Textures are stored in JPEG 2000 format. JPEG 2000 decoders come in several flavors - slow and flaky, fast but need the GPU, and midrange but expensive. If you want to rewrite OpenJPEG in Rust, go for it. You can download part of a JPEG 2000 file and get a lower resolution texture, and that's what's done for distant objects. The general idea is to download textures at a size that gets one texel per screen pixel. (Yes, subpixel textures would be better.) Textures are locally cached to SSD. Background threads are frantically loading and unloading textures in the GPU at different resolutions as the viewpoint moves. The highest resolution is compressed losslessly; the others are lossy.
In metaverse systems with user generated content, there's not much instancing. So the texture load is much higher. Wander around Cyberpunk 2077 and you'll see the same railing show up in completely different contexts. This doesn't happen in worlds with user-created content. There's no producer or art director to insist on reusing content.
If your game downloads content on the fly, you need substantial content delivery capacity. Second Life front-ends Amazon AWS with Akamai. Open Simulator, on the other hand, often just hosts the content on a single game server, along with the the simulator itself. My own viewer pulls about 200Mb/s from the content servers for about 15 seconds when you first connect. Then it's done until the viewpoint moves.