Jump to content

Ardy Lay

Resident
  • Posts

    1,861
  • Joined

  • Last visited

Posts posted by Ardy Lay

  1. On 12/12/2022 at 7:05 PM, SorachaNicEoghain said:

    These days, I have been spending a lot of time in London and other newbie friendly sims and one issue has come up almost every time I've been there, AFK avatars. I usually end up explaining they should just ignore them and don't let it negatively impact their secondlife experience. It seems to be a big issue for secondlife though and very off-putting for new residents. Why do people do it? To increase traffic? Because they fell asleep? To create lag and take up space? To creep people out and make them feel ignored and lonely? 😆. Those last two are a joke. Am I the only one who finds the abundance of afk avatars at events and public sims unpleasant? I tp out as soon as I get a whiff of afk at a club; I'm very active in local chat and I tip well. So for dj's, you can make more money in tips if you invite people who tip and engage with local chat instead of logging in alts. 🙃😜.

     

    So on a scale of 1 to 10 where, 1 = AFK avatars are a pestilence to 10 = AFK is awesome! Why would anyone want to engage in world and explore when you can randomly stand around waiting to be imed?

    Where are you on this scale?

    Do AFK avatars drive new residents away?  Absolutely, yes.  But not absolutely every one.  What I see is, people come in, say nothing, or something, doesn't seem to make much difference, then, if nobody greets them in a few seconds to several minutes they silently leave or utter something, sometimes something rude, then leave.  Ideally, people will always get some non-automated greeting soon after they arrive.  We don't pay people to be greeters, so, it's hit and miss whether someone notices the arrival and says something to them.  It's our home.  We should be allowed to lounge around, be distracted, take naps, wash dishes, do laundry, come back and read chat history, repeat.

    • Like 2
  2. On 12/19/2023 at 9:18 AM, Quartz Mole said:

    I'd like to remind people that the Linden Lab Official:Forum Participation Guidelines start with 

    It would, I think, be generally appreciated, not least by me, if people could express their disagreements about PBR without resorting to sarcasm or otherwise belittling people with whom they disagree.    It doesn't add anything to the discussion, and I fear it can only be off-putting to people who want to ask questions about this new (at least for SL) technology but are worried about being dismissed as idiots for not understanding things.

    Looks like they forgot again.

    I streamed some crowded events using Second Life Release 7.1.2.7215179142 (64bit) and viewers were expressing incredulity over the smoothness of my video stream.  I hadn't the heart to tell them that my 60 FPS video stream was being captured from a viewer that was rendering at 120 FPS at the outset of the adventure, limited by the "sync rate" of my 5120 x 1440 display.  SL window was 1920 x 1440.

    Unfortunately, as time passed, the rendering slowed down, but not because the crowd was getting larger, nor because of a change of scenery.  What I saw changing was avatars were changing outfits as the 3 hours long party progressed.  Not sure if this changing of rendered outfits caused an accumulation of sludge or what.  At the end of the 3-hour event, rendering was down to 48 FPS in a crowd of 38.  Some attendees had said goodby and logged out.  The crowd peaked at 44 attendees if I include myself.

    • Like 2
  3. 15 hours ago, Love Zhaoying said:

    I love it when you think my posts are serious! It means I have to put a "is joke!" disclaimer after all!

    They will ATTEMPT to shoot you down using derisive language and fail whether you are joking or not.

    I'm not tinkering with making "materials" until stuff settles down.  I'll look at what other people make and not stress over it.

    • Thanks 1
  4. Yeah, I bumped into a tree while walking and it sounded like I hit it with a truck bumper.  WHUD!  I then got out some things and walked on them, bumped into them and dropped then.  All sounded alike.  Weird.  Crazy loud too.  The one impact I tried that wasn't loud, and perhaps didn't make a sound at all, was by control-dragging an inactive object into an avatar to move them.  Dragging an active object into them did go WHUD!

    • Like 1
  5. 4 minutes ago, Candide LeMay said:

    If we had 2K/4K textures, in proper hands it could mean one material slot used for the whole mesh instead of multiple slots = fewer draw calls = better rendering performance.

    Yes, atlasing is good, but you and I both know that "proper hands" are diminishingly few in Second Life.

    • Like 2
  6. My take on all this is:

    • Experts are people who gave themself the title.
    • People repeat outdated first and secondhand information as it it's eternally relevant.
    • People describe performance of hardware they don't have.
    • People describe performance of software versions they have never used.

    So, looks like "people" is what all those have in common.

    So, after seeing all this rubbish flying around, I'll add some more.  FRAMES mean nothing.  What's in a frame?  Stuff.  How much stuff?  Dunno.  So, "frames per second" is completely useless as a performance metric BUT is a really good comfort metric, as long as the inter-frame time is fairly consistent.

    I remember, long time ago, GPU specifications had stuff like how many triangles it renders per second and what its texture fill rate is.  Second Life Viewer does report triangles per second.  Would triangles per second anywhere be useful to maybe come closer to a comparable metric than frames per second at such-and-such nightclub on December 11th at 2:26 AM wearing high-heels and a French teddy?

    Oh, in case that wasn't clear, the myth is that FPS is a useful bragging metric in Second Life.

  7. 18 hours ago, animats said:

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

    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. 

    • Like 1
  8. Just now, AmeliaJ08 said:

    I agree with most of your points, take issue with the first and will continue to say SL runs poorly on everything :) it just does, the mightiest gaming PC will be brought to its knees in a sufficiently busy scene due to engine issues.

    Aside from these points though I'll add another: the ongoing insistence by many people that using SL over a WiFi network is a recipe for disaster. I get where this advice comes from (junky WiFi routers which were common in SL's early years) but really? the bulk of users will be accessing SL over a WiFi network, it's fine. Most routers are absolutely fine now too, most ISPs provide something that will work just fine, many even provide genuinely good ones (in consumer grade hardware terms) these days due to customer demands

    WiFi has definitely improved, but we often get calls from people using "mesh", and THE PROBLEM IS ALWAYS PACKET LOSS on their WiFi.

  9. 4 hours ago, Love Zhaoying said:

    People often focus on the computer and completely leave out the network speed/bandwidth etc..

    Keep it up and I will TOAD you and make you run SL on dial-up!

    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.  I have total control of the data rate permitted on my home fiber Internet connection.  I work for the company that provides it.  SL works great on our network as long as the traffic from server to client isn't going through Cogent when Cogent is congested.  Fortunately, we can just prone prune them when they get annoying.  Anyway, I have set my data rate down to 768 Kbps and had SL work fine.  At that data rate the downstream and upstream traffic are "rate-shaped", meaning buffered and released on-rate.  I said "fine" instead of "excellent" because sometimes there is some loss because the buffer is of limited capacity.  At somewhat higher rates, the buffer doesn't overflow, and at much higher rates, the buffer appears to be empty all the time.

    I know that "FPS" is the quality metric that users care about but it's not a decent metric to use when trying to quantify the rendering work being completed in a finite time because the content of frames is highly variable.  Maybe use triangles?  I know SL renders a hell of a lot of triangles per second.  Try comparing that metric to triangles per second in some other rendering engines.

    • Like 2
  10. 11 minutes ago, Solar Legion said:

    That's nice. Not interested in anything whatsoever except making certain actual facts on this are being utilized and the actual history and present situation are understood.

    You may call that "attention seeking" if you like - a response to my posts was not required of you.

    Don't like being corrected? That's fine. Don't pretend it is anything other than what it is: Being corrected.

    As for "attention seeking" - there is no need to announce blocking an individual. Block or do not - announcing it is nothing more than seeking drama.

    Yo.  Dude.  You are ...  what are you doing again?  Explain it so Linden Lab can understand.

    • Confused 1
  11. 35 minutes ago, Abnor Mole said:

    In lieu of that, my recommendation is to do this:

    1. Use Ctrl+Shift+Alt+P to show property lines. (If you are on water also use  Ctrl+Shift+Alt+7 to toggle off water)
    2. Create a box and stretch it very thin (essentially a plane)
    3. Use Snap to Grid to place it right on the property line.
    4. Move your objects so none of them poke through that plane and you are safe.

    I have done this.  Of course, It also works for making stuff at altitude if you move your plane up high.  When this doesn't work is when the object being placed has a visible representation that is smaller than the bounding box.  That had me also enabling bounding box metadata display, and at that point the screen got so busy that I could not tell what was going on and just gave up.  It would have been much easier if the viewer or simulator could just inform me about the one thing I am working on.  This is Second Life, not manual technical drawing on paper where my only option is to make construction lines.

  12. On 12/14/2023 at 10:52 AM, Abnor Mole said:

    I wonder if what they are thinking is that if they can move an object halfway out of their land before it automatically rubber bands back because the center is not on their land anymore that means it is okay and allowed...

    I meet a lot of people that assume that if the software / service allows them to do something and gives no warnings then it must be okay to do it with impunity and no other user can tell them otherwise.  I have been threatened by several that they would abuse report me for returning their objects that encroached upon my land.  I don't let such threats stop me.  If the encroaching object(s) bothers me in some significant way I will return it.  If I get severe negative feedback from that object's owner, then I return any additional encroaching objects of theirs that I can, even if those objects were not bothering be before their owner shot off their mouth.

    Would be helpful if the viewer could warn people that something they are positioning is encroaching on a property line.  Then, maybe, a smaller number of people would be arrogantly ignorant.

    • Like 5
×
×
  • Create New...