Tag: Materials Processing

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 (2): server, materials

Posted on by Inara Pey

Update June 21st: A new Materials Support and Tips thread has been started by Creator Linden in the Building and Texturing Forum (with thanks to Daniel Voyage for the poke).

Server Deployments – Week 25

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

Second Life Server (Main) Channel

On Tuesday June 18th, the SLS main channel received the interest list improvement project which have been previously deployed to Magnum (week 22) and BlueSteel and LeTigre (week 24).

Release Candidate (RC) Channels

On Wednesday 19th June, all three RC channels (Magnum, BlueSteel and LeTigre) received the same server maintenance package, designed to fix a number of crash modes and address an issue with neighbouring region visibility. In addition this package:

  • Contains the new LSL pathfinding property CHARACTER_STAY_WITHIN_PARCEL, and the new LSL object return functions designed to assist land owners with the return of objects under controlled conditions
  • Provides fixes for A fix for an issue in which LSL HTTP-in scripts would sometimes see the incorrect URL (BUG-2833) and for Bug 2850 (Cannot rez objects in Bluesteel and LeTigre parcels which disallow object entry).

The neighbour region visibility issue fixed by the deployment 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, rather than being related to the issue of diagonally adjacent regions not being visible to one another (SVC-8130), which is still an issue on the main grid.

The fix deployed to the Release Candidates does not address issues of diagonally-adjacent regions failing to render to one and/or the other
The fix deployed to the Release Candidates does not address issues of diagonally adjacent regions failing to render to one and/or the other

Commenting on the latter issue while testing it with an alt during the Server Beta meeting on Thursday May 20th, Maestro Linden said, “It looks like some kind of false communications timeout in the remote region, where it disconnects your viewer.” Currently, there is no proposed fix for the issue, although the Lab keep poking at it.

Materials Processing

matbug-715-a
Objects using transparencies as rendered with ALM off in the materials viewer (click to enlarge)
matbug-175-b
The same items rendered with ALM active in the materials viewer (click to enlarge)

The Materials Processing project reached a release status on Wednesday June 19th, with the release of Second Life viewer 3.6.0.277516.

However, problems continue to be reported with transparencies rendering as black when using the viewer, (see MATBUG-175, MATBUG-193 and a similar bug, MATBUG-186).

Two possible workarounds for these problems have been suggested, which may work, depending on the precise nature of the issue, if you’re experiencing it:

  • Going into Preferences > Graphics and unchecking Advanced Lighting Model (ALM) before click OK to apply, then going back into Preferences > Graphics and enabling ALM once more
  • If you have water reflections set to Minimum in Preferences > Graphics, try setting them to a higher value and then unchecking / rechecking ALM.

Some of these issues were known well in advance of the viewer reaching a release status, which promoted comments of surprise during the Open-source Developer meeting on Wednesday June 20th that the viewer had been released. Commenting on this, Oz Linden responded:

I’m not at all surprised that people found combinations of visual attributes we hadn’t tested that were busted, really. There are a staggering number of combinations – after you factor in all the possible settings changes on top of them, the number is absolutely not even close to something we could test. The “black issue” makes it sound simple…. we probably had a dozen bugs during development that had that same symptom for different reasons. I’m sure we’ll get it sorted out.

Continue reading “SL projects update 25 (2): server, materials” →

Materials Processing reaches SL viewer release status

Posted on by Inara Pey

Update June 21st: Kokua version 3.6.0.28975 has been released, which include Materials Processing support.

Update June 20th: NiranV Dean has released a version of his “in development” Black Dragon SL viewer with Materials Processing support. See his blog post for details.

Further to the first part of my SL projects update for week 25, materials processing has now officially reached release status with the release of viewer 3.6.0.277516.

If you are already running the release version of the viewer (3.5.3.276452) and have automatic updates enabled, the new version of the viewer, you should be notified that the update is available. If not, or if you have not previously installed the SL viewer, but wish to try-out the new materials capabilities, you can download and install 3.6.0.277516 by following the above link to the official download page.

A katara showing detail created by the use of materials properties
A katara  created by June Dion showing surface detail and reflective qualities using materials properties

For those not in the know, Materials Processing adds normal and specular maps to the in-world tools capabilities of the viewer (using the new land impact accounting system in the process!), allowing much higher / improved levels of realism be obtained with textures used on prim, sculpt and mesh items (they do not work on avatar skin and clothing layers).

I provided an overview of the Materials Processing, including brief notes on normal and specular maps when the project reached a beta viewer release status at the start of June, and I refer you to that post for details.

As noted in that article and elsewhere, the materials capabilities introduce a revised Textures tab to the Build floater in the viewer, which allows you to add normal and specular maps to objects and object surfaces, as well as textures (referred to a diffuse maps).

Materils Build floater Texture tab: The diffuse (texture) option, showing the Alpha mode drop-down options (l); the normal map options, with map picker and default bump map drop-down (c); the specular map options, in which the Shininess drop-down displays the familiar low, medium & high shiny options (r)
Materials Build floater Texture tab: The diffuse (texture) option, showing the Alpha mode drop-down options (l); the normal map options, with map picker and default bump map drop-down (c); the specular map options, in which the Shininess drop-down displays the familiar low, medium & high shiny options (r)

Note, as well, that in order to see materials in action, you’ll need to enable the Advanced Lighting Model option in the Graphic tab of the materials viewer. Please also see the Materials FAQ for other information relating to Materials Processing.

Given the capabilities are now available in the release viewer, and allowing for pressing activities around Server-side Baking / Appearance, it is likely that we’ll start seeing more TPVs start to adopt materials in the coming weeks (for example, the Cool VL viewer already has materials support in the experimental branch).

In the meantime, the Lab has released a video demonstrating the capabilities, complete with a Torley Dancing SL10B bear!

Materials Processing represents a collaborative project developed and implemented by both Linden Lab and third-party viewer developers. Originally a proposal submitted by members of the Exodus viewer team in 2012, the project has included the direct involvement of developers from Catznip (notably Kitty Barnett) and Firestorm (notably Tonya Souther) as well as from Exodus (notably Geenz Spad) in the development of the viewer-side tools and capabilities, with the Lab working on the server-side of the capabilities.

If you encounter any major issues with the viewer, such as alpha issues, severe problems with texture rendering as black, etc., please make sure you file a JIRA on the issue, with any screen shots you can provide in addition to details of your system (Help > About Second Life > COPY button to copy / paste system information).

Related Links

SL projects update 24 (5): viewer news: SSB/A, upcoming releases

Posted on by Inara Pey

Server-side Baking / Appearance

SUN-74 – Asset Corruptions With Non-SSB/A-enabled Viewers

I’ve recently reported on the issue of BUG-74 in relation to server-side baking / appearance. This affects some non-maintained viewers which do not have SSB/A support and which might result in some worn modify assets (skin, hairbase and eyes) being corrupted  – see here for details. The issue was finally repro’d successfully by the Lab in week 23. Since then, investigations have been ongoing.

Commenting on the situation during the TPV Developer meeting on Friday 14th June, Nyx Linden said, “we have a technical solution for SUN-74. I have tested it against 1.23[.5], and the old behaviour is no longer reproducing. So hopefully that will mean that once we get it in a place where we can test against Phoenix there should be no more asset corruption.”

Nyx Linden (stock)
Nyx Linden (stock)

It’s not clear when this will happen, but it seems likely the updates will be deployed to the “closed beta” regions where TPV testing of the SSB/A code has been ongoing for the last couple of weeks, and tests will be taken there to ensure non-SSB/A viewers will not be negatively impacted when moving between SSB/A-enabled and non-SSB/A regions during the initial deployment of Server-side Baking / Appearance.

However, this does not mean that people on older, non-maintained viewers no longer need to update to an SSA/B-compatible viewer.

Regardless of the fix for SUN-74. people on non-maintained viewers will start to see increasing numbers of grey avatars around them as SSB/A is rolled out, and will find that others see them as a permanent cloud. So the only way to be sure of being ready for the deployment of SSB/A is – update or upgrade your viewer if you have not already done so.

Additional Viewer Patch

A side effect of the work carried out on this issue is that the Lab will also be producing a small viewer-side patch which is not any kind of “bug fix” for SUN-74, but which will help viewers get their own appearance messages “just a little bit faster” than is currently the case.

While TPVs are encouraged to incorporate the patch once it becomes available, it is not seen as a mandatory requirement ahead of SSB/A being enabled on the main grid. As such, TPVs have been encouraged to integrate the patch once it becomes available and as it best fits their own release schedules.

Grid-wide Deployment

When asked about how the Lab plans to deploy SSB/A server-side at the TPV Developer meeting on Friday June 14th, Nyx replied:

Carefully. Definitely carefully. We are doing a lot of testing, and as most of you know, we’re doing an Agni pile-on [see later in this report] … and we have been doing a lot of load testing and we’re pretty confident we have enough hardware on the back-end to handle the load.

[So] We’re going to start with a small group [of regions] and go to an RC channel, and then more, and then take over the entire grid.

Whether “go to an RC channel” means enabling SSB/A across an entire RC channel (Magnum, BlueSteel or LeTigre) or enabling across a portion of regions on the selected RC channel is currently unclear. That decision doesn’t rest with Nyx, but will be dependent upon on number of factors including how well the initial steps in the deployment go.

In light of things like the pile-on test (see the next section) and readying the SUN-74 patch, the Lab remains unwilling to commit to specifying a date by which SSB/A deployment might be expected to start. This is understandable as there is still no guarantee that further issues such as SUN-74 won’t be uncovered as a result of either the pile-on test or as a result of further closed beta testing, which the Lab continues to monitor.

Main Grid Pile-on Test

On Friday 14th February pile-on test was conducted across a number of regions which had been specifically set-up to stress test Server-side Baking with some “real world” avatar numbers. Some fifty or so people turned up for the tests using various viewers with Appearance debugging enabled, including a version of the official viewer which had been pre-set with debugging enabled. The test was in three parts:

  • Baseline testing on regions using the current avatar baking mechanism
  • Testing on regions in the Snack RC channel running a version of the SSB/A code
  • Testing in the “closed beta” region specifically set-up for TPV testing running the SSB/A code

The precise differences between the code on the Snack regions and the code on the TPV test region (the Testylvania Sandbox). Questions were asked in open chat, but the nearest answer which seemed to be given was that the Testylvania region was the one the Lab “cared about the most”.

Testing on the current baking mechanism saw familiar issues of slow clothing / skin rendering and the need to use manual rebakes to try to encourage non-blurred appearances. Things appeared to be a lot better on the SSB/A-enabled regions (I personally experienced no issues in changing skins / clothing layers and found rendering of both fast and error-free, for example). However, some did report issues with rendering, and filed JIRAs / provided log files as a result.

There were multiple reports of attachment rezzing failures as of the asset service coming under pressure as a result of so many outfit / look changes going on simultaneously and in rapid succession. Whether these will see further work undertkaen on the inventory system (some work has already been carried out in a wider context by the Sunshine team), remains to be seen.

Expect more on the tests once LL have had time to chew on the data gathered and review the logs of those who did encounter issues.

Continue reading “SL projects update 24 (5): viewer news: SSB/A, upcoming releases” →

SL projects update 24 (1): Viewer news – materials, SSB/A, deformer, snapshots

Posted on by Inara Pey

Update: In further tests of the FIRE-9097 “fix” at lower resolutions (e.g. 2650 pixels across), I found it can re-introduce the tiling artefacts in snapshots.

General Viewer News

Materials Processing

The release of an update to the materials beta viewer on Wednesday June 5th (3.6.0.276961) was followed at the weekend by the arrival of a further beta version – 3.6.0.277049 – with accompanying release notes. Commenting on the rapid-fire releases, Oz linden said at the Content Creation User Group meeting on Monday June 10th, “We’re getting close to the end of its beta cycle (or put another way… report your bugs now).”

Snapshot Issues

We’re all aware of the snapshot tiling issue which plagued SL photographers for a good while, which would leave “tiling” artefacts on images taken at higher resolutions than the user’s monitor resolution when running in deferred mode (now known as Advanced Lighting Model). A fix for this issue (MAINT-628) finally reached the public in late 2012, but brought with it some additional issues. On of the most notable of these was the appearance of black rectangles in very high resolution images.

Very high-resolution "black rectangle" issue common to viewers utilsing the MAIN-628 "tiling" fix (image courtesy of Dil Spitz)
Very high-resolution “black rectangle” issue common to snapshots taken with viewers utilsing the MAIN-628 “tiling” fix (image courtesy of Dil Spitz)

This latter problem most recently caused an additional outcry when the LL “tiling” fix was finally incorporated in Firestorm viewer earlier in 2013, with many users incorrectly blaming the Firestorm team for the problem.

Well, for all and sundry, Firestorm users or otherwise, there is some potentially good news on the horizon.

Firestorm image artefact fix: image at 6000 pixels across, saved as JPG (click to enlarge)
Firestorm image artefact fix: image at 6000 pixels across, saved as JPG (click to enlarge)

Commenting on the broader issues reported with snapshots duing the Open-source Dev meeting on Monday June 10th, Oz Linden said:

It looks like there are fixes in the MAINT pipeline for those. I don’t know how soon those will be out… I can try to find out if they have a project build ready.

Additionally, there is further news specifically for Firestosm users. While it is somewhat outside the scope of “SL project news”, it is neverthless reporting here.

Nicky Dasmijn has been working on the problem, and has implemented a fix for the issue (see Firestorm JIRA FIRE-9097), which should correct matters for snaps of up to 4096×4096 pixels without any “rectangle” artefacts appearing or with any regression to issues of tiling, and which may work at high resolutions than that for some.

tile-test-6K_001
Firestorm image artefact fix: image at 6000 pixels across, saved as PNG – note rectangle artefact (click to enlarge)

I tried a very rough-and-ready test of the fix. I found that capturing images up to 5,000-5,600 pixels across with the aspect ratio maintained worked OK for me. Anything around 6,000 pixels across saw JPG images save OK, but rectangle artefacts begin to appear when saving in PNG (see both images on the right)

However, as I’ve recently been experiencing other GPU issues, I’ve been unable to ascertain if the rectangles are down to an issue with the code or simply a matter of my GPU running out of resources when processing PNG images above 5600 pixels across.

The fix is currently in a recent Firestorm pre-release, and will hopefully make the cut for the next formal release. It is currently unclear whether the code has been / will be contributed to LL, and if so, whether they will adopt it or opt to go with their own forthcoming updates (as indicated by Oz in his statement above) or opt to combine it with their own fixes (depending on the nature & scope of the latter).

Future “STORM Project Viewer” Release

There are a number of code contributions which have come via the Snowstorm route which have been queued awaiting a suitable release. These cover a range of additions to the viewer, and example of which is STORM-68 (As a Builder, I want that ability to set default permissions on creation of objects, clothing, scripts, notecards, etc.).

Commenting on STORM contributions in general, and in light of the forthcoming changes to the viewer release process, Oz said, “I’m trying to get all the storm issues merged up so that I can be ready to put out a project viewer as soon as the new viewer version manager is deployed.” Whether STORM-68 (which is apparently seen as “largely good to go”, although it may also require a server-side change), or the fixes for snapshot issues mentioned above will be among them remains to be seen. However, a “STORM” project viewer could well be adding even more features to the SL viewer in the near future.

Continue reading “SL projects update 24 (1): Viewer news – materials, SSB/A, deformer, snapshots” →

SL projects Update 22 (3) SSB/A issue update, upcoming viewer releases

Posted on by Inara Pey

Server-side Baking / Appearance

Yesterday, I reported on the SUN-74 issue (Apparent avatar skin and eye texture asset corruption with Server Side Appearance), which can impact users with avatars wearing modifiable skin and/or eyes and/or hairbase who enter (via teleport or crossing a region boundary) an SSB/A-enabled region while using a non-SSB/A enabled viewer (e.g. such as Phoenix or the v1.23.5 viewer) and leave them with a corrupted copy of the worn skin / hairbase or eyes. At the time I noted that the matter was under investigation by Linden Lab, and no decision had been made on how to handle it.

Whirly Fizzle demonstrates the result of the SUN-74 issue
Whirly Fizzle demonstrates one aspect of the SUN-74 issue – on a non-SSB/A viewer, her MOD skin has turned black / invisible and her MOD eyes have turned white as a result of entering an SSB/A-enabled region and responding with YES to the given prompt.

Speaking at the TPV Developer meeting on Friday May 31st, Oz Linden provided an update on the issue and spoke more generally on the issue of the use of olfder (non-SSB/A capable viewers) going forward:

We don’t actually know what’s ultimately going to be done about that; that’s a subject of vigorous discussion that’s going on even as we speak, so we’ll see how that plays out. I think it’s fair to say that regardless of what happens with that particular issue … I will just make the observation that there are still people really, really old viewers [and] there is no way, no way at all, that we could even begin to test for compatibility back with all of those viewers.

As it is, as recently as this last week there were 1,665 different viewer version strings reported as connecting to the main grid (these include 151 versions of Singularity, 50 versions of Phoenix, 262 labelled as Firestorm, and so on). Some of these may be “one offs” self-compiled builds (which may or may not have the most recent updates to support something like SSB/A), but even so, given the overall number of viewer strings, it is understandable why the Lab view attempt to ensure so many different viewer versions were fully compatible with anything on the grid is a next to impossible task.

This does not mean that the Lab is going to ignore SUN-74, right now they are still investigating the problem and trying to reproduce it in a consistent manner (which is apparently proving difficult for a number of reasons, not the least of which is that some older viewers simply crash when attempting to repro the corruption). However, what it does underline is the need for people to upgrade to an SSB/A-enabled version of their preferred viewer sooner rather than later.

The reason for this is that very soon the Lab will start undertaking more widespread testing of the new service by enabling it across a number of regions across the grid. These regions may not necessarily be constrained to any of the usual RC channels, but could well be a mix of regions from all of the various simulator channels, making them harder to identify and avoid. This testing will be to gain greater insight into how the service stands up under “real avatar loads” – something which is impossible to carry out to any great depth on Aditi, as there simply isn’t the volume of users active there.

Once this more widespread testing starts, then it is entirely possible that users who remain on non-SSB/A capable viewers are going to encounter issues and problems beyond seeing grey avatars which the Lab are not going to address, simply because the issues can be resolved by a viewer update.

So the word really is, update, update, update.

Continue reading “SL projects Update 22 (3) SSB/A issue update, upcoming viewer releases” →