animats

Right. Second Life uses four basic mechanisms to keep this distributed system in sync. Lockstep. One side says to A, "do X". A replies "did X". Sim to viewer examples are RegionHandshake/RegionHandshakeReply, and CrossedRegion/CompleteAgentMovement. Eventually consistent. No matter what order the messages come in, the result is the same at the end. ObjectUpdate works this way, mostly. The first ObjectUpdate from a sim for the object creates it in the appropriate region. If the update for a child prim arrives before the root prim, the child is, temporarily, an "orphan" and goes on hold, not appearing on screen because its position info is relative to the root prim, so the viewer doesn't know where to put it yet. When the parent arrives, orphans are placed with their parents and appear in world. This works well; in Sharpview I check for orphans that never found their parent, and, in normal operation, don't find any. Loss-tolerant. As objects move around, their current position is sent via ImprovedTerseObjectUpdate messages. These are shorter than full ObjectUpdate messages. They're sent as "unreliable", and not re-transmitted, because, if you lose one, you want to use a later one, not a stale one that was retransmitted. Reliable and in-order. Events on the event channel, which is a TCP connection, should be both reliable and in order. Due to some implementation problems and middleware, discussed previously, they're not. Monty LInden is working on this. Some of the things that happen around region crossings and teleports aren't in any of those categories. They're "eventually consistent if everything happens in the normal sequence". This is the underlying cause of most of the things that fail intermittently. The theory on how to do this reliably wasn't well developed until 2011. Second Life was designed well before that. There were no standard patterns to follow at the time. My own thinking on this, and this is just me, is this: Single teleports and simple region crossings seem to have been designed to be eventually consistent. Where they are not, that's an ordinary bug. They mostly work, although under overload things go wrong. We see failures at crowded clubs when too many inbound teleports are underway, for example. We see avatars spending too much time in pink cloud mode. Fast multiple teleports and double region crossings just aren't going to work reliably without some kind of lockstep interlock to prevent a second one from starting until the first one has finished. Trying to make all the cases there eventually consistent is a very tough problem. Preventing a second one from starting too soon is easier. Yes, under certain circumstances this will briefly delay some movement. But if there's any significant delay at a double region crossing, it's going to fail anyway.

New version out: 0.7.0. Download from here. Windows and Linux versions are available. Again, I'm not promoting Sharpview for general use at this time. It's still a tech demo. Use it with a low-value alt. Download requires a password; IM me for access. In this version, you can explore the world of Second Life. Sitting, flying, and driving work. Region crossings work (mostly). Right-clicking on things brings up a pie menu, like Firestorm. The only option that does anything is "Sit". Can't do "Touch" yet, and clicking on things is rather low-rez; it's based on bounding boxes only in this version. This version is intended for testing what's really going on at region crossings. There's new logging. If you open the "Developer->Statistics" window, you can watch the status of regions as they connect and disconnect. Region crossing failures do occur, and when they do, the Statistics window should, below the current region and location, show, in red, the name of the region that seems to be giving trouble. Most region crossing failures seem to involve the avatar's control region (the one that gets the key presses) differing from the region in which the avatar is present. That happens momentarily at each region crossing. If that condition lasts for more than a second, something has gone wrong. Don't know why that happens, but it can be detected and displayed. Incidentally, the old "EstablishAgentCommunication" server side bug, the one that delays region appearance in Sharpview, appears to be fixed in a newer Second Life simulator in test on the beta grid. So the end of that problem is in sight.

There are trees in world which change with the seasons. I've seen some of them come up blank, with no texture, then work right after the season changes.. In Sharpview logs, I see an HTTP 404 error for the texture, indicating the UUID wasn't found on the asset servers. Now that spring is here, the problem becomes clearer. You can get the UUID for your own textures. You could put that UUID in a script or a note card, and change the texture UUID with the season using a script. You can use the texture by calling LlSetTexture to put it on a face of a prim. You don't actually have to put the texture in the tree's own inventory. There's a problem with that approach. Every few weeks or months, LL purges the asset storage system of unused items, to prevent it from filling up with deleted garbage. An item is in use if it's rezzed in world or in inventory somewhere, either an avatar's inventory or an object's inventory. A UUID in a script or notecard won't be found. That's just a string. If the only remaining record of a texture is somewhere the system can't find it, it's going to be deleted. Seasonal trees are the worst case for this. For 9 months of the year, the leaf textures for the other seasons are unused. Every instance of the tree is on the same schedule. So the texture is totally unused for months, and may be deleted. There's a grove of walnut trees in Neumogen with this problem. They've been blank textures all winter. When spring came, they switched to a nice spring bloom texture. So, if you make something with switchable textures, put them in the object's inventory. Don't just use the UUID directly.

See:

Not impossible, just hard. Most games do their baking and optimization at content creation time. SL does some of that work at upload time. That could work better, and might in the glTF era, because more optimization technology is available now than was available when SL added mesh. There's been a lot of progress in LOD generation in recent years. SL squeezes the lower LODs far too much, and the higher LODs not enough. That needs a redo. There's really no reason to reduce mesh below 50-100 triangles when a GPU is doing most of the work. It doesn't save any scarce resource to go down to those awful 1-triangle see-through building faces. Lower LOD limits should be more generous. On the other hand, allowing 20,000 triangles for the highest LOD of a shoe is pointless. That should be forced through mesh reduction somewhere in the asset pipeline. Most of the real drag on the system is avatar clothing. Non-avatar objects have LI limits, which discourages such insanity. This is why I write about the potential of doing some work on meshes during clothing changes. That's the first time that all the layers, meshes, and textures come together. If you're not within touching distance of another avatar, you should be seeing a compact version that's basically an automatically generated animesh. If you get close enough, you get the full avatar and can still read the inscription on their bracelet and count the facets on the jewels of their rings. One SL creator referred to seeing such details, only half-jokingly, as "essential SL functionality". This is a hard problem, but not impossible. We have 2D avatar impostors now, although they're not very good.

Right. I turned it on, tried it out, practiced for a bit, stacked up some prims, and turned it off again. We do need an easier way to build, but this isn't it.

Same thing works in Firestorm. Any way to get snap-to-grid while manipulating that way?

Huh. Can't get a non-physical object to do anything that way, even rezzing a cube in a sandbox. What needs to be enabled in Firestorm?

Nice. Is there any way to rotate objects?

Thanks. If you hover over a grabbable object (physical, but not an avatar; you can't grab avatars) a hand cursor appears. Clicking and dragging will move the object in the ground plane directions, left/right and near/far. If you hold down CNTL, that changes to left-right and up-down. This is all relative to the viewpoint. If you're dragging and moving, when you release the mouse button, the velocity remains, so things can be thrown. SHIFT and ALT don't seem to do anything. Big objects move more slowly, but can still be moved. Density does not seem to matter. Is there more grab functionality I should know about? I was looking at this because I have to implement "Grab" in Sharpview. There's a lot of machinery in the viewer to make "Grab" work. Somebody went to a lot of trouble. It looks like this was intended to be a more widely used feature. Was it originally intended as the primary building tool? If you had scripts to help with automatic alignment after you placed something, and another shift key to get rotation, SL could have fast building, like Fortnite.

Physical objects can be grabbed with the cursor in SL. You can rez "Beach ball (dragged to ground)" from library in Inventory and throw it around a bit. Does anyone use this feature for sports, or combat, or much of anything?

OK. Is the viewer failing to get some info, or botching PBR content, or what? Is something failing to come in over the event channel? Are those new UDP messages broken?

Matthew Ball VC, (venture capitalist, not Victoria Cross) wrote a good definition of the Metaverse a few years ago. Be persistent – which is to say, it never “resets” or “pauses” or “ends”, it just continues indefinitely Be synchronous and live – even though pre-scheduled and self-contained events will happen, just as they do in “real life”, the Metaverse will be a living experience that exists consistently for everyone and in real-time Be without any cap to concurrent users, while also providing each user with an individual sense of “presence” – everyone can be a part of the Metaverse and participate in a specific event/place/activity together, at the same time and with individual agency Be a fully functioning economy – individuals and businesses will be able to create, own, invest, sell, and be rewarded for an incredibly wide range of “work” that produces “value” that is recognized by others Be an experience that spans both the digital and physical worlds, private and public networks/experiences, and open and closed platforms Offer unprecedented interoperability of data, digital items/assets, content, and so on across each of these experiences – your Counter-Strike gun skin, for example, could also be used to decorate a gun in Fortnite, or be gifted to a friend on/through Facebook. Similarly, a car designed for Rocket League (or even for Porsche’s website) could be brought over to work in Roblox. Today, the digital world basically acts as though it were a mall where every store used its own currency, required proprietary ID cards, had proprietary units of measurement for things like shoes or calories, and different dress codes, etc. Be populated by “content” and “experiences” created and operated by an incredibly wide range of contributors, some of whom are independent individuals, while others might be informally organized groups or commercially-focused enterprises. SL has 1, 2, 3 (in that if the users came, the system could scale up), 4, and 7. 5 will get better as SL gets mobile support. Technically, you could order things in SL for real-world delivery, with in-world malls, but LL never really got into that business. 6 is the thing everybody talks about but nobody actually does. The NFT crowd talked big about that and never delivered. There's a metaverse interoperability group working on standards for interoperability, though. That group did something intelligent. They have two task groups, one on file format compatibility and one on rights management. The rights management people are going round and round with NFT hype, while the file format compatibility are talking about interoperable subsets of glTF/USD. (glTF specifies meshes and textures in a portable way. SL is already going that way. USD adds support for animation and scripts. glTF is already well defined, but USD is more of a container for lots of stuff which may or may not be portable.)

That sounds like the old interest list bug, BUG-233107, forgotten in the transition from the Canny system, and not in the final JIRA archive. It was well-explained in this discussion. It appears to be a race condition. I have a workaround for it in Sharpview.

That's a good review. It's a weak book and a sort of OK movie. It has so many familiar pop culture references that mass-market audiences are comfortable with it. This matters. If Disney does a metaverse, they have all those familiar characters to work with. Disney is more likely to do an MMO than a metaverse. They'll want strong control over story and characters, not a buildable open world like Second Life. "Snow Crash", as a movie, has been in development hell for years. Touchstone, Amazon, and HBO each started work on a video version, but it was never green-lighted. Snow Crash has a well-described metaverse in it, but that's not the main subject. It's about a media company and a cult masquerading as a branch of Christianity working to take over the world. That would be sensitive politically.

That works, but takes too much fussing with hover height. With Roth, I seldom if ever have to adjust hover height.

(Black hole) Actually, that was Meta. I cannot imagine how Meta spent over US$36 billion on their metaverse and produced so little. When LL made a big mistake, they produced Sansar, which looked good and worked OK. It just wasn't something anybody wanted. I'm looking forward to seeing how LL markets SL on mobile. Apparently they can make it work technically, but onboarding has to be drastically simplified and the user's first hour has to be a lot better, or it's going to be a niche thing for existing SL users who want to log in on the go.

Not too good. I tried the Gianni Brox avatar. Looks good, fits clothing OK. But the sit height is way off. I usually use Roth, which has a good default sit position. Sit with Brox, and if you're not on an adjustable seat, you're about 0.25m above the seat. That's not adjustable, is it?

I'm not promoting Sharpview for wide use at this time. It's a tech demo at this point. Running it on a Raspberry PI is pointless. It's intended for gamer machines with a good GPU. Minimum is about an NVidia 1060 6GB. It's intended to answer the question, can we make Second Life look like an AAA title on a machine that can run AAA titles. The answer appears to be yes. When I started, people were saying that was inherently impossible. It's not. It does, however, take a lot of GPU memory and network bandwidth. While I've been working on this new implementation, (Sharpview is 100% safe Rust, all new code) though, the C++ viewers have improved quite a bit. They now have ALM as standard, PBR is close, multi-threaded asset decompression is now in several C++ viewers, and in general things are looking up. Looking ahead, the really hard problem is to figure out some way to bake avatars, with all those mesh layers, down to one mesh and skeleton, like an animesh. Like Bakes On Mesh, and done at the same time, when clothes change. That's really hard. But it's necessary if we don't want things to choke every time we get 50-100 avatars in the same region. At least for avatars further away than 2-3 meters, where we can get away with some loss of detail, it's probably possible.

Things are picking up in metaverse land. Now that the NFT clown car has crashed, and Meta/Horizon has peaked, the people who were quietly plugging along are starting to show things. There's M2. This is based on the Improbable back end, and, I think, Unity graphics. It's a real metaverse, in that multiple users can create in the same space. It exists as a tech demo, and you can request a free account. Requires a Google or, I think, Facebook account to identify you. Philip Rosedale is on M2's board. M2/Improbable continues to lose money, yet continues to attract venture capital. Disney recently put US$1.5 billion into Epic's metaverse project. It's not clear yet what that means. It will involve a large number of Disney/Marvel/Lucasfilm/Pixar licensed characters. Readyverse has the rights to Ready Player One and is making something based on that. They have a demo video of what looks like Aech's Garage from Sansar and a MMO which supposedly looks like the driving game in Ready Player One. You can request a test account. VRChat continues to grow, slowly but steadily. 30,748 users on line right now. They're still a little behind Second Life, but may pass us in the next year. Roblox is still losing money, but has a lot of it left, and has a huge user base, average age still stuck around age 14 or so. So those are some of the major players.

If something is showing out of order link numbers viewer-side, taking it into inventory and bringing it out might fix that. On rez, the viewer gets told about the links of a linkset all at once, and they will probably match the sim-side numbers. Probably. The way this works at the message level is that each ObjectUpdate has the ID of the parent prim. ObjectUpdate messages don't have any information about children. Linksets are put together viewer side from parent info alone. . Parent matters, because position is relative to the parent. The viewer doesn't really need child link number. That number is displayed in Edit, but it's just for user display. Attachments, by the way, are children of children at the ObjectUpdate level. It's possible to have a 3-level hierarchy: Attachment->Avatar->Vehicle. The protocol supports a full N-level hierarchy, but the servers do not support that. There was an accepted JIRA to provide a full hierarchy, forgotten in the transition to the Canny system. Philip Rosedale once said that not having a full hierarchy was one of SL's biggest design mistakes. The workarounds associated with not having a full hierarchy dwarf the difficulty of implementing one. Face numbers of a prim are fully synchronized between sim-side and viewer. They have to be, because face numbers are used with mesh data and texture info.

How? ObjectUpdate messages don't have a link number. Although usually all the object updates for a new object come in one message, that's not required.

Port Babbage Caledon Federation of Democratic Simulators

Actually, it should run on anything that Rust can compile for that can handle the graphics. Some tests have been run on Apple silicon. For now, though, I'm only producing Linux and Windows versions. This is still early.

I wouldn't mind having access to UE5's excellent renderers. The rest of UE5 is mostly incompatible with how SL and the Other Simulator do content, though.