animats

Is it open now?

Yes, that was strange. I suspect that happens occasionally and viewers compensate for it. I'll find the part of the log file that matches the video and make it available. (I use Hardlimit because it's free, and doesn't insert ads. YouTube has too many interruptions now.)

I've received dialog boxes that say "You have been permanently banned' while driving on Linden roads. That's all the popup box says. No source or object is mentioned. Nothing happens to my avatar. Presumably it's some rather lame security orb.

That's what I'm doing now. Good to know the C++ viewers do it too. A few bogus messages from the old region are normal at a region crossing, but in the video i linked, the old region or regions kept sending bogus ObjectUpdate messages for tens of seconds after the avatar and vehicle had left the area. Hundreds of ObjectUpdate messages from the wrong simulator. I have detailed logs for that video if anybody cares. I've seen this at two region corners. It's an indication that the simulator to simulator handoff somehow became confused. The viewer sees fallout from that, but it's not a problem with simulator-to-viewer network traffic.

Right. Especially since Disney and Epic are now working together. We're probably going to be able to visit large Disney-themed virtual worlds soon. SL may have to up its game.

Sharpview 0.10.0 has some serious problems at some region crossings. Here's a video. In a double region crossing, it's possible to get a situation where two regions are both sending ObjectUpdate messages for the main agent object. In Sharpview 0.10.0, that produces terrible visuals and eventually a disconnect. I put a check in my development version, 0.10.1, which ignores bogus ObjectUpdate messages which try to change the main agent's region away from the region that the most recent CrossedRegion message said was in charge. This workaround helps a lot. No more vibrating between two regions. I still log the bogus messages, of course. I suspect that the C++ viewers have a similar check. I've been testing this by logging in an alt with Sharpview and seating them in a YavaPod or SLRR train, then just letting that run for an hour or so.I get about one fail per hour. It falls just like it does in Firestorm - the avatar is Left Behind, seated on the ground, while the YavaPod or train goes on without them. Avatars come off at the usual spots, such as that spot on the Heterocera SLRR main line where the tracks cross over a region corner. So I've achieved bug compatibility. Monty Linden has some fixes to region crossings in test. Right now, they're up on a few regions on the beta grid. I've tested and haven't had any failures there so far. This is a big step forward.

This came up in the TPV meeting today, and after some discussion, it became clear how some new backwards-compatible extensions to UDP messages really work. So I updated the SL wiki to document this. See https://wiki.secondlife.com/wiki/Packet_Layout#Extensions_for_backwards_compatibility If you understand this stuff, please check and update. Thanks. I've been quietly updating the wiki when I discover something that is hard to figure out and TPV developers really need to know. Mostly for my own benefit, so I have a record of what I've found. This one is an issue for anything which has to decode or generate those messages using other than the standard Linden Lab C++ code. That now includes Sharpview, the new mobile viewer, Crystal Frost, libopenmetaverse, the Other Simulator, control programs for such things as SmartBots... We're getting quite a ecosystem going.

The latest thing to be automated with AI: creating 3D models of interiors. https://yueyang1996.github.io/holodeck/ Generates Unity assets, which can probably be converted to SL assets.

There have been real therapists with verifiable credentials in SL. "A basic understanding of psychology and mental health or willingness to learn" is not enough.

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.