Upate April 10th: The BlueSteel / LeTigre package did not deploy as planned due to problems getting the updates completed in time. The Magnum package therefore deployed to all three RC channels.
Server Deployments Week 15
Second Life Server (Main) Channel
There was no planned deployment to the Main channel on Tuesday April 9th. The next scheduled deployment will be in week 16 (week commencing Monday April 15th). This was because there were bugs found in both of the RC releases from week 14 which the Lab wanted to resolve rather than having them propagate across the grid.
Release Candidate Channels
All three Release Candidate channels remain on the same releases as week 14, the only updates to be deployed on Wednesday April 10th being:
- BlueSteel and LeTigre (currently running the new server-side AO capabilities) – should receive a design change to improve compatibility between the new animation override system and other scripted objects that animate avatars (such as poseballs). This may be in response to a JIRA – BUG-2164 – being raised in relation to conflicts between the new AO capabilities and poseball systems
- Magnum (currently running Monty Linden’s HTTP updates) – should receive a fix to correct a crash mode.
As always, there is a forum discussion thread for the week’s deployments.
SL Viewer Updates
CHUI – Communications Hub User Interface – Flickering Issue
The CHUI merge with the SL release viewer has brought with it an increase in the ATI/AMD issue of clickable links in the viewer’s UI flickering when anti-aliasing is enabled (BUG-1560, relating specifically to cards running the 12.10 (or later) Catalyst). This tends to happen with links in the chat window, but may also affect the selection box surrounding items in the inventory floater.
Those encountering the problem should consider raising a bug report.
Materials Processing – Land Impact
The most notable update to the SL viewer has been the release of a project viewer for materials processing. The viewer is available on the SL wiki Alternate Viewer page, and the code is available on Bitbucket. However, due to the work still going into the project, both come with caveats:
- It is still very fragile
- It is still subject to change in various ways
- It should not be used on content you care about – particularly if said content is MODIFY / NO COPY
- It is not recommended that TPVs integrate the code into their release viewer at the moment due to the fact the code will be changing (and there is not SSB merge as yet).
The release of the viewer has also brought with it something of a concern.
Qie Niangao has been carrying out further tests with the Materials Processing project viewer, and has come up with evidence that aspects of the material system can result in objects experiencing sudden (and potentially large) Land Impact value changes. Specifically use of the Alpha Masking and Emissive Mask options when working with alphas can have unexpected results – which is not to say that the result are not unexpected behaviour from LL’s perspective.
Qie describes his discovery in MATBUG-13, is which he offers the following exercise:
- Create a sphere. Hollow it 95%. Add a simple rotation script.
- Set the Alpha Mode to Alpha masking. Note that the land impact is now 43. “More info” shows the extra weight attributed to Physics.
Qie goes on to note that cutting or squashing such an object can have an even more dramatic impact (path cutting the sphere in half, for example, can push LI to 1348, while squashing it almost flat can lead to an LI of 154).
Commenting on the JIRA, Maestro Linden notes:
This is expected behavior. When a material is added to an object, it is enrolled in new prim accounting. A 50cm, 95% hollow sphere has 43.5 physics cost when using a ‘prim’ physics representation. This high cost is caused by the high complexity physics shape. See https://wiki.secondlife.com/wiki/Physics_Optimization for a guide about how to reduce physics cost.
It is interesting to note, however that the same prim using Alpha Blending retains the same physic cost, but only generates a LI of 1. As Alpha Blending is essentially the way alpha layers are currently handled by the system at the moment, Qie’s theory – which I agree with – is that the existing system as been somehow “grandfathered-in” to the LI accounting system.
Concerns have already been raised over the possible repercussions of this change if people are not made fully aware of it. One is that it could results in the unexpected return of objects and sections of builds if alpha masks are employed on existing structures and push up LI values. Another worry is that the situation could be exploited by griefers as a means of “filling” available Land Capacity in areas open to public rezzing.
For builders, a way of offsetting the impact is to perhaps convert linksets to convex hull – although this may not work in all cases; another is, as Maestro suggests, to follow the physics optimisation guide.
Even so, the situation suggests that some effort is required in further limiting land impact. This may, in part, be what the alpha release of the project viewer is about – so that LL can gather data and determine what (if anything) needs to be done. As a result of discussions at the Simulator User Group meeting, Andrew Linden made a note to investigate the possibility of low LI for static phantom content (phantom prims currently incur a physics cost as they are not entirely “collision free” where the physics engine is concerned – while it is possible for an avatar to move through them, they still “collide” with the ground, and thus incur a cost).
In the meantime – work with care when using materials and alpha mask options.
As I reported in my week 14 updates, there has been a marked increase in the issue of prims in linksets failing to render correctly, leading to “missing prims” within in-world builds, etc. until they are right-clicked upon, since the last deployment of server-side interest list updates.
Collaboration between the Lab and users largely confirmed this to be a viewer-side problem which may have been exacerbated by the most recent server-side interest list code updates. Speaking at the Simulator User Group meeting on Tuesday April 9th, Andrew Linden stated his belief is that the problem was made worse by the changes made on the server-side to what constitute “cacheable data” within the viewer – so that the viewer and server as effectively out-of step with one another.
“It used to be that the server’s definition of what was cacheable was “anything that is static and does not have a script,” he said at the meeting. “That definition was expanded in the interest list code that was promoted last week to be: ‘anything that hasn’t changed appearance or position in the last couple of minutes’.”
However, he went on to indicate that this is still only a theory at present, and that he’s continuing to investigate matters and will be updating again at the next meeting.
With thanks to Qie Nianagao