Category: SL Tech

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.

Firestorm 4.4.1: It’s time to update

Posted on by Inara Pey

firestorm-logoUpdate July 2nd: version 4.4.2 has been released by the Firestorm team, and Firestorm 4.4.1 has been blocked from accessing Second Life. If you have previously installed Firestorm 4.4.1, you can install 4.4.2 without needing a clean install. If you are updating from Firestorm 4.4.0 or earlier, a clean install is strongly recommended. The downloads can be found on the Firstorm website.

Firestorm 4.4.1(.34164) arrived as a release on Thursday June 27th. This is another major update to SL’s most widely used TPV, and one which all Firestorm users should update to sooner rather than later.

The reason for this latter comment is one which should be familiar to anyone who regularly reads this blog – Server-side Baking / Appearance (SSB/A) is a-coming.

Subject to final confirmation, the Lab plans to start deployment of the server-end of the capability on July 9th, and while it might take a while to encompass the entire grid, it will mean that anyone using a pre-4.4.0 version of Firestorm is going to start seeing increasing numbers of grey avatars around them as they travel the grid and (quite likely) finding themselves being told they are a cloud when seen by others.

Updating sooner rather than later will also greatly assist those volunteers who give up copious amounts of time to help with the in-world Firestorm Support groups. Right now, the Firestorm team estimate more than 77,000 users are still running versions of Firestorm older than 4.4.0, and thus have no SSB/A capabilities. It’s going to be impossible to supply all of these users with support and advice if they all leave updating their viewer until the 9th July or later – so please, if you are reading this review and you are using a version of Firestorm older than 4.4.0, consider updating now.

Doing so means that should you need to contact the Firestorm support team directly, because you are encountering problems and cannot find help through the Firestorm wiki or the troubleshooting index, you’ll be far more likely to receive a timely response to your request for assistance.

Even those who have updated to 4.4.0 should make the move to 4.4.1, as it includes the very latest updates and fixes for the SSB/A code from LL. Outside of SSB/A, release 4.4.1.34164 offers a number of important fixes for 4.4.0, and so it’s again important for 4.4.0 users to step up to 4.4.1 to gain these benefits.

As always, there is a lot to cover in a Firestorm release, so I’m not going to plough through everything here – the official change log provides a breakdown of all updates and fixes. Instead, this review focuses on what I regard as the key updates / changes. As always, credits for the various updates and contributions to Firestorm which are mentioned here can be found in the release change log – again, please check them there.

What is NOT in this Release

I’m actually going to start with what is not in the 4.4.1 release. It does not include the following major updates from the Lab:

  • The Communications Hub User Interface
  • Materials Processing

The reasons for this are simple. For one thing, the Firestorm team have been largely focused on fixing issues and problems with Firestorm and on getting the viewer ready for the SSB/A release. This  left them with little time to get changes resulting from the CHUI release by LL integrated into the viewer, although considerable work has been carried out in refactoring the code.

Similarly, there is no Materials Processing capability included with this release. This is in part because the Lab themselves have only recently moved the materials code to a release status (and it still has a number of very visible bugs associated with it), but mostly because changes made to the viewer as a result of the introduction of CHUI affect files which are also changed by the materials project. It is therefore important that the Firestorm team implement the changes in the same order – changes as a result of CHUI first, then the materials changes.

So those wanting to use materials in Firestorm are, unfortunately, going to have to wait a while longer.

New Features and Improvements from the Lab

Note these also include work by the Firestorm team arising from LL-development viewer updates.

  • “Missing prims fix” – MAINT-2647 / BUG-2116 / FIRE-8950 – this should hopefully resolve the majority of issues around prims / linksets failing to render in the viewer until an action such as right-clicking on them or toggling atmospheric shaders off / on is taken
  • Merge up to 3.4.5 codebase plus cherry picked fixes plus server-side appearance support improvements
  • Major under the hood refactoring in preparation for the CHUI merge
  • Added RegionHandshakeReply flags for Server-side Appearance – a fix for the SUN-74 issue.

Snapshots Fixes

Firestorm 4.1.1 includes an interim fix for the issue of black rectangles appearing in snapshots taken at very high resolutions. Note that this fix is not the recently released additional fixes arising from MAINT-628 made by Linden Lab. These fixes will be included in an upcoming release of Firestorm, and so the current fix should be considered interim.

Communications Updates

Radar can now be accessed via its own button / menu option / floater for those who prefer not to access it via the People floater. The new button can be selected from the Toolbar Buttons floater, which will open the new Radar floater. Additionally, Radar can be accessed via World > Radar from the menus.

The new Radar floater (left) and optional Toolbar button, compared to Radar as it appears in the Nearby tab of the People floater
The new Radar floater (left) and optional Toolbar button, compared to Radar as it appears in the Nearby tab of the People floater

The Radar retains all functions found when displaying it in the Nearby People floater, including the ability to display the mini-map within it.

The Payment icons on the Radar / Nearby People floaters have also been updated: $ indicates the user has Payment Information on File; $$ indicates Payment Information Used.

For those who use the Friends list (Comm > Friends or CTRL-SHIFT-F), highlighting a person’s name in the list and then tapping ENTER will start an IM conversation with that person (no need to click the IM button).

For those who use Growl, dialogue messages and inventory received from object messages are now displayed with Growl. In addition, all Growl preferences check boxes will only be enabled if Growl is installed on the user’s system.

Navigation Updates

Beacon distances are now shown for the
Map beacon ranges now show the distance from the avatar, not the camera

Firestorm 4.4.1 removes the 2-second delay when using the click-to-teleport functions or teleport chat shortcuts (gtp, etc.) or the Teleport To function in Radar.

A new option allows region grid coordinates to be displayed on the World Map (Preferences > Move & View > Firestorm > Show grid coordinates on the world map), which OpenSim users might perhaps find more beneficial than most SL users.

Also, map beacon ranges now show the distance from the avatar, not the camera.

Continue reading “Firestorm 4.4.1: It’s time to update” →

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” →

Viewer release summary 2013: week 25

Posted on by Inara Pey

This summary is published every Monday and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:

  • It is based on my Viewer Round-up Page, a list of  all Second Life viewers and clients that are in popular use (and of which I am aware) and which are recognised as adhering to the TPV Policy
  • By its nature, this summary will always be in arrears
  • The Viewer Round-up Page is updated as soon as I’m aware of any releases / changes to viewers & clients, and should be referred to for more up-to-date information
  • The Viewer Round-up Page also includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog.

Updates for the week ending: June 23rd, 2013

SL Viewer

SL Viewer Resources

Third-party Viewers

Additional TPV Resources

Depreciated / Discontinued Viewers

  • SL Development viewer – depreciated as of version 3.5.2.274629 April 24, 2013
  • Zen Viewer – discontinued by developer and no longer available, January 27th, 2013
  • Phoenix viewer – development and support ended on December 31st, 2012

Related Links

Kokua catch-up

Posted on by Inara Pey

kokua-logoKokua 3.6.0.28975 was released on Friday 21st 2013, joining the in-development Black Dragon viewer (NiranV Dean) in becoming one of the first v3-style viewers to fully adopt Materials Processing.

I’ve been remiss in my coverage of Kokua’s development, which has been fairly steaming along over the last several months (the last update I gave was for Kokua 3.4.4 in January 2013), so this piece is a little bit of a catch-up on some of the major updates – such as SSB/A support – since then, starting with the 3.6.0 changes.

Straddling Worlds

Despite all the hoo-haw over the Lab’s move to sub-licence code libraries from Havok (a move which was incorrectly interpreted by some as being an attempt to stymie OpenSim), Kokua is one of the viewer which continues to happily straddle the SL / OpenSim divide by providing capabilities which work in both, as well as options specific to one or the other (such as SSB/A support for SL, and enhanced OSSL support and the ability ro disable SL’s build constraints for OpenSim use, for example).

Accepted onto the Linden Lab Thirty-party Viewer list in April, and listed in the Third-party Viewer Directory, Kokua avoids the Havok complication by providing pathfinding support without the navmesh visualisation capabilities (potentially no great loss to the vast majority of users) and by using the third-party mesh upload code for importing mesh objects, thus allowing it to comfortably span both environments.

3.6.0 Download and Installation

The Windows installer weighs-in at 36.3 MB, putting it towards the upper end of the installer list by file size, which is hardly surprising given the punch of extras the viewer includes. Installation itself was, for me, straightforward, the viewer neatly over-writing my previous version (I opted not to go my usual clean install route).

Firing-up the viewer yielded no anti-virus warnings from AVG Pro (which has recently being getting a little vociferous over SLplugin.exe of late with some viewer installations, despite having given it a pass in previous installs – the most recent flag going up with my installation of the latest SL viewer with materials support).

The current Kokua message of the day (MOTD) – coming from LL – raised a smile, using a little humour to underline the fact that SL users need to update their viewers.

A light-hearted reminder of the need for SL users to update to an SSB/A-ready viewer
A light-hearted reminder of the need for SL users to update to an SSB/A-ready viewer

Materials Processing Support

The release of Kokua 3.6.0 marks it as the first v3-style viewer to provide full viewer-side support for materials processing in for Second Life (if you’re on OpenSim, there are server-side updates required to make materials capabilities work, but there is already a preliminary effort to get these implemented).

The updated Texture tab of the Build floater
The updated Texture tab of the Build floater

If you’re not sure what materials processing means, please take a look at my primer provided for the SL viewer’s beta release.

As one would expect, materials support has been implemented as it is presented through the SL viewer: the Texture tab in the Build floater has been updated to provide support for normal and specular maps, which can be selected from a high-level drop-down (see right), and which include their own additional attributes (the “old” Bump and Shine options). Note that each materials map can be set with independent repeats and rotations.

Materials also includes some additional updates – the most noticeable of which is perhaps the ability to include an alpha mode when working with alpha masks. This can be set to one of:

  • None –  the alpha channel is ignored, rendering the face opaque, or
  • Alpha blending – essentially the same as we currently have for any alpha texture, or
  • A 1-bit alpha mask with each pixel either 100% transparent or 100% opaque, with a cutoff setting to determine where the threshold is (alpha masks should render faster than alpha blending, and eliminate issues with alpha layer sorting), or
  • Emissive mask – so the alpha layer is interpreted as a per-pixel glow setting.

Materials support also includes gamma correction capabilities within the rendering system. This may cause scenes to render more darkly than in non-materials capable versions of Kokua, and as reported with the SL viewer, may cause some alpha rendering issues.

Graphics Updates

Materials Processing has seen various other changes made to the viewer to improve rendering, some of which have resulted in improvements to the GPU support table, and adjustments made to the graphics defaults themselves. While these may have been included in versions of Kokua prior to 3.6.0, they’re covered here for completeness.

Graphics tab changes in Preferences and water reflections
Graphics tab changes in Preferences and water reflections

First and foremost, the Quality and Speed slider now has seven pre-sets instead of four, adding mid-point settings between Low and medium, medium and high, and high and ultra. These are designed to better reflect the capabilities of supported graphics cards and to determine whether or not a card has the ability to support materials rendering by default (whether you actually want it to do so is up to you). As such, you may find that if you’ve not updated Kokua in a while, your default graphics setting is different from previous versions.

The other notable change (again, if you’ve not updated Kokua in a while and haven’t been following SL viewer changes over the last few months) is that the “lighting and shadows” check box has been renamed “Advanced Lighting Model” (ALM), and the option needs to be checked in order for you to see materials capabilities being rendered in your viewer.

Finally, and purely by way of a side note, if you enable ALM in SL and find you’re having  issues with alphas rendering correctly with this release of Kokua (they appear entirely black), try changing Water Reflections (arrowed above) to anything other than Minimal. This may help resolve the issue for you. Another possible workaround for the “black alpha” problem is to disable ALM, click on OK to accept and close Graphics, then re-open Graphics and re-enable ALM.

Command Menu, Build Floater Updates and Look AT Options

The 3.6.0 release also sees a new Command menu implemented, which brings together those commands moved from other menus, popular commands and a number of chat commands imported from Firestorm and turned into menu options (such as “tp2cam” to teleport to your current camera location).

Additionally, the Build floater’s Object tab gets a port of the build parameters copy paste function from the (now defunct) Zen viewer as its implementation was newer than other LGPL licensed viewers, and which is completed with fine tuning tweaks from Firestorm.

Continue reading “Kokua catch-up” →