SL projects update week 27/2: server updates, Experience Keys

Server Deployments Recap

There were no deployments to the Main channel or to the BlueSteel and LeTigre RCs. Magnum received an update to the Experience Tools project, intended to provide a fix for BUG-6438 “Objects attached via llAttachToAvatarTemp to object owner detach when script is removed from prim inventory” and UI updates. – release notes.

Week 28 Updates – LSL Support for Materials

Subject to last-minute hiccups, it is likely that the LSL support for materials (normal and specular maps, and diffuse texture alpha mode) currently on BlueSteel and LeTigre will be promoted to the Main channel and to the Magnum RC in week 28 (week commencing Monday July 7th).

LSL support for materials looks as if it will go grid-wide in week 28 (week commencing Monday July 7th)
LSL support for materials looks as if it will go grid-wide in week 28 (week commencing Monday July 7th)

There is still no additional throttling in place for the LSL materials functions, as testing revealed they may not be any need for them. adding to this, Maestro Linden said at the Server Beta meeting on Thursday July 3rd, “It’s throttled via the normal script time throttles, there’s no special X/minute throttle. Well, also there’s a throttle for accessing the materials list by viewers. So even when your viewer knows that an object got material X via the update, it may have to access the RenderMaterials capability to look up the render parameters, and that capability access is throttled (the viewer knows to request at a rate below the throttle so that it doesn’t hit failures).”

 Experience Keys

There is liable to be a discussion of the Experience Keys project at the next Simulator User Group meeting, to be held on Tuesday July 8th, with members of that project team in attendance. The meeting will take place in Denby, on the main grid, commencing at 12:00 noon SLT.

Webkit News

As I’ve previously reported on a number of occasions, Webkit is a third-party library used within the viewer for a number of tasks. For example,  it powers the built-in web browser, and is used to display profiles (unless you’re using a viewer supporting legacy profiles). It is also used with like Media on a Prim (MOAP) and many in-world televisions.  There have been an increasing number of issues with Webkit which have caused some pain (see BUG-4763 and FIRE-12642, and FIRE-11057), and Monty Linden has been poking at as a part of he ongoing work with the third-party libraries used in the viewer build process.

A major problem here is that Webkit itself has deprecated, leaving the Lab needing a replacement. Speaking at the Future of SL meeting, hosted by the Firestorm team on Wednesday July 2nd, Oz Linden indicated that a decision has been made to replace Webkit with the Chromium Embedded Framework (CEF). There is no indication of how long this work will take, as it is a very non-trivial effort which is leveraging work already carried out on the Lab’s next generation platform and other internal services.

GPU Updates

Also during the Future of SL meeting, Oz indicated that there are two upcoming changes which will affect GPUs and GPU memory usage.  Both are currently with LL’s QA team.

The first eliminates using the GPU card name as a means of recognising the card’s capabilities. Once released, the viewer will be able to recognise GPUs a lot more dynamically. One benefit of this is that people with state-of-the-art GPUs should no longer experience the viewer failing to recognise their card and defaulting to basic graphics

The second is a fix for how the viewer uses a GPU’s memory. “Many of you will have noticed that we don’t use all of the video memory on your video cards,” Oz said of the fix at the meeting. “It turns out that’s because of a very old bug that plagued us a long time ago and we sort-of arbitrarily, in order to avoid tickling the bug, we capped how much memory we would ever use.”

With the fix, the viewer will be able to measure the amount of GPU memory and then allocate itself what is liable to be a reasonable share of that memory.