animats

Thanks. Cranking up Sharpview's values to the highest values shown there reduced region loading time from about a minute to under 10 seconds. (Tested on Clockhaven in New Babbage.)

OK. Doing that. Current values are // Resend, Land, Wind, Cloud, Task, Texture, Asset in kb/s. [ 100.0, 100.0, 20.0, 20.0, 310.0, 310.0, 140.0 ] all multiplied by 1024.0 before sending. Object updates are coming in far too slowly. About one every 20ms or so. Regions appear too slowly. How can I make the simulator send object updates faster? Is there something else I have to set?

A bit more info. I've been logging neighbor startups and region crossings for a while now. Here's how the happy path works: The gaining sim (the one the avatar is about to enter) becomes live. User can see into the gaining region. See the event chart above for connecting to a neighbor sim for this sequence. Avatar crosses into the gaining region and gets at least 1m past the boundary. This triggers the region crossing. The losing sim (the one the avatar is leaving) sends a CrossedRegion event to the viewer via the event poller. (This is only sent once. If that message is lost, the avatar is stuck until logout or teleport.) The viewer sends an AgentMovementComplete message to the gaining sim. This handshake completes the handoff of avatar control to the gaining sim. This whole process happens in lockstep. Delays or lost messages here stall the avatar. (The handoffs consistently happen in the right order. I've walked an avatar back and forth across the corner of a 4-region sandbox many times, with Sharpview checking for consistent handoffs. 100% success.) All that is about handing off control. Moving the avatar as an object to a new region is done with object updates. The normal case, walking across a region boundary, causes an ObjectUpdate for the avatar coming from the gaining sim. The viewer notices that the avatar has changed region, makes it appear in the gaining region, and kills it off in the old region. This is the same process that happens when an ordinary object crosses region. So that's the happy path, a single region crossing of a single walking avatar into a live region. That works reliably. What can go wrong? Mostly things involving race conditions with ObjectUpdate messages. Old delayed ObjectUpdate messages from the losing sim can tell the viewer, incorrectly, that the avatar moved back to the losing sim. At region corners, there's a sequence of ObjectUpdate messages for the regions crossed, and those might not arrive in sequence. Viewers have to be prepared for this ambiguity. This is a consistent-eventually problem. It's different from the lockstep system for transferring avatar control. It's all one-way, sims to viewer. Things may be temporarily confused, and they need to resolve quickly into the desired end state where all parties are in agreement on where the avatar is. This is probably part of why region crossings work worse on slow links. The odds of out of order receipt increase. Haven't gotten to vehicles yet. Lots of opportunities there for ambiguous out of order situations. A possible option for getting out of ambiguous stuck situations is for the viewer to ask the simulators where the object is. The viewer could send a RequestMultipleObjects message to the various simulators involved in a region crossing, for the objects exhibiting ambiguous behavior. The simulators that don't own the object won't respond. The one that does will repeat the last ObjectUpdate. This may be a way for viewers to get stuck situations un-stuck. Not yet sure if this is necessary or desirable.

Steam has about 20,000,000 users online right now, and they all have gamer PCs. SL has about 45,000 users online. Plenty of room for growth there. SL on a phone screen is just too cramped for a big virtual world. It's a nice capability to have, but too limiting.

This is an argument for linear tier charges, so that if you're just a little over, you don't get a big jump in the monthly charge. People who are just a little over sometimes cut off part of the parcel to round down to a standard size and save a big monthly charge. This leads to those useless micro-parcels.

Using Sandbox Wanderton on the main grid for now. It's quiet. (Sharpview testing. With extensive logging on, it's easier to test some place where little is happening.)

For testing purposes, I'm looking for some place on the beta grid where four regions come together as flat terrain, all can be entered by any avatar, and there's no solid obstacle atop the corner. Morris has a big tree and planter at the intersection. Leafeon has a banline. Main Open1 has skill gaming regions at the corner, so you have to be enabled for gambling. Thanks.

Happy Holidays from New Babbage. Sharpview demo. Multiple regions are displayed. Still a 1 minute wait at many region crossings before the next region appears, as above.

Here, if anyone is interested, is the code my NPCs use for that: https://github.com/John-Nagle/l*****ils/blob/master/npc/pathavatartrack.lsl The basic search for agents is the usual agents = llGetAgentList(AGENT_LIST_PARCEL_OWNER,[]); Lists of avatars are checked with llListFindList, which is linear search but at the level below LSL, so it's not too slow. All lists are by avatar UUID, not name. What all that is doing is finding new avatars on the parcels to greet. There's much filtering. Avatars at huge elevation differences (skyboxes) are ignored, because the NPCs can't get there. Avatars are only to be greeted once per visit, so there's a list of avatars greeted and a list of those who left within the last five minutes, so stepping off the parcel doesn't cause an immediate re-greet. There's a list of avatars where greeting failed (the NPCs couldn't get close to them), and those will be re-tried, at increasing time intervals. Of the eligible avatars, the one closest to the NPC is greeted first. This keeps the NPCs from being too annoying. There's also a check for running out of script memory, to avoid script crashes if there are too many visitors. Notecard and landmark distributors could benefit from some of those checks. There are places which keep hitting on you to accept their notecard. Tracking who's been seen recently and who's been processed (given a notecard, greeted, etc.) makes such tools much more tolerable. Oh, and don't send popup messages to off-parcel avatars. That's a TOS violation and really annoying when you're driving.

Horizons is strange. It's adult, it's overpriced, and very little of interest seems to happen there. The mid-century modern theme was a cute idea, but the pre-built houses were so badly laid out as to be useless, waterways have a drawbridge every 100 meters, and everything is either colored tan or glows pale blue. Employee break area of the Umbrella Corporation. Horizons Thule Central.

There's an incredible amount of vacant land in SL. Zindra used to look more full, because the main land baron would put some filler building on his empty properties. He's no longer bothering, nor are his competitors. So there are entire half-regions empty, and overpriced. Corsica is still cheap. I have a little roadside plot there, backing up against a huge area of abandoned land. I should do more with it. Right now it has a little garage/repair shop and a spare bike, plus one of my NPCs to keep an eye on things.

Since I have a house on the west coast of Bellesaria, I get to see very nice sunsets over the water. Sunrises, not so much.

The built-in trees and grasses are special case built in objects. They're not meshes. They're not sculpts. They're not prims. Their scale is interpreted differently for each tree species. They have their very own level of detail system. They have strange ownership and placement rules. They don't have a physics model, so you can walk through them. They're generated procedurally, and each one is supposed to be different. So, no surprise that they don't encroach in the same ways as other objects. That probably has something to do with their scale weirdness.

What are you trying to do? If you're just fading something out slowly, consider texture animation where the alpha is just a gradient.

Cloudflare's anti-spam protection has become too aggressive. The Firestorm people may need to adjust their Cloudflare settings. I keep getting CAPCHAs over and over. Filed a Firestorm JIRA. https://jira.firestormviewer.org/browse/FIRE-33409

That agrees closely with what I see in Sharpview. Login region has implicit EAC. Second region gets EAC immediately. Additional EAC messages for nearby regions don't show up. Try waiting a minute or two, though. Maybe you'll see the one minute timeout I see. OK, so the region teardown was viewer-initiated. The viewer receiving a new set of caps then makes sense. I was worried about the simulator suddenly deciding to change the caps, which would confuse the viewer, but that apparently is not what's happening. Good. I'd suggest re-running this test just standing near a region corner. No need to move the avatar for the first two minutes. Then try a region crossing. This is good. You're seeing many of the things I'm seeing, plus other problems which might stem from retries down at the libcurl layer.

Now that's interesting. (To about four people, anyway. Apologies to non-technical people reading the forums.) It looks like we only see sim->viewer events here; this is just the event channel, and that's one way. At packet #1102, there's are EnableSimulator events for (12035) and (13000), which numbers I assume identify the regions. At packet #1532, there's an EstablishAgentCommunication for (13000). But there's no EstablishAgentCommunication for (12035) anywhere. So region (12035) won't become visible yet; without a seed capability, the region capabilities cannot be fetched and the region's assets cannot be loaded. The user should be seeing empty space for region 13000 at this point. That's the behavior that I see in my logs - a missing EstablishAgentCommunication message. One region gets its EstablishAgentCommunication message right after EnableSimulator, and another doesn't. That's not right, I think. Now, at packet #1975, we see a CrossedRegion (13000), with the note "Seed cap for 13000." But that would indicate the avatar moving into a region that hasn't gone live as a neighbor yet. This looks to the user like going off the edge of the world. Is that correct? The info in CrossedRegion is sufficient to bring up a cold region, but that's an emergency measure only needed when the neighbor system somehow fell behind and didn't make the region appear before you got there. Fast flying might do that. (I'll have to try the F-16 on afterburner again; that's a good stress test for fast region crossings.) I've never seen that happen in Sharpview just walking around. Walking into a region that hasn't had an EstablishAgentCommunication yet seems to generate an immediate EstablishAgentCommunication for me. What I see in that situation, prior to the CrossedRegion, is that everything to bring up the region has happened except the EstablishAgentCommunication. RegionHandshake and RegionHandshake reply are done. ObjectUpdate messages are coming in. But asset fetching is on hold because the seed capability, and thus the region capabilities, are not known yet. (Different regions can use different asset servers. I don't think SL does this any more, since everything is in one data center now, but it may have done so in the past. The Other Simulator, being decentralized, does that routinely. So the viewer shouldn't just use an asset server URL from some other region.) At packet #4713, there's a note "New seed cap for viewer". What does it mean when the seed capability changes? Is that supposed to happen? Do the UDP IP address and port change, too? Should the viewer tear down the region and rebuild it from scratch? Onward!

Great! Reliable event transmission will be a big win. Things break if events are lost. Something I saw recently was four HTTPS status 500 returns in a row from the event poller. Is that indicative of trouble? Error 500 seems to precede other things going wrong, but I'm not sure if that's related. Normal nothing-to-send return is a premature EOF. (I retry everything except 404, but after three errors I add a short delay to prevent hammering on a broken connection.) Current Sharpview polling policy remains to make a request and wait 90 seconds, letting the server do the timeouts. I'd suggest sending, when there's no event to send, an empty block of LLSD, or some other kind of empty item. Then we could clearly distinguish errors from no-data situations. On the region crossing front, I understand and have implemented the happy path for a walking avatar, but am not sure about the hard cases yet. Working through the various error situations. I can now walk about halfway round Robin Loop in Sharpview before something breaks. What I figure out I will document in the wiki, as I did for login and Beq did for neighbor attachment.

Right. Or at least maybe. I'd been thinking of scenarios along those lines too, looking for a race condition. But I would expect that CrossedRegion is only sent after sim-to-sim arrangements are complete. CrossedRegion contains the IP address, UDP port, and sim capability for the viewer connection to the gaining region, info that comes from the gaining region. So both sims are talking. The handover from sim C to sim B should be complete before sim C sends a CrossedRegion to the viewer. If the sims work that way, then there's no race condition. I think. Of course, it may well be that the protocol does not in theory have this race condition, but the implementation does. From Monty Linden's previous discussions, the event queue machinery does have known problems. It's entirely possible that non-corner region crossing fails, which are rare, are caused by lost CrossedRegion messages. This all seems to be somewhat independent of the avatar as an object crossing. The avatar gets created in the new region, just like any other object. Not clear how that interlocks with CrossedRegion/CompleteAgentMovement. The general SL observation is that you can walk across a region corner without problems, but vehicles with avatars have serious trouble. I've tried walking across a corner in Sharpview (main grid, road intersection in Zindra, because those have a nice big X on the region corner) , and nothing broke in the first few tries. Sharpview doesn't do "sitting" yet, (object selection by mouse isn't coded) so I can't yet try vehicles. You might test that with your viewer. It's interesting that CrossedRegion contains all the info needed to start up a region in the viewer. Normally, that info is not used; if you're crossing into a visible neighbor region, the viewer is already talking that region. There's probably some legacy reason for this. Anyway, it's clear now that if a CrossedRegion message ever gets lost, you have a region crossing failure. Viewers can detect this. If you're off the edge of the region by more than 1 meter (that's what triggers a region cross) and there's no CrossedRegion message within a second or two, there's been a fault. So that's worth catching and logging. We're getting closer to understanding region crossings at the message level. Eventually, more will become clear.

Now that Sharpview handles region crossings, a few preliminary notes: CrossedRegion is only sent once by the simulator. If a CrossedRegion event is ever lost, your avatar is stuck, because the viewer won't start sending agent updates to the new region. This is a strong argument for making the event poller not lose messages, short of a sim crash or logout. Recovery from this usually requires at least a teleport, and maybe a logout. The viewer replies to CrossedRegion with CompleteAgentMovement. If the viewer doesn't send that reply, the avatar is stuck sim-side. Very stuck. On the Other Simulator, it takes two relogs to fix that, and the stuck avatar can persist for days. That's observed behavior. Now a bit more speculation. There are some implicit race conditions around these key events. The normal sequence of events is sim->viewer CrossedRegion from the losing region, then viewer->sim CompleteAgentMovement to the gaining region. Near a region corner, things get complicated. When vehicles and multiple avatars are involved, even more complicated. More on this in future, once more data is available. From previous tests, I've shown that double region crossings start to fail when network round trip time passes 500ms, and fail almost all the time at 1000ms. But nobody understands the failure mode. I suspect it involves this CrossedRegion - CompleteAgentMovement sequence. That three way handshake between losing sim, gaining sim, and viewer seems to be on the critical path for some sim-side events.

Here's a video of what I've been talking about. (Video is on PeerTube - no ads!) After all this discussion of what's happening down at the message level, I wanted to show what this looks like at the user level, in Sharpview. Visuals of the problem make it easier to understand. It's the usual region corner for testing, Morris/Ahern/Dore/Bonifacio on the beta grid. The login region appears, and then one neighbor region appears in Sharpview. Then, there's a one minute wait. Then the rest of the regions appear, as discussed above. Henri gets a 10 second wait; I get one minute, stuck waiting for EstablishAgentCommunication. We don't know why. Here, after the regions load, I go visit each of them. Sharpview can now do region crossings. At least the simple cases. The region crossings work fine here. Those regions are completely live. So that's what I've been stuck on for a month now. (Yes, some of the Linden trees are very tiny. Scale for Linden trees is different from everything else, and the special case for that tree species isn't set up properly in Sharpview. Something else for me to fix.)

Tilia is a regulated money transmitter. To file a complaint with Tilia's California state regulator, click here for the California Department of Financial Innovation and Protection complaint form.

Do you know of an in-world example of that done well? Usually, if normals, roughness, and albedo are misaligned, it looks pretty bad.

That's emissive, not glow. Glow is when the light comes from outside the object's boundaries. That's because the light hit the environment or the eye was looking at something too bright. Glow fakes that by having a light source outside the object boundaries. The whole point of PBR is that it does what light really does, not what you think it does.

Some legacy technical features we could do without: Classic "Glow". It usually looks awful. Glow in PBR is supposed to be a side effect of a bright light interacting with the environment, and eventually SL should have that. Prim types Test and 33. So obscure I've found only one in world, using a tool that looked for it. And that prim was invisible. The built-in bump maps. There are some built-in bump maps. Some Linden trees use them for the dirt in the flowerpot. They're not used for much else. The built in hack modes to guess at normals from textures are not very good, either. Use Deep Bump, the Blender plug-in, for that. Different scaling for different texture maps (normals, roughness, etc.) on the same object. This is seldom used, but adds complexity to the UI. If it's used at all it's because someone really wanted to apply two texture layers at different scales to the same object, and tried to fake that with scale factors. Standard glTF does not support this much, but it was put into SL's PBR implementation. "Wear" (as opposed to "Add") for mesh avatars. Seldom if ever does it do the right thing.