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.
The Snowstorm code contributions viewer appeared as a project viewer on June 12th. Version 126.96.36.1990788 includes some 20 code contributions to the viewer, including:
- Allow setting of default permissions on creation of objects, clothing, scripts, notecards, etc.
- 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
- 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.