SL projects update week 27: SSB/A, general news and discussions

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.

How the Lab measures what they consider to be “reasonable” is unclear – although it would seem more likely that they base enabling ALM by default on the OpenGL version a GPU card supports, rather than on and in-world performance testing. As such, this may well lead to the “enabled” list of cards being a little too liberal in its spread.

However, how and where LL might otherwise draw the line is hard to determine, simply because everything around viewer performance is so subjective and dependent upon everything from the overall hardware someone is using through to the complexity of the region where any measures are baselined, the number (and complexity) of avatars within it at any given time. As such, it would appear unlikely that the Lab will change any of the assigned defaults, although concerns on the matter have been carried back to the office from the Simulator UG meeting.

Land Impact Concerns

As indicated in a number of my Materials Processing project updates, use of materials capabilities in objects moves them into the “new”, or “mesh”, accounting system. As has been particularly noted in these pages, this can have some alarming results when using materials in conjunction with complex / tortured prims (and with sculpts).

Qie Niangao was one of the first to highlight potential issues when carrying out experiments using Alpha Masking and Emissive Mask options, when he noted objects experiencing sizeable increases in their LI.

Using the Alpha Masking and Emissive Mask Alpha Mode options with tortured prims (in this case a hollow sphere) into the “new” LI accounting system

Qie raised his concerns in JIRA MATBUG-13, together with concerns that the application of materials to existing in-world objects could result in the unexpected return of objects as a result of LI increases exceeding the local parcel / region capacity limits. Subsequent to this, MATBUG-217 was raised highlighting this latter point.

It is possible to overcome some issues with LI by adjusting the physics associated with an object or linkset. However, this is not a guaranteed workaround for all cases, and the effectiveness may be further limited by the application of materials.

Concerns have been raised that because of this, new users will be put off learning about building in-world and using the tools available within SL to start into content creation. Whether this is true or not remains to be seen, and it is unlikely the Lab shift its position on materials falling into the new accounting system.

To better educate users on content creation, there have been calls at the Content Creation User Group for the Lab to do more to promote things like the Good Building Practices wiki and the Content Creator’s Guide, in order to better put information in front of content creators new and old and to try to encourage much more efficient building practices across SL as a whole, prim or otherwise.

Large Textures

Alongside questions of performance with ALM enabled and concerns over the LI accounting system, the subject of people using very large textures  was once again raised.  while there are times when a 1024×1024 (or a 1024×512) texture is required, there is a tendency to use large textures for absolutely everything. Using very high resolution images may appear to make things look really good, but they also require large amounts of memory. Using lots of high-resolution textures, especially where they are not needed, can therefore overwhelm people’s video cards and cause them problems.

A graphic posted to the forums demonstrates this problem, and underlines why considered use of textures can help everyone. As such, requests have been made to again better educate users in the more rational use of larger texture sizes.

Related Links

• SL Good Building Practices wiki
• SL Content Creator’s Guide
• Materials FAQ