SL project news: week 2 (3): server, mesh and materials

Server Deployments – week 2

As noted in the update to part 2 of this week’s report, the planned deployment of two new releases to the RC channels didn’t go as anticipated. Originally, it had been intended that BlueSteel and LeTigre would received the new threaded region crossing code while Magnum would receive Andrew Linden’s interest list code improvements.

Interest List Deployment Cancellation

The interest list deployment was cancelled after the 11th hour discovery of some bugs with the code. Speaking at the Server Beta meeting on Thursday 10th January, Maestro Linden described the main issues as – ironically – being connected with region crossings, and with object updates.

In the first, anyone crossing between regions several times in a vehicle would experience all of their non-rigged attachments disappearing from their world view, with the viewer itself eventually physically detaching them. Not only did this cause confusion as to what was happening with attachments for those experiencing the issue, it also resulted in some avatars ending up naked following a relog.

Interest listcode: bugs led to deployment cancellation on Wednesday 9th January
Interest list code: bugs led to deployment cancellation on Wednesday 9th January

The second problem was slightly more complicated, if potentially more rare. In it, if User A had an object on the ground and User B looked at then turned their camera away such that the object was no longer on their screen, User A could then wear the object as an attachment and teleport away; however, when User B subsequently turned their camera back to where the object had been, they would still see it on the ground despite the fact it had been taken away. What happened if User A (now wearing the object) teleported back to User B wasn’t actually tested.

As a result of both of these issues and the cancellation of the interest list deployment, Magnum received the same region crossing package as intended for BlueSteel and LeTigre.

Region Crossing Code Issues

However, the bad news did not end there, as Maestro Linden explained, “After a few hours, we saw that the [region/sim] crash rate was way too high.” As a result, the threaded region crossing code was disabled via a configuration change to the servers without the need to rollback the release. Once this had happened, region crash rates returned to “normal” levels. In all the new region crossing code was active for around five hours before being disabled once more.

Analysis of the crash rate revealed it to be linked to avatars crossing to / from heavily scripted regions. While the new code was extensively tested on Aditi, the regions there were not excessively loaded with scripts during testing, and so the problem did not manifest. However, subsequent testing with the test regions running heavy script loads did result in them also crashing, confirming the problem.

At the time of writing, Kelly Linden believes he has a fix for the issue; if so, it should hopefully find its way to the RC channels in week 3, commencing Monday 14th January.

Deployments for Week 3

Both of the issues described above mean that there will be no code deployment to the Main Channel on Tuesday 15th January.

Wednesday 16th January will hopefully see the re-deployment of the interest list code and the fixed threaded region crossing code. Additionally, a main-server release is planned for the week, which comprises:

  • A clean-up of the estate access code to prevent banned avatars being able to re-enter a region
  • Server support for ‘neck’ and ‘avatar center’ attachment points. While these were added to the viewer last year, the code was never actually added to the server, resulting in some errors being experienced when using the attachment points.

SL Viewer

Week two has seen three SL viewer updates released by the Lab at the time of writing. The beta viewer rolled to 3.4.4.268697 at the start of the week, the release notes for which are available for reference. This release should hopefully include a fix for the rendering issues the earlier beta was experiencing. In addition, the development viewer saw the release of version 3.4.5.268856, and the CHUI development viewer of 3.4.3.268914, although the main branch of the project viewer remains the same.

Materials Processing

As mentioned in the first part of this report, materials processing will only be seen in viewers running in deferred mode. This led to questions being asked at the Opensource Dev meeting on Wednesday 9th January as to how things will be handled should a viewer be switched from running in non-deferred mode to deferred in a region / parcel which uses materials processing.

The current plan is for the viewer to receive the UUIDS for normal and specular maps alongside everything else on connecting to a region, but for the viewer not to process the UUIDs for any normal / specular maps if it is not running in deferred mode. Should deferred subsequently be enabled, the viewer can then use the UUIDs to request the additional normal and specular maps from the server in order to render them, while continuing to use textures, etc., which have already been cached locally.

Testing materials processing in SL. Note the texture of some surfaces and reflections on others (image courtesy of Geenz Spad) - click to enlarge
Testing materials processing in SL. Note the texture of some surfaces and reflections on others (image courtesy of Geenz Spad) – click to enlarge – Note that this is not indicative of materials processing being openly available

Due to some concerns being raised over the number of viewers running in deferred mode (whether with or without lighting and shadows, etc.,  active), there may be an attempt to collect and collate data on those viewers running in deferred mode and – perhaps equally as importantly – those capable of running in deferred but which are not. This information would help tremendously with any educational campaign required to increase people’s awareness of both materials processing, once live, and in the overall changes and improvements being made to the rendering system.

Parametric Deformer and Mesh

There is no major news on the parametric deformer itself at present. There are a number of people outside of the Lab carrying out some testing, but the anticipated internal meeting at the Lab has yet to occur – the hope is that it will be on Friday 11th January. In the meantime, there may be a move to merge the deformer code with viewer development as, in Oz linden words, the deformer is, “Pretty far behind now :(.”.

In terms of mesh in general, Maestro Linden reports that Baker Linden’s threaded mesh rezzing code is now running on Aditi on the DRTSIM-194 on a few regions, such as CCMTEST26. The aim of this work is to improve simulator performance when rezzing complicated meshes. Maestro reports that while it well likely be a few weeks before the code is ready for an RC channel release, particularly as there is at least one memory leak to be fixed, overall the code is having the desired effect, with simulator fps remaining around 45, compared to 35fps on Agni.

Network Issues

As most people noticed, Tuesday 8th January was marked by major network issues which, among other things, resulted in extreme lag, high packet loss and a general feeling of no fun all around. During the Server Beta meeting, Maestro Linden confirmed the problem had been within the network services at the Lab’s co-location facility in Phoenix. Adding to the explanation, Coyot Linden indicated that the problem lay in a failed network link, compounded by issues occurring with the redundant link. As a result, the two problems took the data centre around 4 hours to resolve to a point where LL were comfortable in issuing an “all clear” via the Grid Status page.

12 thoughts on “SL project news: week 2 (3): server, mesh and materials

  1. After I’ve downloaded the SL Development viewer, how do I test materials processing? Which regions/parcels use materials processing and how do I know what to look for/at when I’m running the viewer in deferred mode?

    Like

    1. So far as I’m aware, there are no public test areas for materials processing as yet, and the code is not yet in viewer-dev. The repro for the code was accidentally exposed just before Christmas, but that has been rectified, and according to Oz, the code won’t be appearing for another couple of weeks.

      The image in this report was supplied by Geenz Spad purely as a tease, and relates to the closed teasing which is occurring at present.

      Like

  2. As always Inara, your writing is informative, concise and intelligent – thank you for this blog. It really does make my SL so much better. You provide a genuine insight into SL, and I think this is simply one of the best blogs about it I have ever read.

    Like

  3. The “Region Crossing” processing is very important to me personally (I’m a speedboat demon out on the Blake Sea). Thanks for explaining the issues in clear language.

    Like

    1. You’re welcome, Yordie!

      It’ll be interesting to see what mods the Lab has made since the pile-on test. As mentioned in my report on the outcome, the results at the time, when using vehicles, were disappointing. Hopefully, some tweaks have been made as a result of data gathered from the tests.

      Like

      1. It’s good to know they are really hammering this code in testing. Sounds like they are very serious.

        Like

        1. The turn-out for the pile-on test was a little low – but it was interesting to learn from Caleb that they did get a lot of data out of the hour or two we spent slamming around the regions. Hopefully, we’ll find out this week what has happened and how the code fares on an RC release.

          Like

          1. Seeing as the servers start failing after a few hours, it sounds like a small memory leak. always hard to track down when they are that small.

            Like

Comments are closed.