Jump to content

Andrew Linden

Retired Linden
  • Content Count

    29
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Andrew Linden

  • Rank
    Member
  1. Nalates is correct. The way I would put is this: The viewer measured ping time includes the time it takes for the viewer to get around to processing the network packets. Although a packet may have already arrived at the ethernet port and is sitting in the queue, its "arrival time" is measured when it is actually processed, which is done in the same thread as the render work.
  2. I just finished coding up a fix for this bug, and it should work for all ghosted region boundary objects. It will have to get tested and bundled into a server update so the earliest it could hit RC would be around 2013.10.09.
  3. I have a fix for this but it didn't make it in time for this week's update (for unrelated technical problems). It is currently deployed to the DRTSIM-208 channel on the beta grid (aditi) which includes the region "Gibson" if anyone wants to check it out. Antony Fairport, who first reported this problem in a jira issue, has tested it and has verified that it works.
  4. This is the first I've heard of an "invisible avatar" problem. We'll be needing some details to investigate, such as the region name, time of event, would couldn't see who and where they were standing when it happened. Ideally this info would be put into a jira issue where the investigation could be tracked (rather than putting it in this thread). BTW, it occurs to me that there is a feature where a parcel owner can specify that people outside the parcel cannot see people inside, and visa-versa. I wonder if one of the parcels in the club is misconfigured with this option. BTW, one way to
  5. Turns out my theoretical fix did not work, but I did get some clues today that I hope will help me figure it out.
  6. Yes, the problem only affects people with certain internet connections. In particular connections that suffer UDP packet loss at relatively low bandwidth settings. Doing a normal HTTP download speed test on such a connection may indicate a higher bandwidth than is supported for UDP traffic -- TCP traffic may be treated differently than UDP. The workaround is to lower you SL viewer bandwidth settings in the preferences. The one resident who tried this was able to make the scripts load at 350kbps or lower. This will not necessarily degrade your SL experience as much as you might expect. Th
  7. Yes Ciaran, that sounds like the same thing. To really see it in action you would crank your viewer bandwidth settings down to a few hundred kbps, then turn away from a big crowd of Dwarfins, wait several seconds for the Dwarfins to move around, then turn around very quickly so they are all in view. The low bandwidth settings will cause a significant amount of time to pass before all of the linked pieces to get updated correctly.
  8. I logged into to Ruiz/159/80/1502 as per the instructions in BUG-1779 and finally noticed what you're Levio is talking about. For me it was rather hard to see becuase most of the meeroos would snap together pretty fast, but I dropped my viewer bandwidth settings down to 300kbps (from 1Mbps) and could reproduce it much easier. Each visible part of a meeroo is a child-prim. The root is an invisible prim that typically doesn't actually move when the meeroo sits down or stands up -- each child prim moves to a new local transform to produce the effect of motion to a new stance. The problem is t
  9. @Pierre - No, reducing your cache size will not help. That setting just controls how much hard drive space you are willing to devote to the cache, and in this context includes both the texture cache and the object cache which are stored in separate formats and different locations. It doesn't control how big each per-region object cache file will be, just how big of a filing cabinet you have for those files. A workaround was mentioned earlier in this thread. Something about "flipping alpha masks and atmospheric shaders settings". If that works then it seems like the best workaround that I
  10. "But why is the client suddenly having a problem it didn't have two months ago? " What has changed is that the server is now treating much more content as "cacheable". The server's definition of cacheable used to be something like: "is static and does not have a script". The new definition of cacheable is: "has not changed position or appearance in the last couple minutes". The viewer bug must exist inside the code that retrieves object data from cache and is more noticeable now because the viewer-side object cache tends to be bigger. I've brought the problem to the attention of one of t
  11. I can explain why the avatar bounces when you raise the terrain under its feet: The terrain info is stored in two formats: (1) a 2D array of floating point heights (a "heightfield") that is used for visualization and (2) a big list of triangles (a "mesh") which is used fo collision purposes. Whenever you modify the terrain you are actually changing the heightfield data (1), which then must be translated into mesh form (2) before you avatar can collide with it. The conversion to mesh is computationally expensive and can take a significant amount of time to complete. To reduce lag caused by
  12. The problem was caused by the new interestlist code which tries to not subscribe to objects that are outside of the camera view. When crossing a region boundary your viewer would extrapolate your camera forward, the vehicle would be created behind the camera, and the server would not subscribe to it. The faster the vehicle the more likely this would happen. The solution was to special case interestlist subscription to whatever you're sitting on -- the server now ALWAYS subscribes to your seat. We already had some special case code for seats, but it needed a little more.
  13. Janet, you mention that your cache is maxed, which sounds like you're talking about the cache on your local filesystem (hard drive), which can be configured to be large or small. I was talking about storage in memory (RAM). The viewer will take a lot of RAM, but there are limits to what it can get -- the rest of your operating system and other applications also need RAM to function. Also, there is special RAM in your graphics card which is also limited. If you are in a texture-heavy region (many large unique textures) then it may be that the viewer cannot hold all those visible AND those b
  14. After looking through the SL UDP packet code a bit more I have a little better understanding of how it works than last time I spoke about it. I learned that when we actually pack data for a UDP packet we limit the payload to 1200 bytes. We're aiming for a max of 1500 bytes for the entire packet, counting UDP header and some ACK information that we add to the end of the normal 1200 byte payload, so we leave 300 bytes for that stuff. Once the final payload is computed (including the initial data and postpended ACKs, but not including the UDP protocol header) we check the size and print a WARN
  15. Janet, what you're describing sounds like a behavior of the viewer. It is probably performing a lazy scan for textures that are not being rendered in view and slowly unloading those from memory -- in an effort to prepare the memory for any new textures that might show up, and to help keep your render frame rate high. This is definitely not related to the server delaying updates for objects behind you since these objects are not chaning and thus would not be getting updates anyway.
×
×
  • Create New...