SL project updates: week 10 (2): server, SSB, materials and SSAO

Server Deployments Update

All of the deployments planned for week 10 went ahead as scheduled. While further issues related to region crossings have been reported, these are not thought to be related to any of the new code deployments for this week (see below for more).

The one issue that has been noted with the deployments is for VWR-786, which formed a part of the Magnum deployment.

This was supposed to ensure that if a friend does not have ‘See my online status’ permission, they will now see “User is not online ..” message following IM or inventory offer. However, the result has also been that if you IM a non-friend, the server always returns the “User is not online” message. The short-term solution for this is to remove the change from week 11’s releases in the interest of getting the other fixes (BUG-1612 and SVC-8019) across the grid.

The Lab is particularly keen to see SVC-8019 deployed to the entire grid, as this should fix issues of regions not handshaking correctly with one another following a rolling restart. The cause of this is believed to be due to regions looking at stale cached copies of a neighbouring regions’ status. With the update, regions grab more up-to-date copies of the status of their neighbours.

Server-side Baking: Further Pile-on / Load Test

Nyx Linden has announced that there will be a further SSB pile-on / load test on Thursday March 14th, following-on, as with the last test, from the Server Beta meeting on Aditi. The test is liable to be in much the same format as the first test, of which Nyx notes, “It gave us a lot of information and we’ve been working on a number of fixes, both to Aditi inventory, as well as viewer and back-end changes. Given this, the reason for the next test, in Nyx’s words, is because, “We’d like to see how much progress we’re making.”

The first SSB pile-on / load test (image courtesy of Latif Khalifa
The first SSB pile-on / load test (image courtesy of Latif Khalifa

Those wishing to participate will be required to be using the latest version of the Sunshine project viewer (3.4.5.271419), and are advised to attend the Server Beta meeting on Aditi ahead of time (the meeting commences at 15:00 SLT on Thursdays). Addressing those who participated in the first test, Nyx added, “If you had trouble at the last pile-on with outfit switching, feel free to test out the new build in advance – you should be able to comment on the JIRA tasks you filed, or email me directly with any issues.”

Materials Processing

Following-on from his replies to my question at the open-source dev meeting on Monday March 4th, Oz Linden talked some more on the status of the materials processing project at the Wednesday meeting on March 6th, “There’s one build floater bug and one crash that need fixing,” he said in kicking-off the discussion on materials, “I might even be willing to let it out without the crash fix (though it’s pretty bad).”

However, before everyone starts shouting, “Yes, yes!” :), even the release of a crashy version of the project viewer requires the “other” problem to be fixed. This appears to be related to a texture list getting corrupted, and which can manifest in a number of ways, including:

  • The normal map picker reverts to displaying the diffuse (texture) map after a normal map has been selected and the picker closed, with the normal map failing to render on the object / face it has been applied to
  • If deferred rendering is turned off, anything using materials appears black
  • If bump mapping is disabled, objects using materials appear to randomly adopt nearby textures (including skin textures) which can change as the camera is rotated / moved.
Normal map application issue: a normal map is selected and apllied to an object face (l); however, on re-opening the build floater, the map appears to have reverted to the diffuse map (r), and the object face does not render as expected
Normal map application issue: a normal map is selected and applied to an object face (l); however, on re-opening the build floater, the map appears to have reverted to the diffuse map (r), and the object face does not render as expected

I’ve not experienced the second and third of these issues in trying-out the pre-release viewer, but can attest to the first occurring, and Oz has confirmed that it has yet to be fixed.

LSL Support or No LSL Support?

There has been some discussion on the possible use of LSL functions (beyond those already available for texture manipulation – animating them, etc.) being a part of the materials project. When the topic came up during a Server Beta meeting earlier in the year, Maestro Linden indicated the section of the original proposal had been removed, for fear of it being exploited and used to thrash the server and rendering pipeline in a similar manner as sculpt UUID flipping (using a script to repeatedly change the map applied to a sculpt so it is constantly being re-rendered) is bad for the renderer. However, Geenz Spad later indicated that scripted capabilities might be a future release, saying, “I’m not saying no one would add scripting for the *new* parameters. Just that it won’t make it as part of the first release; think of it as a ‘we didn’t have time’ sort of thing.”

I asked Kelly Linden directly on the matter, and his reply suggested that things might go either way, “There are no projects I am aware of, currently in the works to add more LSL functionality for materials,” he stated, before continuing, “When there is news on that someone will announce news on it.” So it still seems likely that the Lab will weigh matters of demand against potential issues / exploits and the amount of work involved, before they commit either way.

Screen Space Ambient Occlusion (SSAO)

Another project heading towards the SL viewer is that of improvements to screen space ambient occlusion, or SSAO.

Tofu Buzzard is working on this (STORM-1928), and while there is some way to go on this before it is ready for prime-time release, aspects of his work can be found in both Niran’s Viewer and the Dolphin viewer.

SSAO haze effect - fix from Tofu Blizzard, available in deferred mode on Dolphin and Niran's viewers.
SSAO haze effect – fix from Tofu Blizzard, available in deferred mode on Dolphin and Niran’s viewers (image courtesy of NiranV Dean)

Firestorm is also set to implement SSAO, although there are problems with SSAO currently conflicting somewhat with the viewer’s default Ambient Occlusion setting in deferred rendering, as Whirly Fizzle indicated at the open-source dev meeting on the 6th March. Whirly also indicated that the SSAO updates may also been scene-dependent (working with some, not with others), and can do, “Weird things to the sun if you take it as-is.”

SSAO issue: A facial view in the current release of Firestorm with Ambient Occlusion enabled (l); a similar image captured on the upcoming Firestorm release, showing a "dirty" face as a result of enabling SSAO alongside Ambient Occlusion (r)
SSAO issue: A facial view in the current release of Firestorm with Ambient Occlusion enabled (l); a similar image captured on the upcoming Firestorm release, showing a “dirty” face as a result of enabling Ambient Occlusion alongside SSAO (r) – images courtesy of Whirly Fizzle

Ergo, there would still appear to be more work to be done here before anything appears by way of options / improvements in the SL viewer. It is possible the next release of Firestorm will join Niran’s Viewer and Dolphin in supporting the capability, as work has apparently been carried out to fix the issues which are known to occur – although it is unclear as to how far down the road the fixes are when compared to other work being carried-out on that viewer.

Issues Updates

Region Crossings

These continue to be a problem, with reports routinely appearing on the server deployment thread as well as being raised at various Simulator and Server Beta User Group meetings. Issues include complete loss of control of vehicles, “broken” camera positioning following recovery, etc. As mentioned in week 9, Eric Gregan has produced a video demonstrating the problem as it occurs on some aircraft, although he’s also come up with a means of avoiding the issue which may or may not work for people:

Commenting on the problem Ayesha Askham asked:

@Maestro and dd (and Wolf, who “knows about these things”)

Is it possible that the “Interest List” changes that Andrew has been heading up could have any bearing on these issues?  I ask because “In-sim” performance on a racetrack (Amber Skyline) has noticeably changed in recent weeks, and NOT for the better.  The coincidence seems remarkable seeing as other unexpected and unwanted effects have definitely been seen.

This prompted Maestro Linden to reply:

Wolfbaginski, Ayesha, Atashi: yes, the issue does appear to be related to the interest list changes.  It seems that after some sim crossings, a vehicle’s passenger won’t have the vehicle in their interest list.  The result is that the viewer doesn’t get any object updates about the vehicle, and instead extrapolates the velocity of it by default.

For some reason airplanes seem to be most affected – this might be caused by the high speeds (relative to other vehicle types), or possibly elevation.  I read a suggestion that selecting the vehicle fixes causes object updates to happen again – this makes sense for an interest list bug, since selected objects are treated specially in the interest list.

He also indicated that the specific problems mentioned above have now been logged as a (non-public) JIRA (BUG-1814), and that any fixes for the issue are likely to be deployed under that JIRA reference.

Advertisement

8 thoughts on “SL project updates: week 10 (2): server, SSB, materials and SSAO

  1. When it comes to materials and scripting, all I really want to start out with is to have the normal and specular images move with the diffuse image when a function like llSetTextureAnimation() is used. That’ll get me things like water or lava, which would be pretty cool. I’ve rather assumed this would happen, since there’s no UUID flipping worries there.

    Like

    1. Yes, I am rather glad it has this capability out of the box. This is at least given as I understand it ATM; I like most others have yet to see/use it. I would also imagine certain functions like llSetLinkPrimitiveParams /Fast should be able to change the settings as a whole offset/repeats ect without causing and UUID flipping issues as well. If not this round maybe soon there after.

      Like

    2. Yup. All current animation parameters work just fine with materials; I’ve been lucky enough to have a bit of a play with them (prior to the texture list issue).

      Like

    3. Although being able to set *different* animation properties for the normal-, specular-, and diffusemaps would allow us to generate *awesome* water.

      Like

  2. Well, the diagonal region handshake fix did not work. I am not sure LL has a good handle on what the problem(s) actually is(are). At any rate, Mullein does not rez from Brocade.

    Like

    1. Mea Culpa. I was “at” the meeting where the update was initially discussed, but not actually “there” as midday (SLT) UG meetings frequently see me in attendance but AFK for a large proportion of the time. Therefore I read too much into the chat transcript when first reporting the fix on Magnum. It’s purely about the issues of sims being visible to one another, but not actually communicating correctly with one another. My apologies.

      Like

  3. So far I’m not seeing where the benefits of the ‘interest list’ are. Slightly worried performance will be degraded rather than improved. Where can I get evidence of improvment?

    Like

    1. There’s only anecdotal evidence from our perspective, given the updates are all currently server-side. Doubtless LL have some metrics for the same reason. However, I suspect there may well be a healthy debate on the issue at the next Simulator UG meeting (SLurl) on Tuesday 12th March (midday SLT), following Maestro’s comments and given that is the meeting Andrew Linden (who is driving the interest list project) attends.

      Like

Comments are closed.