Jump to content

animats

Resident
  • Posts

    6,143
  • Joined

  • Last visited

Posts posted by animats

  1. I put the simple prompt "futuristic house" into Stable Diffusion, and it generated some nice designs.

    house1.thumb.png.9992c42520c36685532ae2352ec5a38b.png

    House 1

    house2.thumb.png.ffa020e3d1fe48dabe5c6b53ec6755ad.png

    House 2

    Not bad ideas for SL.

    house6.thumb.png.57cde34b4640eeb1583e2ff20840d76b.png

    Interior

    I suspect that someone included Architectural Digest in a training set. Or they really liked Zaha Hadid, who's into those linear light strips.

    (These are all synthetic AI-generated images, from the Stable Diffusion program, if you're not familiar with this sort of thing. It's a useful way to get creative ideas.)

    The warmth of these images is impressive. This is proper use of environmental reflections. As PBR and more light sources start to work, SL should look this good. Just a little environment reflection on interior surfaces, with reasonable lighting, makes interiors look warm. If you want to practice using PBR, take some existing house model, tune it up, and light it well, so it looks this good.

    There's a wood-lined room at Rumpus Room which demos this in PBR. It's overdone, though. Back the shiny down to about half those levels, and it should look like this. You want people to say, "That looks beautiful and real", not "Ooh, shiny thing!"

    Possible theme for the 2048 m^2 houses. They need space. You can't put architectural statements too close together, or the result looks tacky.

    • Like 4
  2. 1 minute ago, Henri Beauchamp said:

    Glad to hear it !

    Strange that other viewers than mine (which, AFAIK, is the only only one to use extrapolated values) are not suffering from the same delays as the ones you encountered... 🤔

    Wondered about that myself. Before I started sending any throttling values, and was only showing one region, I got ObjectUpdate messages faster.

  3. 9 hours ago, Henri Beauchamp said:

    I extrapolated those for higher bandwidth settings in the Cool VL Viewer:

    // Bandwidth settings for different bit rates, they are interpolated /
    // extrapolated.
    // The values are for: Resend, Land, Wind, Cloud, Task, Texture, Asset
    static const U32 BW_PRESET_50[TC_EOF] = { 5, 10, 3, 3, 10, 10, 9 };
    static const U32 BW_PRESET_300[TC_EOF] = { 30, 40, 9, 9, 86, 86, 40 };
    static const U32 BW_PRESET_500[TC_EOF] = { 50, 70, 14, 14, 136, 136, 80 };
    static const U32 BW_PRESET_1000[TC_EOF] = { 100, 100, 20, 20, 310, 310, 140 };
    static const U32 BW_PRESET_2000[TC_EOF] = { 200, 200, 25, 25, 450, 800, 300 };
    static const U32 BW_PRESET_10000[TC_EOF] = { 1000, 500, 25, 25, 1450, 5000, 2000 };

    (see the linden/indra/newview/llviewerthrottle.cpp file in the Cool VL Viewer sources)

    Note however that these are just clues for the sim server, and as I understand it, the latter is the one making the actual decisions.

    It would also be about time to kill the ”Texture” and ”Asset” slots, in SL (not in OpenSim !), since those are now all transmitted via the ViewerAsset capability in SL...

    Oh, and ”Cloud” messages were removed years ago, too, from SL (I am now generating them viewer side, in the Cool VL Viewer, so that I can still enjoy Classic Clouds in SL).

    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.)

    • Thanks 1
  4. On 11/14/2023 at 9:55 PM, Monty Linden said:

    But for the record, I believe the rule is to send it (throttle info) only to the main region every time you arrive after TP or RC. 

    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?

  5. A bit more info. I've been logging neighbor startups and region crossings for a while now. Here's how the happy path works:

    1. 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.
    2. Avatar crosses into the gaining region and gets at least 1m past the  boundary. This triggers the region crossing.
    3. 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.)
    4. 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.)
    5. 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.

    • Thanks 1
  6. 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.

    • Like 2
    • Thanks 2
    • Confused 1
  7. 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.

    • Like 2
    • Thanks 2
  8. 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.

    • Like 1
  9. 2 hours ago, BilliJo Aldrin said:

    Thats how Horizons got so big isn’t it?

    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.

     

     

    umbrellacorp.png

    Employee break area of the Umbrella Corporation. Horizons Thule Central.

    • Like 1
  10. 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.

    • Like 4
  11. 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.

  12. 1 hour ago, Monty Linden said:

    In this test, this is right after login so the first EAC is implicit in the login payload.  Most of this test is movement between two regions with frequent movement to the far end of 13000 beyond drawing distance.  There was a third region involved but it wasn't local so I don't have packet data from it.

    I expected to see additional EAC messages for the two test regions but never did.  So this message has more conditionals on it that I thought.  *sigh*

    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.

    1 hour ago, Monty Linden said:

    At 1:50:34 or so I think the viewer kicked off a coordinated teardown of 12035:

    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.

    • Thanks 1
  13. 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!

  14. 2 hours ago, Monty Linden said:

    Haven't had time to run down protocol details so that they can be documented.  Still a thing I want to see.  I've been doing dev test of the new EventQueue logic, among other things.  I can confirm that the outer race condition I talked about before (LLEventPoll destroyed in viewer, LLAgentCommunication retained in simulator) does, in fact, occur with unfortunate results.  So I have some work ahead of me...

    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.

  15. 13 minutes ago, Henri Beauchamp said:

    Likely a race condition between the two regions you are crossing to when in a corner and moving to the opposite region on the diagonal. As I guess it, the race could be as follow when, e.g. you are in region A and you walk NE to region B that you want to reach, and there's region C, North of A and West of B: you cross the corner and shortly get into C and from there cross to B. Normally, you would get:

    • CrossedRegion sent by departure region A with destination region C.
    • Region A hands over to C (server to server messaging).
    • CompleteAgentMovement sent by the viewer for region C.
    • CrossedRegion sent by transit region C with destination region B.
    • Region C hands over to B (server to server messaging).
    • CompleteAgentMovement sent by the viewer for region B.

    But, what may happen, due to variable region ”ping” time with servers and reactivity (depending on their load), and the moment they are when receiving the messages during their frame (start of frame: message taken into account immediately, middle of frame and message processing delayed to next frame), you could actually get:

    • CrossedRegion sent by departure region A with destination region C.
    • Region A hands over to C.
    • CompleteAgentMovement sent by the viewer for region C.
    • CrossedRegion sent by transit region C with destination region B.
    • Region C busy re-serializing the agent data it just de-serialized but must still update before re-sending to next region, meaning likely a one frame delay.
    • CompleteAgentMovement sent by the viewer for region B. Message rejected by region B, since no handover was received for this agent yet...
    • Region C hands over to B (finally, but after the viewer sent its own message !).
    • Region B confused: where's that agent ?... Why did not I get its CompleteAgentMovement ?

    Of course, this is just a wild guess... But it could be fun to try and work around this guessed race condition to see if the hypothesis is correct. Viewer-side, we could try two things, when two region border crossings happen in a row:

    • Delay the second CompleteAgentMovement a little bit (say, by 250ms, or a ”ping” delay + one region frame (20ms)).
    • Send a second CompleteAgentMovement to B, if not ”hearing” from it after a couple seconds...

    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.

    • Like 2
  16. 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.

     

    • Like 1
  17. 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.)

     

×
×
  • Create New...