SL project updates week 36/2: server releases, CDN news, projectors and materials

Kats, Love Kats (Flickr / Blog post)

Note that the majority of information in this article was gathered at the Server Beta User Group meeting on Thursday September 4th, the transcript for which is available here.

Server Deployments, Week 36 – Recap

On Wednesday September 3rd, the Main channel received the server maintenance project previously deployed to the three RC channels. This comprises crash mode fixes and fixes for the following:

• SVC-2262 – “Incorrect height value in postcard which sent from above 256m” (a postcard being a snapshot sent to e-mail)
• BUG-6466 – “Numbers expressed in scientific notation and include a plus sign in the exponent are not parsed as JSON numbers by LSL”, which was thought to have been fixed a while ago, but which in fact resulted in BUG-6657 – “Valid JSON numbers like 0e0 no longer valid after 14.06.26.291532″, prompting the original fix to be rolled back.

There were no planned deployments to the RC channels for week 36.

Week 37 Releases

There will be a Release Candidate channels deployment in week 37 (week commencing Monday September 8th), which will comprise crash fixes and bug fixes. Interestingly, one of the fixes will be to prevent Linden personnel from getting stuck in the new Skill Gaming regions – which Maestro jokingly describes as, “once that fix is out, I’ll no longer have an excuse to play cards all day 🙂 .”

CDN Work

Map Tiles

April Linden has been doing further refinements to the use of the CDN environment for map texture fetching on Aditi (see my notes from week 35). This work is liable to be moving to a main grid RC in the near future, and is being viewed as a “good dry run  for using the CDN for texture and mesh fetching in the future”, according to Maestro.

Viewer Mesh Request Throttling

“During mesh fetch testing with the CDN, we realized that we were throttled by a viewer’s internal throttle,” Maestro said of the ongoing texture and mesh CDN testing currently underway on Aditi (again, please refer to my week 35 and  week 33 reports). He went on:

The viewer ‘only’ requests 100 meshes/second because the simulator has a similar throttle for answering those requests, but with the CDN, the simulator’s throttle is irrelevant. Monty did a special build of his viewer (I’m not sure if the change was permanent) which removed the throttle, and I benchmarked an average of ~365 meshes/second on the CDN region with it. Which, in my mind, is approaching “fast enough” 🙂 .

This probably means that when the CDN work is completed (which will include viewer-side changes at some point), the viewer’s throttle will likely remain, but will be set higher and perhaps with a debug setting. “Because,” as Maestro said, “if mesh loading got way too fast, eventually you might have viewer performance issues from the insane download speed.”

Yuzuru Jewell (of Kane projects fame), has been carrying out tests from Japan, which saw his mesh load speed double via the CDN when using an unmodified viewer.

 Other Items

HUD Detaching / Reattaching Following Teleport

This was first commented on in my week 32 meeting update, and referred to again in week 33 (both alongside BUG-6908). Commenting on the state-of-play with investigations into the issue, Maestro indicated that there is some thinking that it may have the same cause as BUG-7131 (Unexpected behaviour of on_rez event and llDetachFromAvatar() ), which is being looked into, although there is no news on a fix as yet.

Materials Rendering via Basic Shaders and Improving Projectors

In week 34, I carried news about Geenz Spad’s proposal for introducing materials rendering into basic shaders (i.e. so users would not necessarily need to have Advanced Lighting Model enabled in order to see materials), and to improve the functionality of projectors in Second Life.

The JIRA submitted for this work were respectively:

• STORM-2077 – Add support for materials in basic shaders
• STORM-2056 – Projector reflections do not respect the environment intensity parameter
• STORM-2067 – Glossy Projectors

The news on adding materials to basic shaders isn’t currently encouraging. The most recent comment from Marissa Linden (August 20th) states, “Moved to STORM. However our internal engineers do not believe that this can safely be implemented.”

Geenz’s work on projectors an glossiness: top: as test items currently appear in Firestorm. Bottom: as they appear in the test viewer

News is a little more positive with the projector work, with a test viewer having been built, offering those who are interested with an opportunity to play with the updated projector capabilities. There is also a test area on Hippo Hollow.

SL projects update 34/1: server, viewer, materials processing

L’Arc-en-Ciel, WinterFall (Flickr) – Blog post

Server Deployments

As always, please refer to the server deployment thread for the latest news and information.

There was no deployment on the Main (SLS) channel on Tuesday August 19th. All three RC channels should receive the same server maintenance project  on Wednesday August 20th, aimed at fixing a crash mode.

SL Viewer Updates

The library refresh viewer, version 3.7.14.292638 was promoted to the de facto release viewer on Monday August 18th. This viewer contains an update to a large set of libraries used by the viewer to provide security, stability and consistency improvements to this and future viewers – release notes.

This leaves just the Experience Keys project viewer (due for a refresh in week 34), the Oculus Rift project viewer (due to undergo updates in the coming weeks following the Lab’s receipt of Oculus Rift DK2 headsets), and the RC / experimental log-in viewer in various visible viewer channels.

Group Ban Notifications JIRA

A couple of group ban issues have been raised on when and how notifications on ejection and banning are displayed by the viewer since the arrival of the group ban capabilities (or aren’t displayed, as the case may be) – see BUG-2054 and BUG-5928. Cinder Roxley has submitted code as a part of rectifying BUG-2054, and the Lab are looking and what they need to do to ensure consistent and logical notifications are given.

Materials and Related News

Materials Rendering via Basic Shaders

Geenz Spad contacted me over the weekend to point-out BUG-2077, a feature request that would enable all users that enable Basic Shaders to see a subset of materials functionality present in Advanced Lighting Model. Commenting on the JIRA, Geenz notes:

The performance impact won’t be noticeable on the vast majority of GPUs that support at least atmospheric shading and basic shaders, and should generally be much faster on systems that have trouble with ALM. On top of that, this should enable materials to work in water reflections and refractions to some extent.

However, he also notes a number of constraints:

• Maximum number of lights will go unchanged
• Projectors still will not work
• Gamma correction will only be approximated.

In pointing the JIRA out to me, Geenz said, “A proposal has been submitted to LL regarding materials in basic shaders. I’ve started working on materials in basic shaders already, though work will be moving along slowly so definitely don’t expect this to done for a little while.”

At the same time, Geenz is also working on fixing projector reflections not respecting the environment intensity parameter (see BUG-2056). Currently, projector reflections are treated as specular reflections rather than environment reflections (see below). This fix would correct that.

BUG-2056: The image on the left shows projector reflections as they are seen today: overly brightly despite the environment intensity setting (in this case: glossiness 0; environment intensity: 20); the image on the right demonstrates how the reflections should appear with the same environment intensity (images: Geenz Spad)

Again speaking to me about the work, Geenz said, “This is something that I largely started working on while fixing the environment intensity bug on projectors.  Projectors didn’t seem to make a whole lot of sense in their previous state, and since we have enough information to actually do “glossy” reflections with projectors as it is, it made much more sense to just have glossiness tied to the existing glossiness material parameter.”

A further JIRA submitted by Geenz (see BUG-2067) proposes a means of improving the use of projectors to create surface “reflections”. Geenz provides the explanation thus:

Presently projectors have very strange behavior. Depending on a surface’s environment intensity, they get blurrier the more intense they are, and the reflections “fatten” depending on how intense the reflections on the surface are. This doesn’t really make a whole lot of sense.

Depending on how glossy the surface is, projector reflections should become sharper for higher gloss values and blurrier for lower values. On top of that, projector reflections shouldn’t “fatten” based upon intensity; this makes them unusable for decent looking reflections.

This feature makes use of the glossiness parameter to calculate the “gloss” of projector reflections.

Pojectors and glossiness: top = as things appear at present when projecting images onto glossy surfaces; bottom = as they would appear if Geenz’s work is implemented (images: Geenz Spad)

Other Items

Mac Cocoa applicationShouldTerminate Issue

Cinder Roxley has pointed-out a problem with the Cocoa-specific applicationShouldTerminate function within the viewer, which she explains thus:

Say you are logged into sl, and you open appstore and there is an update that needs a restart to complete. Normally you click restart and it shuts down all apps completes the update and when you login your apps are reopened. Because the viewer is sending a bad value back to OSX, OSX will not close it, and it stops the restart from happening.

STORM-2053, submitted by Cinder provides a fix for this problem.

Mirror Reflections

Work is continuing to refine the SL mirrors project (see my report and JIRA (BUG-2055  initiated by Zi Ree of the Firestorm team). There has been some lively lively debate on the JIRA over the course of the last week. The more recent progress has been focused on getting mirrors to work with the Advanced lighting Model (ALM) active.

On top of everything else he’s doing, Geenz Spad has been providing pointers for some the work as well as demonstrating how mirror surfaces could benefit if they are made to work with materials, as shown in the images below.

How mirror reflections might benefit when working with materials: (L): A mirror sphere with a normal map applied; (c) a mirror sphere with environment mask applied; (r) the sphere with both a normal map and an evironment mask applied (images: Geenz Spad)

There is still a fair amount of work still to do before it is likely that the Lab look at any proposal arising from this. I’ll continue to update on progress as it is made, as I also hope to with Geenz’s work with projectors and materials as noted earlier in this report.

SL projects update 24/2: viewer, LSL materials functions

 Server Deployments Week 24 – Recap

• There was no new deployment to the Main (SLS) channel, although it was subject to a grid-wide restart following schedule maintenance on Tuesday June 10th
• BlueSteel returned to the Sunshine / AISv3  inventory update, which requires the use of the Sunshine RC Viewer
• LeTigre once more had the server-side group ban project updates deployed to it. See the release notes for details
• Magnum returned to the Experience Tools project.

The RC channel updates were essentially the same updates as deployed in week 23, but subsequently overwritten following a grid-wide security issue update.

SL Viewer

The Snowstorm code contributions viewer appeared as a project viewer on June 12th. Version 3.7.9.290788 includes some 20 code contributions to the viewer, including:

• STORM-68 Allow setting of default permissions on creation of objects, clothing, scripts, notecards, etc.

The new floater for setting default permissions for created items as it should appear in the Snowstorm viewer

• STORM-1831 Obtain LSL syntax table from simulator so that it is always up to date: this update allows the viewer to obtain the information required for syntax highlighting directly from the simulator the viewer is connected to, eliminating issues with using manually updated syntax files within the viewer falling out-of-synch with the simulators as new LSL syntax as new functions and parameters, etc., are added
• STORM-1966 Block installation on old and unpatched versions of Windows: this updates causes the viewer’s Windows installer to check to see Windows XP systems have the latest patches installed (i.e. Service Pack 3 for 32-bit XP and Service Pack 2 for 64-bit XP). Any XP systems not meeting these requirements will be unable to install the viewer until such time as they are updated. Additionally, Windows Vista and Windows 7 systems  lacking a Service Pack update will receive a warning, but installation of the viewer will not be blocked

For the full list of OPEN and STORM updates, please refer to the release notes.

LSL Functions for Materials

The Server Beta Meeting on Thursday June 12th included tests to see whether the new LSL functions for materials might offer griefing opportunities. Maestro Linden had created two 256 prim linksets using default prim cubes, one of which was scripted to use PRIM_NORMAL to continuously set a unique material on each of the 6 faces of each prim, and the other was scripted to continuously set PRIM_TEXTURE on each face to a different alpha-blended diffuse texture.

Two sets of four of these objects were rezzed in turn, and meeting attendees asked to monitor their viewer performance (FPS and UDP bandwidth) while the Lab watched the simulator.

Server-wise, performance was largely unaffected by either type of object, with the load being largely controlled by the built-in LSL performance controls. Throughout both tests, and with no  objects rezzed, script spare time remained almost constant around the 14-15ms mark.

Viewer-wise, both types of object impacted FPS, with most people reporting around a 50% drop from the materials-enabled objects, compared to around 40% with the texture changing objects.

Both tests saw an increase in UDP information being sent to the viewer, with bandwidth use increasing by a factor of around 3.5 to 4 (e.g. 180-200kbps to 700-800kbps) with the materials objects and a factor of around 5 to 5.5 for the texture changing objects. As indicated by Maestro, the lower bandwidth use by the materials objects was due to the throttles already in place for how quickly the viewer will look up materials properties.

The takeaway from this (and other tests Maestro has performed) is that scripted materials controls are unlikely to be a major source of griefing. The simulator seems to handle excessive use of script materials in its stride, and impacts on the viewer’s frame rate can be mitigated by using Develop > Show Updates to Objects (CTRL-ALT-SHIIFT-U) to block the offending object.

There are still concerns over potential bandwidth impacts, such as by combining the materials LSL functions with other scripted controls, and concerns how the viewer might be affected by peculiar uses of the materials functions (such as combining them with the already laggy animated mesh tails that are available). However, it seems that for now, the Lab will continue to monitor things to see what happens and whether anything unexpected does crop-up, rather than moving immediately to apply throttles to the functions.

In the meantime, the arrival of these functions has prompted people to start putting together feature requests to be able to animate diffuse (texture), normal and specular maps on an object / object face independently to one another. The Lab has previously indicated that trying to do this via llSetTextureAnim() would be “pretty ugly to implement or would need some careful design …” and that as such they have no plans to try this at present. It’ll be interesting to see if any feature request(s) put forward persuade them otherwise.

SL projects updates 22/2: LSL functions for materials avialable for Aditi testing

Maestro Linden used the Server Beta meeting to announce that Simon Linden’s work on adding some LSL support for materials is now available for testing on Aditi.

Regions roller-test102 and roller-test103, both on channel DRTSIM-253, have the server-side scripting support (note the SLurls are for ADITI).

Please note that this is very much a work-in-progress, and the Lab’s own testing is still underway.

The following details can also be found on the Server Beta Meeting wiki page.

Parameters have been added to the llSetPrimitiveParams() and llGetPrimitiveParams() functions to enable scripted control of materials maps

Materials can be added to object faces with llSetPrimitiveParams() functions using the following parameters:

• [PRIM_SPECULAR, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
• [PRIM_NORMAL, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians]
• [PRIM_ALPHA_MODE, integer face, integer alpha_mode, integer alpha_cutoff]
  • Valid alpha_mode options are PRIM_ALPHA_MODE_NONE, PRIM_ALPHA_MODE_BLEND, PRIM_ALPHA_MODE_MASK, PRIM_ALPHA_MODE_EMISSIVE

Materials can be read with the various llGetPrimitiveParams() functions using the following parameters:

• [PRIM_SPECULAR, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
• [PRIM_NORMAL, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians]
• [PRIM_ALPHA_MODE, integer face] returns [integer alpha_mode, integer alpha_cutoff]

Additional Notes

• Behaviour for both getting and setting materials parameters should basically correspond to behaviour with PRIM_TEXTURE
• The color vectors use 0.0-1.0 as the range, as with llSetColor()
• The integer parameters for PRIM_SPECULAR correspond to the same values that you see in the build tool
• Components of a material can be ‘reset’ as follows:
  • PRIM_NORMAL and PRIM_SPECULAR settings are set to default values by setting the texture to NULL_KEY
  • PRIM_ALPHA_MODE settings are set to default values by setting the alpha_mode to PRIM_ALPHA_MODE_BLEND – mask_cutoff is actually reset to 0 unless the alpha mode is PRIM_ALPHA_MODE_MASK
  • When PRIM_NORMAL, PRIM_SPECULAR, and PRIM_ALPHA_MODE settings are all set to default values, the material is deleted from that prim face, and LI may be updated accordingly
• This new scripted capability will only work on the nominated test regions
• ALM must obviously be enabled.

Known Issues

• The version currently on Aditi lacks proper throttling, so there could be performance issues if scripts behave badly. A throttle will be added in due course
• There is a viewer rendering issue, where the face will not be rendered and you’ll see log spam (BUG-6187). This can happen:
  • If the viewer has ALM enabled
  • And a prim face has a material on it
  • And PRIM_ALPHA_MODE is PRIM_ALPHA_MODE_BLEND (this is the default after a material is added)
  • And the diffuse texture does not have an alpha channel (e.g. plywood)

With reference to BUG-6187, Maestro added, “One thing to keep in mind …  is that if your diffuse texture lacks an alpha channel, you’ll also want to set the alpha mode to PRIM_ALPHA_MODE_NONE to avoid the bug, even if you really just want to add a normal map.”

The bug itself doesn’t mean the alpha mode should be set every time a materials map is changed, only when adding a material to a face which previously didn’t have a material. Maestro went on to give some further information on the issue:

What happens when you add a material via the build tool, is that the viewer inspects whether the current diffuse texture has an alpha channel and automatically sets the alpha mode to ALPHA_MODE_NONE if the diffuse texture is opaque, but keeps it at _BLEND if there’s an alpha channel. Unfortunately, the simulator can’t do this, because it doesn’t necessarily have the texture asset and doesn’t have the right libs to process texture assets in that manner. The build tool has some trickery where it always greys out the UI for alpha mode when the texture doesn’t have an alpha channel. Anyway, it’s kind of a hassle, but once PRIM_ALPHA_MODE is set to something ‘friendly’, you should be able to update normal or specular settings without touching it again.

As this is a viewer rendering bug, there is no timescale as to when a fix may appear.

The Lab is particularly interested in seeing how use of these new parameters may affect performance (such as through rapid and repeated changes to maps), and what kinds of rates cause these issues, so that they can more accurately assess the required level of throttling.

Depending upon how further testing goes, what additional changes the Lab needs to make, and what has already been scheduled at the time, these updates might be available on an RC on Agni in a few weeks.

SL projects updates week 22/1: LSL functions for materials, group bans

It’s a light start to project news from the lab this week.

Server Deployments Week 22

There are currently no planned deployments for the week.

Materials LSL Functions

There’s still no firm date for when this are liable to surface for testing, but speaking at the Simulator User Group on Tuesday May 27th, Simon Linden indicated the time is getting “closer”. In the meantime he re-iterated the get and set functions currently being worked upon, which remains as per my week 21 report, namely:

Get functions:

• [PRIM_SPECULAR, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
• [PRIM_NORMAL, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians]
• [PRIM_ALPHA_MODE, integer face] returns [integer alpha_mode, integer alpha_cutoff]

Set functions:

• [PRIM_SPECULAR, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
• [PRIM_NORMAL, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians]
• [PRIM_ALPHA_MODE, integer face, integer alpha_mode, integer alpha_cutoff]”

The same access rules will apply to materials as for diffuse (texture) maps.

Most people may already be aware that llSetTextureAnim() will apply an animation equally across all three maps applied to an object / object face. However, the Lab is not currently looking to add additional parameters to llSetTextureAnim() so that each type of map independently of the others. Offering an explanation as to why this is the case, Simon said:

I’m guessing that would be pretty ugly to implement … or would need some careful design and thought as it couldn’t create new material entries under the hood.  I think that will have to be a follow-on feature … I can imagine it might create some cool effects but it would have to be carefully done not to blow up the materials accounting.

Group Bans

Simon indicated that the remaining back-end server updates for the group ban service may have been deployed on Tuesday May 27th. If so, it is possible that an initial server-side RC deployment of the group ban code might occur in week 23, together with the appearance of the group ban viewer. however this is pure speculation, and depends on how long the Lab want to let the back-end updates run prior to making a visible code deployment. More is likely to be known following the Server Beta meeting later in the week.

SL projects updates 21/1: server, viewer, LSL and materials

Server Deployments Week 21

Main (SL) Channel

On Tuesday May 20th, the Main (SLS) channel received the server maintenance package deployed to Magnum in week 20.This includes a bug fix for a networking-related issue that sometimes affects busy sims.

Issues encountered on the grid, but unrelated to the new code deployment, interrupted the latter. Commenting on the situation at the (late-starting) Simulator User Group meeting, Simon Linden said, “I believe the rollout stopped in the middle, and things will get patched up tomorrow morning. We’re still picking up the grid pieces and will sort out the clean up plan later in the day.”

BlueSteel and LeTigre RCs

On Wednesday May 21st, the BlueSteel and LeTigre RCs remain on the Sunshine / AIS v3 server-side code, and receive the networking-related bug fix deployed to the Magnum RC in week 20 and to the Main channel on Tuesday May 20th – see here for details.

Magnum RC

On Wednesday May 21st, the Magnum RC should receive a new project, which includes changes related to the ‘Experience Tools’ project.

SL Viewer

The de facto release viewer updated on Monday May 19th to version 3.7.8.289922, formerly the Maintenance RC comprising fixes in Recent tab, Chat, LSL editor, land management, etc; GPU table updates; crash fixes & performance improvements – release notes here.

Also on Monday May 19th, the following RC viewer updates occurred:

• The Sunshine / AIS v3 RC was temporarily removed from the Alternate Viewer page, but is expected to return soon
• A new Memplug RC viewer, version 3.7.8.289942 was released, containing a number of fixes for memory leaks which are expected to result in improved viewer performance and a reduction in crash rates.

LSL Functions for Materials

Materials processing: LSL capabilities for materials now being looked at

Further to discussions in week 20, Simon Linden had some news on the much-requested LSL functions for materials processing, saying, “I can say I was trying to grief myself with materials LSL functions the other day. I hope we can talk more about that on Thursday at the beta user group.” He went on to outline some of the functions for manipulating materials that he’s been playing with:

Get functions:
[PRIM_SPECULAR, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
[PRIM_NORMAL, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians]
[PRIM_ALPHA, integer face] returns [integer alpha_mode, integer alpha_cutoff]

Set functions:
[PRIM_SPECULAR, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
[PRIM_NORMAL, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians]
[PRIM_ALPHA, integer face, integer alpha_mode, integer alpha_cutoff]

He went on, “There is a magic default value using NULL ids that represents “no material” … so it can be removed.”

Simon also indicated that at some point soon (no date as yet), there will a few regions (most likely on Aditi, the beta grid) to try-out the new functions with the aim of seeing how the capabilities are used, how they get abused and then how SL behaves, so that some appropriate limits can be imposed to prevent deliberate or accidental abuse.

Other Items

New Mesh Avatars and the AMD/ATi Issue

On Thursday May 15th, Linden Lab launched their line of new mesh avatars to something of a mixed response. Unfortunately, said avatars may have fallen a-foul of a long-standing  rigged / fitted mesh rendering issue affecting people used AMD / ATi graphics systems with recent Catalyst drivers, and which sees rigged / fitted mesh stretching to the 0,0,0 coordinate of a region – see BUG-6065, which offers advice on circumventing the issue.