animats

One can always hope. It's been like that for the last month. It's a culture conflict. Zenescope is a comics publisher. Their user base is accustomed to waiting for the next issue.

The Firestorm pre-processor is pretty good. The best feature is #include, which allows libraries. Importantly, anything from an #include that isn't referenced is removed. That allows libraries to contain lots of functions you may need, without memory cost if not used. For a transpiler, LSL is a terrible target language. The immutable list system is the only data structure, and it's too hard to work with. If you translated arrays and structures into LSL, the resulting LSL code would be terribly slow. The right solution, which Open Simulator has, is to let you write C# code. Internally, LSL (usually) compiles to Mono, which is a bytecode system that can run various languages. So the server side is almost C# ready. C# is an OK language, and we know it can be mapped to the LSL functions, so, why not? What I had to go through to implement the maze solver for my NPCs in LSL was hell. All those global variables. I wrote that in Python first, to debug the algorithm.

Right. It's just Zenescope promoting something. The NFT system Zenescope is using has zero connection to the SL world. What we can learn from this is that, while hooking up NFTs to Second Life is possible, the customer reaction is DO NOT WANT.

Quick fix: staff Social Island 10. Preferably by making it a rotating duty for management, so they see the problems of onboarding.

Um, you're probably right. Maybe go at this from a different direction. Partner with Architectural Digest and some architecture schools. Aspiring architects get a region to develop. Then there's a a judging by AD staff. Everybody gets to admire the region, and the virtual houses go on sale. Or partner with FIT, Fashion Institute of Technology in New York, and have a competition for clothing designers leading up to a runway show at Fashion Week in SL. Promote SL as the best-looking virtual world. Get coverage in Vogue, WWD, AD, etc.

If Zenescope offered their characters and outfits in Second Life, they'd be pretty good. One of their characters. One that's safe for the non-adult forums. But this is what we get in SL: Pretzels? Pretzels. This project needed a bigger budget.

Did the Zenescope crowd ever get the rest of their quest built? I did phase 1, which involves a mostly empty mansion, a miniature golf course, a fast food restaurant, a maze, and, inevitably, a trip through the gift shop. Then you get to a portal with something like "Phase 2 coming soon". Maybe Phase 2 is less boring.

Oh, that thing. It's like Upland, on a larger scale. You can buy areas on a map, with vague promises about a 3D world being built so you can do something with your piece of the map. There's a good chance this is illegal in the US, as an unregistered security offering. There's something called the "Howey test" which is used to determine if something being offered for sale is a security. The basic concept is that if you sell a token that's for something that exists right now, that's probably OK. If you sell a token for something that doesn't fully exist yet, that's promoting a speculative investment. Which is reasonable enough. You buy land rights in Second Life, you can visit the virtual land, build on it, and have your friends over. That's fine. You buy land rights in Earth 2, and you are hoping that they "transform into the world's geographical virtual land platform, introduce our global economic simulator and continue building our E2 Terrain Engine to provide massive, realistic, real time rendered geolocated 3D environments." That's not OK. That's almost the definition of a "blue sky" investment. A few years back, the big thing was "ICOs", "initial coin offerings". In 2018, the Securities and Exchange Commission brought the hammer down on the ICO industry. They pursued criminal charges against the worst offenders (the first one was the crypto coin supposedly backed by diamonds and land, in reality backed by nothing), and sent the others a letter, asking why they hadn't registered with the SEC as an investment offering. Suddenly the entire Initial Coin Offering thing just disappeared. A legit business could have made the SEC filings and kept going. Very, very few did. Here's a list of SEC enforcement actions related to ICOs, etc. The SEC hasn't yet cracked down on NFTs yet. They're known to be considering enforcement actions.

The "Facebook building a high-rez Second Life" theme is just the article author's speculation. Facebook is apparently going to announce some naming or rebranding thing today. It will probably involve the name "meta" in some way, because Facebook has been buying up domains with "meta" in them. That may just be a corporate reorganization, much as Google did when they made the parent company "Alphabet". I'm not sure this is a big threat to Second Life. Facebook has tried three times already to get into virtual worlds. Three duds so far. Roblox looks like a bigger threat. They have a published roadmap. They're making progress getting past blocks and making their world look and work better. They have growth. They have a few billion dollars. They have a few million users. They have a few hundred developers. They have a "can do" company mindset.

There used to be an SL user doing business as "The Land Chick", who had billboards advertising her services in finding parcels. But those billboards seem to be gone.

If the first part of this proposal works, then this "mesh baking" phase could be used for further optimizations. Merging meshes during clothing changes is one potential optimization. There's also the possibility of removing triangles that can't possibly be seen from the outside. But that would require developing new technology. So, initially, I'm just talking about adapting something the competition already has working. What I'm talking about won't add more meshes to an avatar. Just the existing meshes, with slightly different rigging weights. This needs a demo add-on in Blender to be a convincing proposal. IM me if interested.

The problem is peak processing per frame, not total processing time. Throttling spreads out the load over multiple frame times. (This is the difference between real time programming and non-real-time programming. It's peaks that matter, not averages.)

Goal: make clothing layer properly without user pain. Suppose we had something which compressed inner clothing layers a bit to prevent them showing through outer layers. Roblox is adding a clothing system. The same items fit different bodies. They're gaining on us! Yes, they're not great clothing items. It's a tech demo. Roblox is automatically adjusting the rigging slightly when you put on a clothing item. Should SL have something like that? Catch up with Roblox? Roblox has to add "cage layers" to clothing to make it force-fit any avatar. Think of that as a possible future "Fitmesh Plus". Probably too much trouble for SL, because existing SL clothing doesn't have the extra info needed for that. What could be done with existing SL clothing. A simpler, more compatible system would just squeeze inner layers inward a bit. Only when necessary, so they didn't peek though. This would eliminate the need for alpha layers for clothing, the need for alpha HUDs, and the need to break skins up into a hundred tiny faces. Basic rule: if it doesn't peek through in pose stance, it should not peek through in any stance. So you try on clothing in pose stance, and then it Just Works. This would be done automatically when the user changes clothes. Much like BOM baking, and probably as part of the same system. Good idea? Comments? Of course, there's the occasional item of clothing which layers in an unusual way. Shirt tucked in on one side only. So this trick won't work for everything. Have to be able to turn it off for some items. How much clothing is like that?

It's not much, but the throttle does kick in. If you see a packet loss percentage, and pinging the SL servers shows no packet loss, that's probably the throttling system. Whether it should be throttling is a separate issue. The average UDP rate is low, but the peak rate is much higher. When you enter a new un-cached region, there's a huge blast of full object update and compressed object update messages. Processing them is a fair amount of work. For example, all the geometry for prims is generated on packet reception.

Yes. There's a related problem and a related mechanism. The LL viewer and ones using the same code are mostly single-threaded. (The code dates from the era when personal computers only had one CPU core.) The same thread that's refreshing the screen is handling the incoming data from the network. This, by the way, is why "ping time" goes up when FPS is low. Timing is complete when the refresh loop comes around and reads the network, not when the packet actually arrives. So, too much incoming UDP data during one frame time would reduce FPS. That's the real reason for the throttle. If you have lots of bandwidth, no throttle, and a viewer choking on drawing the scene, the arriving packets could use up too much of the frame time and lower the FPS even more. So there's a backup system - the packet discarder in the receiver. If too many UDP packets come in during one frame time, some packets are discarded. There's a quota on how much UDP data gets processed per frame. This is why "packet loss" goes up when FPS is low, even if the network itself is not losing any packets. As Beq points out, UDP packets are not, of themselves, reliable. The essential lost messages do get resent after a second or so. SL networking appears to use a fixed retransmit timer. So dropping messages does not cause the sender to slow down. That's not good. In practice, this isn't a major problem most of the time, now that assets come via the asset system over TCP. That part works exactly like fetching images from a web server. But when a viewer connects to a new region and has no info about that region in the cache, it asks the server to tell it everything about that region. So the server floods the viewer with too much information. Which can result in packet drops and retransmissions. Delaying certain messages more than one second will cause a region crossing to fail every time, for example. All this interaction is delicate.The packet-discard system relationship with FPS makes the networking rather brittle. So it's hard to predict what will happen if you change something. Working on this would require instrumentation and testing. I can understand LL's reluctance to mess with this.

Is that being removed as part of the "file cache" update?

Big textures are only a problem because the texture loader in the viewer is too dumb. That was supposed to be fixed as part of Project Interesting, and there are bits of code which clearly try to do something, but they don't work. As I've mentioned before, I've been working on this for my own experimental Rust/Vulkan based viewer, where I can try out advanced approaches without dealing with legacy C++ code. Here's an early test. (This is a long way from being useful to end users.) http://www.animats.com/sl/misc/accessmalltest.mp4 This is simply a video of looking around a fashion shopping event with many high-detail images. You can see textures loading and grey objects becoming textured. There's a lot of texture level of detail swapping going on for distant objects, but most of that isn't visible. Note the absence of blurry objects in close-up. This improves the shopping experience. You can see all the displays. The rules used for texture loading are simply this: Try to load and unload textures to maintain one texture pixel per screen pixel. Texture loading priority is based on screen area involved. Constantly adjust the loading queue as the viewpoint moves. Unless you get close to an object, the system won't load a high-resolution texture. So it doesn't matter if you have 1024 x 1024 or even 2048 x 2048 textures. By the time you get close enough to load such a texture, the object is filling most of the screen and deserves to be loaded. If you never get that close, the detail is not loaded. If you get close enough, you will always get the full texture. Fast. Technical notes: Beq Janus points out that this is not optimal for some cases with texture atlases, but in practice that doesn't seem to come up much. Testing continues. Efficiently adjusting the loading queue on the fly is somewhat difficult technically. Fortunately there's a standard Rust library to do much of the heavy lifting. This reduces the priority change overhead from O(N) to O(log N). The standard C++ priority queue in the STL is useless for this, because you can't change the priority of a queued object. The Boost priority queue, maybe. This works better if you have multiple threads on multiple CPUs working on the problem, so queue updating does not affect the FPS. If you have to do this from the main draw thread, it may reduce frame rate.

That area just lost the Lionheart Mainland Embassy, with its nice four-track railroad station. If anyone wants to build a rail-related facility there, Lionheart is selling it off.

Last week the Linden Lab job openings included a "Head of Product" for Second Life. Today that opening is gone. Is there a new head of product coming onboard?

Roblox is trying to attract an older crowd, according to their SEC S-1 filing. So they need to decide what to do. SL has G, M, and A, of course, and used to have the teen grid. Facebook went for legless avatars, and that was a flop. The NFT worlds aren't getting enough users to need governance,. It's not clear how this plays out.

Roblox has a terms of service update. Roblox's average user age is 13. (Since birth, not first login.) But this seems overkill.

(Probably off topic)

https://www.twitch.tv/videos/1173815818 TCG World. A procedurally generated metaverse. It's a big world with procedurally generated terrain. 800 square kilometers of terrain. You can buy plots, and put stuff there. It's seamless and sharded. Every N users get a new instance of the world, and they all see the same fixed objects, but only the avatars in their shard. So everybody sees 800 square kilometers with maybe 20-100 avatars in their shard. It's built from standard MMO parts; Unity for the client, Photon for the server. Plus an asset server. Each client generates the same terrain using a pseudo-random number generator in sync with all the other clients, so they don't really store much terrain in the client. Of course, it's really all about selling land and NFTs. Like Decentraland, the idea is to have just enough low-cost virtual world to convince the Securities and Exchange Commission you're not selling a blue-sky investment. It is, however, a procedurally generated metaverse, and one that looks reasonably decent visually.

There's surprisingly little off the shelf code inside the SL viewer. It has its own math library. Its own mesh format. Its own networking system. Its own graphics system. Its own menu system. It's more self-contained than most programs.

This. Most of the people in this discussion are experienced SL users. Many are content creators. Some have been deep inside the viewer code and have made improvements. The typical new user, who's played modern games, sees that Second Life is really slow and leaves forever. That's the problem. Is there any other commercial 3D entertainment system as sluggish as Second Life?