Second Life: Third Party Viewer UG 2016 w38

ACI & LI

Vir Linden is digging into ACI and LI as a few issues have accumulated over time. Some are believed fixable and they are looking at those as well as the overall cost calculations.

Butterfly Solo

Butterfly Solo

There are reported cases of unexpected or misbehavior of cost calculations. The Lindens are collecting those cases and plan to have a wide range of cases they can test and analyze to see where and why things go wonky.

They also plan to take that wide range of items and measure their cost across a wide range of machines. This will be a deep dive into the cost calculations. The effort is to see if things need to change in how costs are calculated. The Lindens are making NO guarantee anything will change but, Oz says it is a real possibility they will.

Exactly what the viewer is doing with ACI (Avatar Complexity Information) is fuzzy. Oz explained the state of ACI as it is now and as it is planned to eventually be.

The SL Viewer reports what it thinks the avatar Render Cost is to the SIM. The SIM averages and filters the reports for each avatar. Out of bounds data is filtered out. The remaining reports are averaged for each avatar and the result reported to all in region.

The purpose of the idea is to eventually avoid downloading everything related to an avatar that will never be rendered. As it is now, the part that avoids the downloading is not in place. But, the Lab is using the data to learn what people are doing with their avatars.

Trust is an issue in this system. A griefer could make a viewer and misreports data to throw the server off in regard to a targeted avatar and have it report bad information to other users. The result being people would not render someone regardless of their ‘real’ ACI. Which is why the system discards what it thinks is unrealistic data and averages together reports from numerous people in the region.

As it is now the viewer decides, based exclusivity on its own calculation of the avatar’s ACI, on whether to render it as a JellyDoll or not. So while the average ACI reporting is in place server side, it is not used by the viewer. As the Lindens become more confident in how things are working and know more about what people are doing with avatars they will move along their plan. The result will be less load on the viewer as the server reports the averaged ACI way ahead of when the viewer needs to render an avatar. The viewer will then be able to avoid downloading what it isn’t going to use.

As it is now viewer calculates the ACI for each avatar and reports whether it is rendered or not rendered. The SIM counts how many are not rendering an avatar and how many are in the region. It reports that information to the viewer. They see how many aren’t rendering their avatar. This happens every minute.

There is a bit of lag when an avatar leaves a region. The server does not immediately clear ACI reports when someone leaves. Server time stamps all ACI reports. It does age out the reports quickly. But, are not in perfect sync with an avatar leaving. So, how many people are actually rendering you in a busy region with lots of coming and going is a bit fuzzy.

When you change your outfit that causes a series of notices to be sent but, how many can see/render you is delayed by 90 secs. The system is waiting for those around to report in and update the server on the cost of your new appearance. After that you are told how many are/aren’t rendering you.

A problem we have now is people get various ACI numbers for same avatar. It can vary and ± 2k seems to be normal. However, the Lab is hoping to get all viewers, including third party, reporting the same value… or near same value. Different hardware apparently influences the calculation.

We are noticing that a single viewer may report the ACI of its avatar at different values at different times, often after a teleport. That’s not right.

As it is now your viewer decides to render based only on your calculation of ACI. Your calculation doesn’t have much affect others perception of cost on whether to render a specific avatar or not. But, the plan when fully implemented would be more influenced by calculation from various viewers.

So, different ACI values for the same avatar from different users and for the same avatar showing large differences, <=5k, are of interest to the Lindens. They would like to track down the reason. If you see them report them, JIRA.

Whirly of course has an instance of just such a case. See: BUG-37642ACI randomly changes (often at login or following a TP). It isn’t hard to reproduce the problem once you find an outfit affected by it. Find the outfit is tedious. Most people notice it with a particular outfit they have. Then it is easy to reproduce.

This affects how others see you too. So, you may have an ACI of 40k and others see you with an ACI of 80k. The error could cause some avatars not to render you and you’ll see a high number of avatars ‘not rendering you’ for no apparent reason, assuming you have a low ACI.

The variation in ACI for BUG-37642 is often huge, 2x or more. If you run into this please report your information in the JIRA.

Oz mentions the ACI calculation does have a distance factor due to LoD. But, the Lindens are considering whether that is something to keep. I notice I can see some avatars render OK and as I get closer they go over my limit (350k on the new machine) and turn to jelly.

The basic take-away here is that more tweaking is coming to ACI and LI.

Leave a Reply

Your email address will not be published. Required fields are marked *