Jump to content

animats

Resident
  • Posts

    6,107
  • Joined

  • Last visited

Posts posted by animats

  1. discardedxmastree3.png.02439d3304aaef535a2d569056491451.png

    Just let the Belissarian Department of Solid Waste dispose of it.

    Saturday is trash day.

    (I''ll delete it when the trash is emptied. The bin people might offer a "big trash" script to drop into unwanted items. Put junk next to a BelliBin, and when the bin is emptied, the big trash item would be deleted, too.)

    • Like 2
    • Haha 4
  2. badorb2.png.06f966751fc1e8c2be03636097055791.png

    Shot down on Xmas Eve by this, flying over Bellessaria. No warning. I was having a nice, relaxing flight, and was getting close to my own place there.

    I thought those zero-second orbs had been cleaned out of Belli. Somehow this one was missed. Found the orb, filed the usual abuse report.

    66 kills from one orb! I'm tempted to give the owner a lump of coal. But no. It's usually people who didn't read the instructions, not hostility.

    • Thanks 2
    • Haha 1
    • Confused 1
    • Sad 1
  3. How about a new covenant for new mainland regions? Borrow from the Bellessaria covenant, which seems to be working well. At least the Skybox and ban line rules, which are objective.

    Then add a few new mainland regions, put them on sale, and see how it works out.

    I'd like to see the southeast quadrant of Zindra filled in. There's a hole where four roads dead-end and, if you cam off-sim, you can see the raw edge of the world. The western edge of Bay City has a similar raw edge. Both of those would be high-value real estate if created, and it would be interesting to see how they are used. Auction them off and see what happens.

    Land auctions should extend the time to at least one minute after the last bid, to reduce auction sniping.

    • Like 1
    • Thanks 1
    • Sad 1
  4. Unfortunately, the viewer isn't told about link numbers. The messages from simulator to viewer don't have link numbers. The viewer just numbers them in the order it is told about them. Viewer side link numbers tend to agree with the simulator side link numbers, but there is no guarantee. The viewer doesn't need link numbers; it has a totally different system for identifying child prims and their parents.

    Name your child prims. The viewer and simulator both have good info about names. This is mostly a problem when all the child prims are named "Object". See this old article about how to look up by name in a script.

    • Like 2
    • Thanks 1
  5. 2 hours ago, Ardy Lay said:

    I did not use any of the Second Life Viewer's metric displays to evaluate the performance of my network or the performance of the viewer when I deliberately delayed delivery of packets via my network.  I used the same external tools I use when measuring performance of voice and video transports.

    The Second Life Viewer's behavior as experienced by the user is all that I cared about.  As data was delayed on the way to the viewer, I, the user, could 'feel' the delays in on-screen updates in the location of objects and avatars.  There are two interpolation mechanisms in the viewer that have some effect on this.  You know about them as you have described them in great detail in the past.  I left them at their defaults.

    It's interesting to note that, yes, some packets may arrive too late to be used and may be counted as "lost" by the viewer, and that some message types sent via UDP will be resent if missed, either by loss or excessive delay.  Mostly I was trying to get a feel for how network characteristics affected the end-user experience on Second Life.  I ran all the same tests on several other applications.  Telnet and SSH really sucked to use when delay was introduced.  Voice was okay with some delay except for the time-shift issues that caused participants to overlap and collide when the delay was more than 120ms.  One-way video gives no hoots about delay.  ALL of them sucked when loss was introduced along with the delay, because of the timeouts and additional delays with any retransmissions.  Most voice and video transmissions tested did not loss well.  SRT introduced delays by buffering the video and requesting retransmission of missing data.  It tolerated up to 20% loss unless the bandwidth available introduced so much delay that the retransmitted data arrived too late to be played, limited by the allocated buffer size.  SRT with elastic-buffering just kept increasing the depth of the buffer until it hit a limit and crashed.  HLS, however, just makes the user wait for the data to arrive, no matter how long that might take, at it is downloading files to play sequentially.  

    With the Second Life Viewer, which I personally have used for many hours a day since March 16, 2008, loss in-flight ALWAYS sucks when that which is lost is required.  You know the messages...  The ones that result in retransmissions and timeouts, up to and including disconnects.  However, if the round-trip time is reasonable and there is sufficient bandwidth to carry the retransmissions without causing additional loss, some retransmission activity can be tolerated.  What seems to annoy me the most is the loss or delay for "course updates" that result in increased inaccuracy of avatar position and the loss of "full updates" that result in objects, including avatars, sticking around in the viewer when they should be gone and incidents of some objects, and yes, sometimes entire avatars, not appearing when they should be visible.

    I, however, wasn't adding the complexity of teleporting and region crossing.  As you have described in excruciating detail, these activities are way more sensitive to network foibles and infidelities, resulting in much anguish over disconnections.  I greatly appreciate the efforts being made to find the causes of these sensitivities and correct or mitigate them. 

    That's about what I see. I've also tested introducing delay in the past. See my 5 year old video. Back then, LL people were complaining that region cross failures could not be reproduced, and so they could not fix the problem. So I came up with a way to generate a double region crossing fail every time, by adding a full second of network latency using Linux tools.

    The retransmission time calculation in the "reliable UDP" system may need some work. In Sharpview, I start retransmits at 2*RTT and back off from there. I think the LL code has a retransmission time constant, set decades ago, and it may be too large. Something to be looked at after event poller reliability gets fixed. Monty Linden has been looking at the event poller, and finding ancient low-level code that needs work.

    Some of this is a viewer architecture issue. The viewer tries to cope with message overload  that would reduce the frame rate too much. Some of that is done by dropping some messages and letting the retransmit system send them again. That's why, when frame rate goes down, "packet loss" goes up. That's the viewer, not the network. In a mostly single thread viewer, the question is always how much time can you steal from the rendering thread. That has to be limited. Remember, when SL was designed, nobody had multiple CPUs on consumer desktops. Today, everybody has lots of them, even on mobile.

    In Sharpview, incoming messages are queued and handled in a separate thread. Received packets are never dropped. One statistics graph I display shows the queue length. It's usually length 0, or, occasionally, 1, indicating that updates to the world are caught up. If that queue length starts to climb, something is wrong. Same problem, different approach. Scales to machines with multiple CPUs, which is the point.

    There's a standards group working on metaverse standards. Linden Lab is not a member. But everyone from Autodesk to W3C is. Their big push for 2023 was on glTF and USD standardization for metaverse content. There's a networking subgroup, and I've been sending in some comments.

    • Thanks 1
  6. Ouch. I seem to have upset some people. Sorry.

    My point here is that LOD transitions in SL tend not to be invisible. There's a lot of flickering in the distance in SL. I'm looking at how to fix that. Most game LOD systems do a cross-fade, rather than a cut, on an LOD switch. SL viewers do not cross-fade, but they could. I'm looking at whether it's worth the trouble to implement. The illusion only holds up if the different LODs match well.

    • Thanks 1
  7. goodtreehi640.png.3c4dc340c9968b245e2b4045e079d6fa.png

    Tree at center is at highest LOD. This is clipped out of a long shot.

     

    goodtreelo640.png.64dc42bdc3e566b561559329466347d7.png

    Tree at center is at lowest LOD. This is a transition from a full 3D model to a 2D impostor with just two flat surfaces.

    Note slight blurring. That's the only visual difference. The impostor and 3D model line up properly.

    Now this is level of detail done right. It's standard in video games, but not that common in SL.
    If we could do the transition with a fade out of one and a fade in of the other, nobody would notice.

    (This is from some Sharpview testing. Location is in Electra, in Heterocera.)

    • Like 1
    • Thanks 1
  8. 4 hours ago, Ardy Lay said:

    SL works on slow networks as long as there is no packet loss.  It's an awkward balance but I have done it.  And by "slow networks" I don't mean garbage multi-hop wireless links.  I did say "no packet loss."  This must include UDP traffic. 

    "Packet loss" in SL is strange. What the viewers report as "packet loss" includes packets dropped by the viewer because the viewer is falling behind. Also, "ping time" as reported by the viewer reflects time until a packet is processed along with the next display frame. This is why slow frame rates result in higher reported ping times.

    If you slow the network down, it may reduce the packet loss rate in the viewer, because the viewer has less packets to process per frame.

    Latency is a separate issue. Excessive delay will break some things. A round trip time of 1 second will break double region crossings with vehicles every time.

    UDP packets are (mostly) retransmitted if lost, by SL's "reliable UDP" system. There are a limited number of retries. There are also "unreliable" UDP messages, mostly the ones that indicate something moved. You want the last one of those, not one from the past, so retransmitting where the avatar was ten frames ago is not useful.

    It's recently been discovered that the event poller, which is a slow TCP poll, is much less reliable than it should be. Monty Linden is working on this. Henri Beauchamp and I have some workarounds.

    If you dig deeply enough into this, some unexplained SL behavior turns out to be low level bugs.

    • Thanks 1
  9. 3 hours ago, Scylla Rhiadra said:

    But the key point, surely, is that it will only be able to spit out the kind of information one can already find online. What it's NOT going to be able to do is hold a noob by the hand (so to speak) and lead them through a process. "Can you show me a screenshot of your inventory" is not going to be an option here.

    That's the basic problem with large language models at this point. They're good at general information, if it's in the training set. Coupling them up to the "real world" (virtual or otherwise) for context is not yet working well. It's not impossible, but it's a research topic, not just buying a ChatGPT account. Lots of interesting research going on in game dev AI. Give it a year.

    • Like 1
  10. I've seen a stable where each paddock was a separate parcel. And parking spaces with parking meters! Like rent boxes, but with time limits in hours. But usually, tiny parcels are for some ad scheme.

    • Like 3
  11. 49 minutes ago, Pixels Sideways said:

    This is a bit off topic but why does a mesh that is specifically created with a set number of vertices, edges, faces/triangles at a small size that is 2LI suddenly balloon up to 300L when increased to a much large size?   SL generated prims don't do this so why do imported meshes?

    Land impact policy is complicated. The reason meshes are assigned higher LI when scaled up is that they will go to a higher LOD at a longer range when bigger. They thus use more graphics resources when drawn.

    Nobody, including LL, is really happy with the LI formula. But if changed, and the LI of existing objects ever went up, some objects would be deleted because they pushed a parcel over its LI limit. This has been discussed at Creator User Group more than once.

    When glTF meshes finally arrive, it will be time to look at this again.

    • Thanks 2
  12. 2 hours ago, Zalificent Corvinus said:

    That's how SL works, the server sends UDP packets telling your viewer what's in front of you and with in draw distance, what it's uuid is, what textures it uses, what their uuid's are, colours, gloss/env settings, and now a whole new bunch for PBR.

    It's called the "interest list".

    If you checked the forums , you might even find the numerous threads, with posts by Linden devs, talking about interest lists, and why they havn't been recieved reliably for months, causing that whole "I teleported to location x and the buildings were there, i could walk into them, but they were invisible" complaints.

    People like @animats and various Linden techs have posted on this. Try and keep up.

    SL users should not have to be aware that the interest list system exists. This stuff is way below the user level.

    A brief summary for non-technical people:

    Unlike most games, SL viewers start out with no content inside them. Everything has to come in over the network. Each region is managed by a simulator program, and those talk to each other and the viewers. Simulator programs know what's in their region at all times. Viewers start out knowing nothing about that. Simulators send viewers a list of what's currently in draw range. When a region first appears, there's a big list sent, and thereafter, each simulator sends updates as you move around.

    If the simulator's world view and a viewer's world view ever get out of sync, they won't get back in sync until the avatar leaves the area and comes back. Mostly they do stay in sync, but there are bugs. Currently, those mostly involve teleports and logins, where a huge interest list update is blasted out to each viewer as the avatar enters. Sometimes, especially in regions with many avatars, not all the info gets delivered. When that happens, some objects will not appear in the viewer at all. In regions with many avatars, you sometimes see some avatars with missing body parts.

    Exactly why that happens is not well understood.

    • Like 4
  13. 8 hours ago, Zalificent Corvinus said:

    Instead they will prevaricate, contemplate moving to Vulkan, put that off because its "too hard right now", try cram in some new shiny, that doesn't work properly and that almost nobody benefits from,

    That's a concern. LL has a tendency to half-implement something, declare a victory, and go home. That happened with Project Interesting, with pathfinding, with animesh, and with large crowd support. We're maybe half way through the graphics modernization project (PBR, wide dynamic range lighting, cheaper lights, Vulkan). I hope they don't give up.

    • Like 2
    • Thanks 1
  14. 2 hours ago, Tomas McConaught said:

    How about the Tower of PBR?

    That's a good idea. There's a collection of random examples of PBR over at Rumpus Room, and there are more on the beta grid. But they're not organized for instruction and training. That would be a good project for someone at Builders Brewery. We need a few little dioramas which show scenes with good materials and lighting. A good start would be a well done warm living room, with ordinary items such as wooden furniture and leather upholstery, using PBR textures that match real-world materials, and good lighting. Maybe re-decorate some of the model Linden homes at WelcomeHub.

    Here are some free PBR textures. Enjoy.

    2 hours ago, Paul Hexem said:

    We should be on a much more modern rendering tech. DX10, DX11, Vulkan... We know the possibilities are there thanks to guys like @animats. Except every time that's floated, this same kind of argument comes up.

    Realize that what I'm doing in Sharpview is very bleeding edge. It's all in Rust. It uses many Rust crates that are under heavy development. I've spent several years now pushing and pulling on about a half dozen Rust projects to get things fixed on their side. It's coming along reasonably well, but it's taken much longer than it should have. You cannot yet bet a business on that technology. In a year, it may be different.

    LL is taking a cautious, incremental approach, so as not to break things. I don't fault them for that. I have my disagreements with LL, but not over their cautious approach to the live world.

    Remember, they tried an incompatible redo - Sansar.

    • Like 2
    • Thanks 2
  15. You can do that if you want, I suppose. My Sharpview viewer is nowhere near able to do all the things SL does, as yet. That's why it's experimental, ask for the password, use a low-value alt for testing.

    Sharpview is actually PBR-only, and always has been. That's because it uses a modern renderer. Classic diffuse/specular texture maps are translated to PBR albedo/roughness/metallic maps. Everything is wide dynamic range. It looks OK, but does not match classic SL exactly. LL is running both a new renderer and an old renderer, which creates a different set of problems.

    We'll see how this works out once lighting gets better. PBR in the C++ viewers is still in flux. Eventually we are supposed to get realistic lighting, where lights have real-world lumen values, rather than 0..100, the sun has a very large lumen value, and if you don't light your indoor spaces, they're dark. The intermediate states of this transition, where we are now, are kind of hokey.

    (Hint: if you have a store or public space, turn on shadows, set your environment to dark night and go visit it. If you can't see anything useful, you need lighting.)

     

     

  16. 3 hours ago, Setsuki Takeda said:

    A place with a few "common sense" rules like Belli has, but with more open design for people to actually build on, both commercial and residential.

    The success of Bellessaria is a good argument for using some of the Bellesaria covenant terms on mainland. The minimum height for skyboxes is the main one.

    • Like 4
    • Haha 1
×
×
  • Create New...