There was no Main channel deployment or rolling restart on Tuesday May 13th, and neither the BlueSteel or the LeTigre RC channels will receive an update or should undergo a restart on Wednesday May 14th.
The Magnum RC should receive a new sever maintenance project on Wednesday May 14th, which includes a bug fix for a networking-related issue that sometimes affects busy sims.
SL Viewer Updates
The SL Maintenance viewer was updated on Monday May 12th to version 3.7.8.289922. This viewer includes multiple fixes to Mac viewer; fixes in Recent tab, Chat, LSL editor, land management, etc; GPU table updates; crash fixes & performance improvements.
LSL Functions for Materials
The subject of scripted control for materials was once again raised at the Simulator User Group meeting on Tuesday May 13th. Commenting on the matter, Simon Linden said:
I am looking at it but not promising anything. We’re trying to be really careful to understand how the server and viewers will react when stressed with a lot of material churn. From what I can tell, fast-moving material-based animation will not work well … that’s likely to be throttled or blocked somehow. But supporting something like a hud or other control that could adjust the look of an object … where it’s done rarely … is definitely possible.
As noted the last time this subject was raised, there are concerns over how LSL control of materials might impact system performance, either deliberately (via rapid and multiple flipping of maps, hence Simon’s comment on throttling the speed at which changes could be made), or unintentionally, such as using them with objects which may already have a large performance impact (such as animated mesh tails).
During the meeting, there was discussion on options for animating normal and diffuse maps, remembering that they can already be animated in lockstep with their attendant texture (diffuse) map. During this discussion, Simon commented on some of the difficulties in animating materials independently of the texture map:
The materials LSL support would include changing the offset, repeat and rotation values for the two maps, just like for regular textures. The update problem hits if you look at the way materials have been optimised between the server and viewer and how updates are sent. Materials are referred to by a number ID … so you get updates that say “this face has material 1234” on it, the viewer, if it doesn’t know what 1234 is, has to ask the server.
Now, if you change the offset … you have a new material 34356, the viewer has to again find out what that is, but this time it already has the actual specular and normal maps, so no download there. And when you switch back to 1234, it has all the info and can draw it faster.
Summing-up the situation in general, Simon concluded, “I hope there will be something to play with eventually on the beta grid … we’ll probably want to experiment there and figure out what kind of limits are effective.”
The future of mesh garments / wearables created using the now SL-defunct mesh deformer was the subject of some discussion at the Open-source Contributions meeting on Wednesday 11th December. While the deformer was never officially adopted by the Lab for use within Second Life, it was available in various test and experimental viewers, and the code could also be included in self-compiled viewers if people knew how.
Fitted mesh is coming….what of the future for garments made for / via the deformer?
This means that there are garments within Second Life that were created and uploaded for / with the deformer code, and which can resize with viewers using that code. However, as is the case with Fitted Mesh, the clothing would not deform when using a viewer without the requisite code. The same will be true once the Fitted Mesh updates reach a release candidate status and start to be more widely adopted: while Fitted Mesh (and Liquid Mesh) garments, etc. will deform to an avatar’s shape, items created using the mesh deformer will not; they will continue to behave like any other rigged mesh item.
This likely means that as the Fitted Mesh code does become more widely adopted, people will stop using any garments / attachables created using the deformer code, and the availability of such items in SL and on the SL marketplace will decline over time.
Whether or not this means deformer-based items will vanish from people’s inventories is something only time will tell. From the Lab’s perspective, the work involved in trying to pro-actively determine a method of identifying assets using the deformer code and removing them from the asset servers / inventories isn’t likely to be worth the end result. Therefore anyone with “old” mesh deformer garments and attachables will probably retain them until they opt to delete them from their inventory.
It appears unlikely that viewers using the deformer code will be pro-actively blocked from SL. What is likely to happen is that the code simply will not be formally adopted by those variants of TPVs which do not connect to any other grid than Second Life. However, this does leave a further interesting question as to the future of the mesh deformer, which has potentially seen far wider use in OpenSim communities than Second Life. While it would seem likely OpenSim will adopt the viewer-side changes required to enable Fitted Mesh (at least in the majority of cases), at this point in time, it is not clear whether the mesh deformer will be entirely abandoned. Whether there will be sufficient pressure within OpenSim for the deformer code to remain in use, and whether TPVs will feel obliged to incorporate the deformer into their viewers / OpenSim variants of their viewers as a result, remains to be seen. Currently, the only grid which has any kind of significant investment in the deformer is InWorldz, which provided funds for the code to be further enhanced and adopted it into their dedicated viewer in July 2013.
Materials and Numbers
Statistics are always a hard thing to determine. Back in the day, there was much controversy over figures released as to the adoption of mesh within SL following its deployment. The figures offered-up by the Lab at the time were vague enough that they could be taken to mean that mesh was either being rapidly adopted, or was seeing very slow growth (with the reality lying somewhere in between). This was not an attempt by the Lab to fudge issues at the time; it simply underlined the fact that numbers aren’t always the best means of trying to quantify something, so it’s perhaps better to allow the passage of time to speak for itself.
The most recent figures for materials suggest that over half of the regions in SL now have at least one materials-enabled item within them, and around 10% of avatars apparently utilise at least one materials-enabled item. Again, these are figures that are likely to be interpreted either way, depending on how people look upon materials as a whole. Certainly, the term “object” is sufficiently vague so as to be pretty worthless as am objective yardstick, as it likely covers everything from an individual prim through to entire linksets, which leads to a huge variance in the visibility of objects using materials. On a personal note, I can only say I’ve made extensive use of materials in my house, and am more than pleased with the results.
I’ve used materials on my house; particularly on the stonework and stucco textures to provide added depth. Materials on the whole appears to be slowly gaining momentum
Upcoming Code Contributions
There are a number of third-party code contributions in development for the SL viewer, some of which I’ve previously reported upon, and which are now progressing towards a point where they may well have public visibility through the likes of a release candidate in the new year.
STORM-1981 and STORM-1831
STORM-1981, contributed by Jonathan Yap, is intended to change the behaviour of tracking beacons to help make locating items in a region somewhat easier (e.g. locating lost items or scripted objects which are causing issues, etc.). Under these changes:
Beacons would begin at a height of 0 metres and extend up to the maximum unassisted flight ceiling (5,020 metres)
The beacon colour will be blue from 0 metres to the base height of the object being tracked, and red from 5,020 metres down to the height of the object being tracked
Users can optionally set the beacon to pulse towards the target object using the CheesyBeacon debug setting (Advanced->Highlighting). The blue beacon will pulse up towards the object, the red beacon will pulse down towards the object.
Tracking beacons will be changing under STORM-1981, making it easier to locate objects, etc.
STORM-1831 covers the work being undertaken by Ima Mechanic, with assistance from Oz Linden, to improve syntax highlighting in the viewer’s LSL editor by allowing the viewer to obtain the information required for syntax highlighting directly from the simulator the viewer is connected to. This should eliminate issues with the current manually updated files used to manage syntax highlighting falling out-of-synch with new LSL syntax as new functions and parameters, etc., are added. Folded-in to this work should also be a change to the source code text allowance in the viewer’s LSL editor, increasing it from the current 65,000 characters to around 256,000.
The server-side cap updates required for both STORM-68 and STORM-1831 have been combined and passed into the simulator release stream, and while it is unclear as to when the cap updates will reach a server-side release candidate package, their progress is being tracked. Obviously, both STORM-1981 and STORM-1831 require viewer-side updates as well, and these will hopefully appear in viewer release candidate form once the server-side updates are sufficiently deployed.
STORM-68
A number of TPVs include the ability to specify the default permissions applied to a new prim object (cube, cylinder, torus, etc.) on creation. STORM-68 aims to add a similar capability to the LL viewer (and which will quite possibly supersede the capability in TPVs once implemented). This work is again coming from Jonathan Yap, although it requires server-side updates, which Andrew Linden has been taking care of. However, this work has hit some problems in viewer / server interactions, which may be down to timing issues between requests and acknowledgements being sent between the viewer and the simulator and vice-versa. As such, further testing is required, so it’s possible this work might take a little longer to appear in the new year.
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.
The “grey box attachment issue” (image courtesy of Jen Cuddihy via the SL forums)
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.
Quick ways to improve performance when running in ALM to see materials. Top left: you can uncheck Ambient Occlusion, keep Shadows set to None and drop water reflections to Minimal. Bottom Left: Using Debug Settings from the Advanced Menu, set RenderLocalLights to FALSE. Right: Firestorm / Phototools, ambient occlusion, shadows, local lights and facelights can all be disabled from the Light tab and water reflections lowered from the WL tab
Update, July 31st: further to the note below relating to the BlueSteel RC deployment, it appears the bug fix did not clear QA in time for the deployment to occur. Maestro Linden has updated the deployment thread to read: “BlueSteel’s planned project hit some last minute issues, so the update has been canceled for this week. Instead, BlueSteel will not be rolled this week (it will match the version on the ‘Second Life Server’ channel).“
Server Deployments Week 31 (Week Commencing Monday July 29th)
As always, please refer to the week’s forum deployment thread for news, updates and feedback.
Second Life Server (SLS Main) Channel
On Tuesday July 30th, the SLS Main channel received the server maintenance package previously deployed to BlueSteel in week 30 and LeTigre in week 29. This project includes:
A further fix for the issue of pathfinding characters using CHARACTER_STAY_WITHIN_PARCEL getting stuck if they somehow exited their home parcel
Fixes for objects failing to detect collisions after teleporting (BUG-969) and run time permissions failing to function correctly on attachments (BUG-2931)
New capabilities to the materials system to better handle texture requests.
Release Candidate Channels – Wednesday July 31st
Magnum and LeTigre will remain SSA enabled and both receive the updates deployed to the Main channel.
BlueSteel should receive a new server maintenance project. However, a last-minute bug was found in the code. While this has been fixed by Kelly Linden, it has still to pass LL’s QA at the time of writing. Assuming the package passes QA and is deployed, it will include:
Fixes for some simulator crash modes
A fix for BUG-3291 (“llListen in linked objects is listening at root instead of linked object local position *after re-rezzing the linkset*.”)
A fix for BUG-3307 “(llApplyImpulse called from attachment does not work on avatar if script is reset or started when attached”).
Doyouthinkhesaurus – Baker Linden (far right), in his new avatar look, literally towers over the start of the Simulator UG meeting on Tuesday July 30th.
Server-side Appearance
As noted above and in part 2 of last week’s report, SSA will not be enabled on any additional server channels this week, but does remain enabled on LeTigre and Magnum as the Lab continue to gather statistics and monitor performance, etc. Commenting on the state-of play, Nyx Linden said, “Testing seems to be going well, but we’re being on the cautious side – making sure that the back-end can handle the load. There are a few reported bugs in JIRA, but *most* are minor and we’re working on the not-so-minor ones.”
Issues
I provided an update on some of the more serious issues the Lab has been addressing with SSA in part 2 of my week 30 report (see the link in the paragraph above). Since then I’ve been poked about additional advice the Firestorm team have put together for those experiencing issues, including SUN-98,and I’m providing the relevant information here.
Avatar textures remaining grey / SUN-98: is generally the result of wearing a corrupted clothing asset, and as such is “expected behaviour” in order to avoid cases of accidental nudity, as I explained last week. To help diagnose the problem, the Firestorm team suggest you:
Remove all clothing and allow the avatar to bake with just the skin layer worn. If it fails to bake properly, the skin is the corrupted asset and needs to be replaced
If the skin bakes correctly, start adding the clothing layers of the outfit one at a time and check each to see how it bakes
If an item shows-up fully or partially grey, that is the corrupted asset. Replacing it should allow everything to bake and render correctly.
The Firestorm article also includes some Firestorm-specific actions for problems, and is a work-in-progress, so you can refer to it via the link above for further advice.
Apologies for the late-running of this update. I started drafting it earlier in the week and, um, forgot about it.
Week 27 Server Deployments
Just a reminder that due to the Independence Day code freeze for week 27, and the fact that the Lab is closed on Thursday 4th, Friday 5th July for a long weekend, there were no server deployments this week.
Server-side Baking / Appearance
Deployment / enabling should be commencing in week 28, most likely starting on the 9th July. To help spread the message, the Lab has once again blogged on the deployment of the new service, referring to it by the official title of Project Sunshine (which is a part of the Shining Project) and again included their video explaining what is going to be happening.
The majority of maintained viewers provided by both Linden Lab and third-party viewer developers are already ready for the new service, with only Dolphin, Exodus and Imprudence being without support. Hopefully, both Dolphin and Exodus will update shortly, but it will be some time before Imprudence is in a position to adopt SSB/A – the team has a fair amount of catching-up to do.
So, to borrow from the Lab. If you’re not already running an SSB/A capability viewer: “Don’t be cloudy and grey – enjoy Sunshine today” – and update your viewer!
SL Viewer News
A further SL beta viewer release was made on Tuesday July 2nd – version 3.6.2.278133 – with (among other things) further materials fixes, as listed in the release notes.
In other updates:
The Lab has made a viewer repo public which contains various bug fixes and updates made available in the beta maintenance viewer. These include items such as the additional fixes for high-resolution snapshots (to prevent things like black rectangles appearing in very high resolution images). Expect to see them filtering through into TPV soon, and for the fixes themselves to start the SL release viewer possibly sooner.
The “project interesting” viewer which contains viewer-side updates to complement various server-side interest list project updates is still undergoing work to fix all the blocker bugs which are currently preventing it from being made public.
In terms of the latter, Andrew Linden reports that he is looking to gather data which will allow for performance comparisons with things like scene loading pre- and post “project interesting”, to see help measure the improvements in the HTTP texture download changes implemented by Monty Linden.
Other Items
What is a Reasonable FPS Rate?
In the last part of my week 26 update, I reported that the Lab has statistics which show that around 50% of users are running viewers with the Advanced Lighting Model option (“ALM” – formerly the Lighting and Shadows option and also referred to as “deferred rendering”) active, and that they further had data to suggest that up to 75% of users have hardware capable of running with ALM enabled “with reasonable performance” in terms of frame rates (e.g. an average somewhat above 10 fps).
At the time I reported this, I noted that:
However, given that fps is a highly subjective measure and somewhat dependent on a range of external factors (such as how many other avatars are in the region with you, whether you are moving around a lot or not, etc), the “YMMV” rule comes into play.
That the term “reasonable performance” is so nebulous sparked a debate during the Simulator User Group meeting as to what might be regarded as “reasonable” frame rates for a viewer running with ALM enabled (although not necessarily with any lighting & shadows options set). The broad consensus of opinion was that a rate of around 20-30 fps would be considered “reasonable”.
Part of the concern here is that while ALM is required in order to be able to render materials effects, LL might be overly optimistic in determining which cards have ALM enabled by default, which may in turn have an additional impact on new user retention due to people logging-in to SL and experiencing extremely low frame rates and not having any understanding on how to improve their experience.
As reported in part 2 of this update, the release viewer was updated on June 27th with a release containing a number of updates and fixes, including some for materials, such as occlusion culling is less effective than it should be, especially with regards to very large objects; light function sampling being incorrect in advanced lighting model and the legacy Shiny options being overly strong in deferred rendering. The initial fixes for these issues are considered important for TPVs to pick-up when integrating materials into their viewers, while follow-up releases (such as the new 3.6.1277824 beta viewer released on June 25th, being viewed as slightly less important at this time.
Materials continues to be updated and refined, and the Lab is gathering stats on viewer use with ALM enabled
The latest stats the Lab has on viewers show that some 30% of users are currently running with the Advanced Lighting Model option (ALM – otherwise known as deferred rendering), and are thus able to see materials in use in-world, although the stats also appear to indicate that up to 75% of the user base have hardware capable of running with ALM enabled, “with reasonable performance” in terms of frame rates (e.g. an average somewhat above 10 fps). However, given that fps is a highly subjective measure and somewhat dependent on a range of external factors (such as how many other avatars are in the region with you, whether you are moving around a lot or not, etc), the “YMMV” rule comes into play.
The Lab has already carried out a fair amount of performance tuning with ALM, and at the TPV Developer meeting on Friday June 28th, Oz Linden reported that further work is going on in this area, which will include some profiling of the shaders in order to try to further improve performance.
The expectation is now that the new viewer release process will come into effect during week 28 (week commencing Monday 8th July). The process is actually ready to go, but as with the server-side of things, the 4th July no change window means that the process cannot be implemented in week 27.
Vivox Update
Once the new process is running, the Vivox update is likely to be one of the first items to go to a viewer release candidate. This update should greatly improve Voice quality within SL. A further Vivox update is liable to follow this at some point.
Interest List Improvements
The viewer-side interest list updates are coming, although the viewer repro has yet to be made public, although again it is anticipated that a project or beta viewer with the updates will be made available after the holiday period, and TPVs will be able to obtain the code.
Viewer Settings
The Lab is moving to eliminate the use of viewer settings files based on channel name. This means that in future, a single SETTINGS.XML file will be used for all versions of an SL viewer which is installed. The code for this is moving towards the release channel of the SL viewer, and the hope is that it will prevent issues of confusion when settings appear to be “wiped out” when using multiple versions of the viewer (e.g. such as moving between the SL release viewer and the SL development viewer and back a few months ago resulted in people’s toolbar buttons “vanishing” from the release viewer).
Inara Pey: Living in a Modemworld 