Category: 2013 Project Updates

SSB/A: rolling to LeTigre, Wednesday July 10th plus Catznip updates

Posted on by Inara Pey

Update Wednesday July 10th: In checking the forum deployment thread for this week’s roll-outs, I see that KarenMichelle Lane has provided a list of regions on LeTigre where SSB/A will be enabled once they have restarted. Again, you’ll need to have an SSB/A-enabled viewer to avoid issues with avatar rendering on these regions. If you find that once the restarts have completed you are encountering issues with avatar rendering (for example, you are using an SSB/A viewer and find you avatar fails to render for yourself or others), or other issues which appear to be linked to SSB/A, please consider raising a bug report detailing the problem, how to reproduce it, and including your environment information (Help > About (Viewer Name) > Copy to Clipboard), which references Project Sunshine.

Update, 22:00 BST: Exodus have released Exodus 13.7.9.1, which includes SSB/A support, CHUI (the Communications Hub User Interface) and the removal of RLVa.

This week marks the start of the enabling of Server-side Baking / Appearance in Second Life.

On Wednesday July 10th, LeTigre will become the first Release Candidate channel on which SSB/A will be enabled. While it is subject to confirmation, it would appear as though all regions on LeTigre will have SSB/A enable once the Wednesday restarts have been completed – I’ll be updating on this following the Simulator User Group meeting on Tuesday 9th July.

In short this means:

  • Regions on the LeTigre RC channel will see UpdateAgentAppearance, enabled. This is used to request a server-side appearance bake
  • The ability of connected viewers to upload baked textures via the UploadBakedTexture capability and via AssetUploadRequest will be depreciated and removed from simulators on the LeTigre channel
  • As a result, viewers that do not support server-side baking will fail to display avatars correctly.
If you want to avoid seeing increasing numbers of grey avatars (l) and / or avoid people telling you, "you're a cloud" when you appear perfectly fine to yourself (c), update to a version of a viewer supporting SSB/A and see and be seen (r)
If you want to avoid seeing increasing numbers of grey avatars (l) and / or avoid people telling you, “you’re a cloud” when you appear perfectly fine to yourself (c), update to a version of a viewer supporting SSB/A to see others, and have them see you, properly rendered  (r)

Note also that as a result of the SSB/A changes, “temporary texture” uploads will no longer function on regions on the LeTigre RC channel. The Local Textures function found within the majority of viewer will continue to work, however, and provide an alternative means to preview textures at zero cost for most situation where this is required (other than collaborative building projects on Agni).

So, if you have resisted updating your viewer to an SSB/A capable version. or moving from a viewer which is no longer maintained & won’t be supporting SSB/A (e.g SL viewer 1.23.5 or Phoenix) now really is the time to do so. At the time of writing, of the maintained “full” viewers listed in the TPV directory, all but Dolphin, and Imprudence currently support SSB/A, while the current releases of Lumiya, Metabolt and Radegast clients also have confirmed support for SSB/A.

To make sure you get the best from SSB/A, make sure you are running the latest version of your preferred SSB/A-enabled viewer.

Catznip 8.1 Update

While Catznip R8 is SSB/A-enabled, the Catznip team have released R8.1 on Tuesday July 9th. This contains important code updates from Linden Lab. As such, it is considered a mandatory update.

If you are a Catznip user, and even if you have R8 installed, please make sure you do download and update to R8.1 when prompted.

Although Catznip 8 supports SSB/A, R8.1 includes important LL-driven updates to the viewer-side code, please make sure you update when prompted / download R8.1 from the Catnip site
Although Catznip 8 supports SSB/A, R8.1 includes important LL-driven updates to the viewer-side code. If you’re a Catznip user, please make sure you update when prompted

Related Links

SL projects update week 27: SSB/A, general news and discussions

Posted on by Inara Pey

Apologies for the late-running of this update. I started drafting it earlier in the week and, um, forgot about it.

Week 27 Server Deployments

Just a reminder that due to the Independence Day code freeze for week 27, and the fact that the Lab is closed on Thursday 4th, Friday 5th July for a long weekend, there were no server deployments this week.

Server-side Baking / Appearance

Deployment / enabling should be commencing in week 28, most likely starting on the 9th July. To help spread the message, the Lab has once again blogged on the deployment of the new service, referring to it by the official title of Project Sunshine (which is a part of the Shining Project) and again included their video explaining what is going to be happening.

The majority of maintained viewers provided by both Linden Lab and third-party viewer developers are already ready for the new service, with only Dolphin, Exodus and Imprudence being without support. Hopefully, both Dolphin and Exodus will update shortly, but it will be some time before Imprudence is in a position to adopt SSB/A – the team has a fair amount of catching-up to do.

So, to borrow from the Lab. If you’re not already running an SSB/A capability viewer: “Don’t be cloudy and grey – enjoy Sunshine today” – and update your viewer!

SL Viewer News

A further SL beta viewer release was made on Tuesday July 2nd  – version 3.6.2.278133 – with (among other things) further materials fixes, as listed in the release notes.

In other updates:

  • The Lab has made a viewer repo public which contains various bug fixes and updates made available in the beta maintenance viewer. These include items such as the additional fixes for high-resolution snapshots (to prevent things like black rectangles appearing in very high resolution images). Expect to see them filtering through into TPV soon, and for the fixes themselves to start the SL release viewer possibly sooner.
  • The “project interesting” viewer which contains viewer-side updates to complement various server-side interest list project updates is still undergoing work to fix all the blocker bugs which are currently preventing it from being made public.

In terms of the latter, Andrew Linden reports that he is looking to gather data which will allow for performance comparisons with things like scene loading pre- and post “project interesting”, to see help measure the improvements in the HTTP texture download changes implemented by Monty Linden.

Other Items

What is a Reasonable FPS Rate?

In the last part of my week 26 update, I reported that the Lab has statistics which show that around 50% of users are running viewers with the Advanced Lighting Model option (“ALM” – formerly the Lighting and Shadows option and also referred to as “deferred rendering”) active, and that they further had data to suggest that up to 75% of users have hardware capable of running with ALM enabled “with reasonable performance” in terms of frame rates (e.g. an average somewhat above 10 fps).

At the time I reported this, I noted that:

However, given that fps is a highly subjective measure and somewhat dependent on a range of external factors (such as how many other avatars are in the region with you, whether you are moving around a lot or not, etc), the “YMMV” rule comes into play.

That the term “reasonable performance” is so nebulous sparked a debate during the Simulator User Group meeting as to what might be regarded as “reasonable” frame rates for a viewer running with ALM enabled (although not necessarily with any lighting & shadows options set). The broad consensus of opinion was that a rate of around 20-30 fps would be considered “reasonable”.

Part of the concern here is that while ALM is required in order to be able to render materials effects, LL might be overly optimistic in determining which cards have ALM enabled by default, which may in turn have an additional impact on new user retention due to people logging-in to SL and experiencing extremely low frame rates and not having any understanding on how to improve their experience.

Continue reading “SL projects update week 27: SSB/A, general news and discussions” →

SL projects update week 26 (3): more viewer, SSB/A and cache

Posted on by Inara Pey

Materials Processing

As reported in part 2 of this update, the release viewer was updated on June 27th with a release containing a number of updates and fixes, including some for materials, such as occlusion culling is less effective than it should be, especially with regards to very large objects; light function sampling being incorrect in advanced lighting model and the legacy Shiny options being overly strong in deferred rendering. The initial fixes for these issues are considered important for TPVs to pick-up when integrating materials into their viewers, while follow-up releases (such as the new 3.6.1277824 beta viewer released on June 25th, being viewed as slightly less important at this time.

Materials continues to be updated and refined, and the Lab is gathering stats on viewer use with ALM enabled
Materials continues to be updated and refined, and the Lab is gathering stats on viewer use with ALM enabled

The latest stats the Lab has on viewers show that some 30% of users are currently running with the Advanced Lighting Model option (ALM – otherwise known as deferred rendering), and are thus able to see materials in use in-world, although the stats also appear to indicate that up to 75% of the user base have hardware capable of running with ALM enabled, “with reasonable performance” in terms of frame rates (e.g. an average somewhat above 10 fps). However, given that fps is a highly subjective measure and somewhat dependent on a range of external factors (such as how many other avatars are in the region with you, whether you are moving around a lot or not, etc), the “YMMV” rule comes into play.

The Lab has already carried out a fair amount of performance tuning with ALM, and at the TPV Developer meeting on Friday June 28th, Oz Linden reported that further work is going on in this area, which will include some profiling of the shaders in order to try to further improve performance.

Currently, and as previously reported in these pages, the Cool VL viewer experimental branch and the Black Dragon 2.2.3 beta both provide materials processing capabilities.

Viewer Release Process and Viewer Updates

The expectation is now that the new viewer release process will come into effect during week 28 (week commencing Monday 8th July). The process is actually ready to go, but as with the server-side of things, the 4th July no change window means that the process cannot be implemented in week 27.

Vivox Update

Once the new process is running, the Vivox update is likely to be one of the first items to go to a viewer release candidate. This update should greatly improve Voice quality within SL. A further Vivox update is liable to follow this at some point.

Interest List Improvements

The viewer-side interest list updates are coming, although the viewer repro has yet to be made public, although again it is anticipated that a project or beta viewer with the updates will be made available after the holiday period, and TPVs will be able to obtain the code.

Viewer Settings

The Lab is moving to eliminate the use of viewer settings files based on channel name. This means that in future, a single SETTINGS.XML file will be used for all versions of an SL viewer which is installed. The code for this is moving towards the release channel of the SL viewer, and the hope is that it will prevent issues of confusion when settings appear to be “wiped out” when using multiple versions of the viewer (e.g. such as moving between the SL release viewer and  the SL development viewer and back a few months ago resulted in people’s toolbar buttons “vanishing” from the release viewer).

Continue reading “SL projects update week 26 (3): more viewer, SSB/A and cache” →

SL projects update week 26 (2): server, pathfinding bug, viewer updates

Posted on by Inara Pey

Server Deployments – Week 26

As always, please refer to the week’s forum deployment thread for news, updates and feedback.

Second Life Server (Main) Channel

On Tuesday 25th June, the SLS Main channel received the server maintenance package deployed to the three RC channel in week 25. This fixes a number of crash modes, addresses an issue with neighbouring region visibility, and adds the new pathfinding property CHARACTER_STAY_WITHIN_PARCEL to llCreateCharacter() and llUpdateCharacter() – see my week 19 report for details – and the object return functions I reported on in week 23.

While not intended to fix issues of diagonally adjacent regions not being visible to one another (SVC-8130), there are reports that at least some of the regions which have suffered from this issue for a considerable time can be seen from one another once more – although Maestro Linden isn’t entirely convinced the underlying cause of the problem has been corrected.

Release Candidate (RC) Channels

On Wednesday 26th June, all three RC channels (Magnum, BlueSteel and LeTigre) received a new server maintenance package, comprising:

  • A fix for ‘llApplyImpulse now works only in the root prim’ (SVC-8227)
  • Crash mode fixes
  • New LSL function: string llXorBase64(string str1, string str2)
    • Returns a string that is a Base64 XOR of Base64-formatted input strings, str1 and str2.
    • Fixes a ‘bad’ behaviour when the 2nd string contains nulls (“A” in base64) – SCR-35
    • Aside from those cases, this function behaves identically to llXorBase64StringsCorrect()
    •  added to avoid changing the behaviour of existing scripts which may rely on llXorBase64StringsCorrect()’s current output
  • Added max_materials_per_transaction flag to /simulator/features cap
    • This number returns the maximum number of materials that can be sent to the “RenderMaterials” capability in a single request.

MAX_MATERIALS_PER_TRANSACTION

Speaking at the Server Beta meeting on Thursday 27th June, Maestro Linden described the max_materials_per_transaction flag thus:

It limits how many materials the viewer can request details for or set (POST, PUT methods) in a single message. By default, the limit is 50. The reason for the limit is that we don’t want the simulator to hang if a malicious viewer requests the details of 2 billion materials at once.

So, the capability for materials is called RenderMaterials [and] it has 3 HTTP access methods:

  • GET: get the full list of details of all materials in the region
  • POST: get the materials details for a list of material_ids (the server will only parse the first max_materials_per_transaction in the post data)
  • PUT: set the materials properties of up to max_materials_per_transaction object faces

GET is used when you first connect to a region and want to get the materials of everything [in the region, not just within draw distance]; POST is used if, for example, a new object is rezzed with a new materials type, and the viewer needs to resolve what the normal map is, etc; and PUT is used for object editing.

[So] if the viewer needs to edit 80 faces at once, for example, it will know that the server limit is 50, and POST in 2 messages (one for the first 50, the other for the other 30).  [The] ‘max_materials_per_transaction’ flag in the features cap will be a way for the viewer to know if the server limit changes from 50 per message. I’m not aware of any plans to change that limit in the near future, though.

Deployments for Week 27

There will be no server-side deployments in Week 27 (commencing Monday July 1st), as US Independence Day is on Thursday July 4th. The next scheduled deployments will be in week 28, commencing Monday July 8th.

Pathfinding Bug

Elijah Linden has discovered a bug within the pathfinding code, wherein certain regions have continuous navmesh rebaking, which causes some annoying UI effects, hurts simulator performance somewhat and causes memory spikes. Regions can be affected even if pathfinding is turned off.

Voidpointer Linden assumes human form (stock)
Voidpointer Linden assumes human form (stock)

The bug arose as a result of the recent CHARACTER_STAY_WITHIN_PARCEL property added to the pathfinding capabilities. Commenting on the bug at the Server Beta meeting on Thursday 27th June, Voidpointer Linden, who implemented the new CHARACTER_STAY_WITHIN_PARCEL property, said:

As part of the STAY_WITHIN_PARCEL changes, I needed to change the way the navmesh is constructed. This involved making sure that every region did a rebake once. Unfortunately, the criteria that I used to test whether a region needed rebaking had a flaw – it can’t see parcel edges underwater [possibly because the navmesh doesn’t include areas below sea level]. So if a region has more than 1 parcel and has no parcel edges above water, then it thinks it needs to rebake. So it does.

And does so repeatedly, as Elijah Linden reported in BUG-2975 (Regions continue to requests rebake after rebakes have been performed).

There is a fix for the issue, but it currently requires testing, and may not appear for a while. In the meantime, there is one assured workaround: if your region is suffering from the issue and has a parcel which is completely submerged, subdivide / raise one part of a boundary for that parcel (and which is not also a region boundary) above water so it can be found by the navmesh rebake process.

This bug is unlikely to be resolved before week 28 due to there being no deployments scheduled for week 27, as mentioned above.

SL Viewer

The SL release viewer updated to version 3.6.1.278007 on June 27th, containing the fixes from the 3.6.1.277611 beta release. This contains some updates related to the viewer being available via Amazon, and fixes for occlusion culling being less effective than it should be, legacy Shiny being too strong in ALM with materials,light function sampling is incorrect in advanced lighting model and a viewer compilation error.

The beta viewer updated to 3.6.1.277824 on June 26th, with the release notes listing the same updates as 3.6.1.277611 and 3.6.1.278007 – so these appear to be work-in-progress fixes.

SL projects update week 26 (1): server, viewer, materials

Posted on by Inara Pey

Server Deployments – Week 26

As always, please refer to the week’s forum deployment thread for news, updates and feedback.

Second Life Server (Main) Channel

On Tuesday 25th June, the SLS Main channel received the server maintenance package deployed to the three RC channel in week 25. This fixes a number of crash modes, addresses an issue with neighbouring region visibility, and adds new LSL capabilities:

  • The new pathfinding property CHARACTER_STAY_WITHIN_PARCEL, which can be used with llCreateCharacter() and llUpdateCharacter(), and is intended to help with keeping characters within parcel boundaries – see my week 19 report for details
  • The new object return functions I reported on in week 23, namely llReturnObjectsByOwner and llReturnObjectsByID, are intended to provide an automated means of returning objects to their owners – see my full update on these functions for details.

This package also includes the following:

  • An update to llReturnObjectsByID() to prevent it from returning other objects which are owned by the parcel owner or estate owner/manager
  • A fix for an issue in which LSL HTTP-in scripts would sometimes see the incorrect URL (BUG-2833)
  • A fix for Bug 2850 (Cannot rez objects in Bluesteel and LeTigre parcels which disallow object entry) – which caused this deployment to be replaced by the Magnum RC package in week 24.

The neighbouring region visibility issue referred to in the package is for SVC-8019, which is related to issues with regions failing to communicate with their neighbours for up to an hour are a restart, causing communications issues (e.g. LSL chat) across region borders. It is not intended to address the issue of diagonally adjacent regions not being visible to one another (SVC-8130).

Release Candidate (RC) Channels

On Wednesday 26th June, all three RC channels (Magnum, BlueSteel and LeTigre) should receive a new server maintenance package, comprising:

  • A fix for ‘llApplyImpulse now works only in the root prim’ (SVC-8227)
  • Crash mode fixes
  • New LSL function: string llXorBase64(string str1, string str2)
    • Returns a string that is a Base64 XOR of Base64-formatted input strings, str1 and str2.
    • Addresses the cases from SCR-35 “llXorBase64StringsCorrect returns wrong result when the 2nd string contains nulls”
    • Aside from those cases, this function behaves identically to llXorBase64StringsCorrect()
  • Added max_materials_per_transaction to /simulator/features cap
    • This number returns the maximum number of materials that can be sent to the “RenderMaterials” capability in a single request.

SL Viewer

General

With the release process yet to switch-over to the new system, the following viewer updates were made in week 25:

  • The SL beta viewer saw an additional release – 3.6.1.277611 on June 21st. This primarily included some fixes for the version of the viewer which is offered via Amazon for download, and rendering fixes
  • The Snowstorm Contributions Test Build viewer was updated to the 3.6.1 code base (version 3.6.1277577, June 20th, for details of the current contributions in the viewer, follow the link). This would appear to be the first step in merging-up a series of third-party viewer contributions which are liable to see a project / beta viewer release after the new viewer release process comes into use.

Viewer Release Process

Commenting on progress with the upcoming new viewer release process at the Open-source Dev meeting on Monday 24th June, Oz Linden said, “We’re in the final verification stages. Might even get it turned on this week.”

As a side note, and In preparation for the new process, I’ve revamped my Viewer round-up page to (hopefully) better reflect the fact that we should be seeing a broader spread of viewers being put out by LL. This is a work-in-progress, and the page may evolve further as the new viewer release mechanism comes into force. Similarly, the weekly summaries produced from this page are also being revised ready for the new release process.

Materials Viewer

Despite issue with the materials viewer, there are a number of content creators already working on products which leverage the new capabilities. At the Open-source Dev meeting on Monday 24th June, Whirly Fizzle pointed people towards the work of Chip Midnight, who has been working on a mesh avatar using materials properties.

Chip Midnight's mesh avatar model (click to enlarge)
Chip Midnight’s mesh avatar model (click to enlarge)

Whilry also supplied a link to  a thread on the SL Universe forums where Chip discusses the avatar. For those interested, it’s worth following the discussion for the next couple of pages – particularly Drongle McMahon’s reply to Chip on the subject of specular and gloss maps.

Continue reading “SL projects update week 26 (1): server, viewer, materials” →

SL projects update 25 (3): Nyx Linden announces SSB/A “imminent”

Posted on by Inara Pey

A note card containing a message from Nyx Linden is doing the rounds in-world concerning Server-side Baking / Appearance. The note card reads in full:

Greetings all,

Nyx Linden (stock)
Nyx Linden (stock)

Wanted to give everyone a quick update on the status of Server Side Appearance. First of all, thanks to all who helped participate in last week’s pile-on test, and a special thanks to those viewers who are already integrating the RegionHandshakeReply flag posted recently. We’ll likely be doing one more pile-on next week, targeting a smaller set of users (to avoid inventory limits that have caused attachments not to load, etc) next week. Let me know if you’d like to participate.

We currently are not aware of any major release-blocking bugs and are starting to look at scheduling the roll-out process. We have a number of QA passes and tests to run through before we can get the final greenlight to do so, so we are currently targeting July 9th as the earliest date at which we will enable SSA for a significant portion of the grid (a server RC channel). Please note that if we find additional bugs in the meantime, or run into other scheduling difficulties this date could be pushed back. We will not be going to RC before this date however.

Please consider this an official warning that this is imminent – We’ve been saying for a while that we’re getting ready for release. We hope with a solid date in mind, all viewers can start messaging to their users that they will need to update or they will start to see issues. There are a few methods by which we will be messaging to the SL community as a whole about this, but we highly encourage you to use your judgement in the best way to reach out to your users and transition them to SSA-compatible viewers.

As always, if you have any questions, or see any issues that could be worrisome if they are not fixed before release, please do not hesitate to reach out to me and/or file a JIRA. Thanks for all your work in preparing for this release!

Nyx Linden

[link and all emphasis mine]

If you want to avoid seeing increasing numbers of grey avatars and / or avoid people telling you, "you're a cloud" when you appear perfectly fine to yourself, update to a version of a viewer supporting SSB/A
If you want to avoid seeing increasing numbers of grey avatars and / or avoid people telling you, “you’re a cloud” when you appear perfectly fine to yourself, update to a version of a viewer supporting SSB/A

As previously noted in this blog, the plan from the Lab has been to deploy SSB/A gradually. Speaking on this at the TPV Developer meeting on Friday June 14th, Nyx indicated the deployment would be a small group of regions prior to moving to a Release Candidate channel (either in whole or in part) and then progress from there.

However, with the preliminary date for this work to commence, and given that almost all maintained SL viewers are now SSB/A-ready (Dolphin and Exodus are the only exceptions at the time of writing), there really is no excuse for people not to update their viewer. The choices are arleady available:

  • Those who prefer the v1-style of UI have the choice of Cool VL Viewer and Singularity
  • Those who prefer the V3-style have the choise of the SL viewer, Catznip, Firestorm, Kokua, Niran’s, and RLV.

In addition, the Lumiya, Meltabolt and Radegast clients are also SSB/A ready.

With thanks to mona Eberhardt