Server Deployments Week 33
As always, please refer to the week’s forum deployment thread for news, updates and feedback.
Second Life Server (SLS Main) Channel – Tuesday August 13th
There was no update to the Main channel. It had been anticipated that the package deployed to BlueSteel in week 32 would reach the Main channel this week, but this is not the case, for the reason given below (see the Grey Box Attachment issue notes, below),
Release Candidate Channels – Wednesday August 14th
- Magnum remains with SSA enabled, but otherwise received no further updates.
- LeTigre should receive a new maintenance package which “only includes a few internal bug fixes which shouldn’t show any visible changes to the residents”. In describing this at the Simulator User Group meeting on Tuesday August 13th, Simon Linden said, “There’s one performance fix that you might see in the viewer … you shouldn’t get those situations where you see lots of ‘duplicate caps. messages”
- Bluesteel should receive a new server maintenance package comprising:
- A fix for the “grey box attachment issue” (non-public BUG-3547, details below)
- A (further?) update to for “llListen in linked objects is listening at root instead of linked object local position *after re-rezzing the linkset*”, which was also listed in the BlueSteel release notes for week 32 (non-public JIRA BUG-3291)
- The code to block avatars entering a region / objects being rezzed in a region during the last 60-seconds before a restart. In addition, restart warning pop-ups will include the region name. This was again in the release notes for week 32, so would appear to be a further update to that code
- Fixes for further simulator crash modes.
“Grey Box” Attachment Issue
This is a problem whereby a grey prim appears around any passenger(s) sitting on a boat / vehicle when crossing from a BlueSteel region to any other region (including another BlueSteel region) – the driver / pilot is left unchanged. The affected avatar has no control and requires a relog, while the prim itself appears to be linked to vehicle when edited.
It is thought the bug was introduced during the week 32 BlueSteel deployment, and Simon Linden indicated it was the reason there was no Main channel deployment for week 33, saying:
We didn’t update the main channel today. There was a bug found involving vehicles and region crossings that needed to be fixed, so that update will go out tomorrow [the BlueSteel RC deployment]. Basically, don’t sit more than 1 person on a vehicle when leaving a BlueSteel region, otherwise it turns you into a box :P. It happens to the 2nd (and probably more, if you had a crowd) person seated on the object.
Kelly Linden explained what was happening to cause this:
Every agent has a ‘task’ representation on the server that is the same as a prim. The bug is in sending the linked set w/ avatars to the other region: avatars after the first are losing the special avatar treatment and getting passed as a regular linked prim. So that prim is what the server thinks all avatars look like.
Simon added:
The region crossing code basically un-sits avatars from an object, sends both the avatars and object to the next region [as separate sets of data], which puts them back together. In this case, the 2nd avatar doesn’t get detached properly and things go south from there. So the 2nd avatar gets sent over bundled up with the object … which it’s not designed to do.
The additional avatars on the vehicle at the time of the region crossing essentially end-up in limbo, with data caught between the two simulators. “The regions are very confused about that avatar data by that point, I’m sure a relog would be needed,” Simon said.
An interesting side-effect of this is that the bug makes it possible to exceed the 256-prim linkset limit – sort-of. Enterprising individuals have realised that if you rez a 256-prim linkset, sit a number of avatars on it and move it across a region boundary, it will acquire an additional prim for each additional passenger over the first avatar to sit on it. However, the ability is of limited value; make any changes to the enlarged linkset, such as unlinking a child prim or trying to texture one of the greyprims, and the entire thing turns no modify / no copy – and the fix being deployed to BlueSteel should correct the problem anyway.
Server-side Appearance
Just as a reminder. There are no further SSA deployments planned for week 33. This is to allow for some back-end updates to be made to the SSA servers. These updates shouldn’t result in any visible difference to users on SSA-enabled regions, and are intended to fix a couple of scenarios where the viewer would have to re-try requests when it shouldn’t have to. The Lab wants to get these updates deployed to the SSA server prior to making any move to rolling-out SSA to the entire grid.
There have been comments on the forums that SSA “must” be encountering major problems as the deployment has been so protracted. This is not the case. Linden Lab (via Nyx Linden) have always stated that the deployment would proceed very, very cautiously because it is such a fundamental change in how Second Life functions. Even though the Lab has indicated that very, very few problems have been encountered with enabling the service so far, and the load testing on both Magnum and LeTigre (representing a little over 20% of the grid) has been very positive, they are sticking to their softly, softly approach.
Viewer Updates
As the Vivox updates became the de facto release viewer in week 32, the remaining five release candidate viewers in the viewer release channel have been underground rebuilding using the updated release viewer code base. On Monday August 12th, updates for both the Cocoa Viewer for Mac (version 3.6.3.279554 – download and release notes) and the Maintenance Viewer (version 3.6.3.279564 – download and release notes) were released.
Materials Project
The Materials Project viewer was updated to version 3.6.3.279651 on August 8th. This release lists a large number of fixes, perhaps most notably those related to problems with the appearance of alpha textures under both local lights and sunlight, and numerous issues with mesh rendering and lighting within the materials viewer. Please refer to the full list of JIRA items in the release notes linked-to above.
ALM Concerns
Concerns have been raised about performance issues as a result of having the Advanced Lighting Model (ALM) enabled by default (as is now frequently the case for most graphics cards, as is a requirement in order to see materials in use in-world).
The amount by which ALM can affect the user experience is variable, and subject to a lot of influences, not just the graphics cards / computer system the viewer is running on. Some people with systems similar to my own (see the panel on the right for my system spec), have noted “significant” impact when running with ALM enabled on a materials-capable viewer.
Part of the problem is the “ALM” is a very broad term, and other options within the viewer can influence performance, but will not impact the ability to see materials even if they are turned off – such as having shadows set to None, for example, or having water reflections set to Minimal and turning off local lights (via debug or Phototools, for example). So part of the problem is that of communicating what can be done from within the viewer to help offset performance impacts should they occur, but which don’t limit their ability to see materials in use.
Inara Pey: Living in a Modemworld 
Sad that disabling local lights is a performance recommendation when keeping Materials enabled. Materials lose a lot of their point when when only the sun and moon are left as light sources for it.
The fact that ALM can be turned off period is bad for materials. Imagine if sculpties or mesh could be checked off, how many would bother? Most things Linden Lab allows to be checked off never seem to go anywhere, like Shared Media and I imagine now materials.
Hopefully I’m wrong though, but I wish there was a way materials was enabled for everyone, local lights enabled for everyone, and it didn’t cause any issues. But I guess if they create unbearable lag for some, there’s no way around it.
LikeLike
Well, something to try if you’re hitting severe issues, rather than a recommendation to keep them off. As with all things, it’s a matter of toggling items and options, and seeing what works, although Shadows (of which local lights are obviously a part) is the biggest GPU chewer.
The Lab is still working on refining things, with improvements coming out in the viewer (hence the project viewer update), so hopefully as things are tweaked further the need to fiddling around and lose options will become less a necessity, particularly for those on moderate systems.
The other aspect is that local lights can be drastically over-used in some builds largely because even though the number physically rendered is pegged at 6, a lot of builds use an awful lot of them as the viewer has tended to render them poorly (so they’re also pumped up to an intensity of 3). With materials, its can lead to a lot of wash-out where there is a concentration of local lights, so as materials comes into greater use, people will start thinning-out places where they do have a lot of lighting sources placed.
LikeLike
Local lights generally shouldn’t have much of a performance impact on the viewer when ALM is enabled unless you’re in areas where someone just started dropping as many light sources as they possibly could. ALM uses a technique known as deferred rendering that’s very efficient when it comes to rendering light. You can render literally thousands of light sources at a consistent framerate with no slow down. But at the same time, due to the poor state of lighting in SL people have to resort to adding more lights in an area as you’ve pointed out.
Oh how it’d be nice if light sources had better intensity ranges than 0..1.
LikeLike
Isn’t a part of the lighting problem the difference between the old system (8-lights maximum including Sun and Moon) and ALM. It’s not just number of lights. it’s in the detail of how the total brightness is calculated. IIRC, the old system set the level from the brightest source of light, while ALM sums the light sources.
When ALM started, some of the old facelights were a very obvious problem.
LikeLike
Brightness is not calculated any differently between ALM and non-ALM. They both share similar lighting calculations. The main difference is where the calculations are handled; i.e., per-vertex or per-pixel and per unique surface or a separate lighting phase that’s not dependent on how many surfaces populate the world.
There is of course the difference in number of lights that ALM and non-ALM supports. Non-ALM only supports a maximum of 8 lights, with 7 of those being selected based upon distance from the avatar and how big they are. ALM allows for a very large number of light sources, and is capable of rendering them much more efficiently than without ALM. So what does this mean about light brightness?
As it stands, light intensity is clamped to a range of 0 to 1. You can of course have values in between, such as 0.25, 0.123, 0.84, and so on. But what if you want a bright light? Say you wanted a light source that’s more in-line with the intensity ranges observed in real life lights?
In most conventional game engines, this has been solved by simply allowing light intensity to exceed a range of 0 to 1. Most game engine developers have decided that 0 to 8 is a fairly reasonable range for the vast majority of lighting environments. To achieve something similar to this in SL however, you have to stack multiple lights on top of each other at their fullest intensity. One thing I’ve seen a lot is content creators who don’t really take into consider ALM (either because they think it runs too slow or because not many people use it) will place as many lights as they can in one area to make it brighter. For per-vertex lighting, avatars tend to look fairly bright in these situations, while many environments tend to not look quite as bright due to the lack of vertices in the environment to receive light. For per-pixel lighting, everything in the effected area will be equally as bright, meaning that the environment will generally look just as intensely lit as avatars.
If the content creator just threw as many lights as their prim allotment allows in the area, thinking that it wouldn’t have any adverse effects for anyone, then the entire area will come across very bright for users with ALM due to the lack of the 7 local light limit.
The reason this happens is all light is additive. It doesn’t matter what rendering pipeline you use on SL. light A + light B + light C in ALM will still be the same as with non-ALM. They defining details here is how many lights each supports, and the difference between per-pixel and per-vertex lighting.
LikeLike
Thanks for the additional explanation, Geenz!
LikeLike
It seems like SSA was disabled on LeTigre with today’s rolls. I have been on two LeTigre Regions today noticing slowly loading blurry avatars.
Amazing how fast you get used to SSA benefits finding it normal that people are rezzed when you look at them… when you mainly stay in LeTigre Regions and then suddenly see the old behaviour coming back
LikeLike