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.”
Those wishing to participate will be required to be using the latest version of the Sunshine project viewer (184.108.40.2061419), 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.”
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.
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.
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.”
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.
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.