Tag: Materials Processing

SL projects update week 19 (1): server releases, SSB/A, materials

Posted on by Inara Pey

Server Deployments Week 19

Second Life Server (Main) Channel

On Tuesday May 7th, the Main channel should receive the maintenance package which has been running on Magnum. This project brings some new minor features to LSL, and fixes some crash modes and well as additional LSL HTTP support – release notes.

 Release Candidate Channels

On Wednesday May 8th, all three Release Candidate channels (BlueSteel, LeTigre and Magnum) should receive server-side support for experience permissions which was running on BlueSteel in week 18. The update, as usual, will also include the changes which are going to the Main channel on May 7th – release notes (BlueSteel).

I was somewhat confused by the release notes for 13.05.04.275247 package, as on the one hand they suggested the new LSL AO capabilities would be absent from Agni following the RC deployments (“Changes since 13.04.19.274370 … Removed changes introduced by Second Life Server 13.04.12.273874”), while on the other, the line originally following this comment suggested otherwise.

I contacted Maestro for clarification, and he confirmed that the AO capabilities will be present on the RC channels following the deployment, and that the release notes have been revised to prevent any further confusion.

As always, there is a discussion thread in the forums for the deployments.

Server-Side Baking / Appearance

SSB/A - further viewer-side updates expected. No published timeline on testing as yet
SSB/A – further viewer-side updates expected. No published timeline on testing as yet

As noted in the last part of my week 18 report, there will be at least update to the viewer-side SSB/A code, which Nyx referred to at the Content Creation meeting on Monday May 6th as being, “Mostly reliability and some related polishing”. From the TPV Developer meeting on Friday May 3rd, the release will be addressing some additional ways in which baking can fail as well as addressing stability in general, although as Nyx noted at the TPV Developer meeting, “Nothing that we know of right now that would be mandatory for the system to work.”

The question of when constrained testing would commence again came up at the Content Creation meeting. This will see a number of regions across the main grid have the server code for SSB/A enabled in order for LL to carry out further load tests on the system ahead of the “switch being thrown” and SSB/A enabled across the entire grid. All Nyx would say on the matter is, “We don’t have a timeline to announce today.”

Whether this means there will be a formal announcement when testing does commence, remains to be seen. However, the Lab is still intending to make a formal announcement on SSB/A, mostly likely via a blog post, ahead of the service being enabled across the grid in the hope of further communicating the change, and the need to upgrade to an SSB/A-capable viewer to as many users as possible.

Outfit Changes

During her tests with SSB/A on Aditi, Kitty Barnett noted that when changing a wearable or reordering the layers of an outfit, the updated bakes could take a while to come through. Concern that this might be the case when SSB/A is enabled on the main grid prompted her to ask:

For server-side baking, would there be any issue with turning on local baking to make getting dressed more pleasant? it could be Aditi, but [when] wearing something it takes a very long time before the server bake comes through, particularly reordering clothing or taking something off … I actually just turn local baking on as soon as there’s a wearable change and it seems to be working nicely and turns itself off when the server bake comes through… but I was wondering if that would cause any undesirable issues [if the same was done on Agni]?

Local bakes already occur when using the Editing Appearance options, so Kitty’s question appears to be more broadly aimed at general outfit changes (people simply swapping individual clothing layers directly from inventory, and (possibly) using the capability in some TPVs to re-order clothing layers directly from inventory, rather than going via the appearance editor).

Responding to the question, Nyx said:

I’m not certain how you’re turning on local baking, and can’t really speak to whether there are undesirable behaviors as a result. The code to switch between the different types of bakes is rather complex and sometimes fragile, and bugs in that area can be subtle … Proceed with caution and best of luck :). Report back if it works well (or if you find interesting bugs!)

Whether such a delay will be noticeable enough to be an irritant on Agni is hard to say as we’ve yet to see the server code up and running on the main grid, so it’ll be interesting to see what further tests on Kitty’s part reveal as testing commences.

Continue reading “SL projects update week 19 (1): server releases, SSB/A, materials” →

SL projects update 18 (4): servers, viewer release process, group bans and bits

Posted on by Inara Pey

Server Deployments – Week 18

As reported in the first part of this update, the SLS Main channel was rolled back to release 13.04.05.273580, as a result of a widespread performance issue.  This unfortunately saw the removal of the new LSL animation capabilities from the channel.

The issue itself is related to problems with regions locating their neighbours. “The sim were hitting the [region presence lookup] service too hard, causing stability problems.” Maestro Linden said at the Server Beta meeting on Thursday May 2nd. Release notes.

In the original notes for this week’s deployments, BlueSteel and LeTigre were scheduled to receive the same deployment package. However, this was subsequently changed so that:

  • BlueSteel received the same reversions as the Main channel due to the performance issue between neighbouring regions, but also received updates for the Experience Keys project as originally planned. Release notes.
  • LeTigre received the same code that was on the main channel in week 17, the only difference being that it fixes the performance issue that caused the Main channel to be rolled back this week.  Release notes.

Maestro described the deployment of the fix for region lookup issues as the “conservative option”, rather than deploying the fix to multiple Release Channels, “In case the changes from the other two channels have their own problems.”

Magnum received the package originally scheduled for it, described as bringing some new minor features to LSL, and fixes some crash modes as well as the fix for grid performance issue, and fixing an issue in which llDialog() messages sent to the object owner could be incorrectly throttled. Release notes.

The hope is that if all is well with the Magnum update, it is liable to be deployed to the Main channel in week 19.

SL Viewer Updates

Beta Viewer Release

A new beta version of the viewer emerged on May 2nd, using the 3.5.2 code (3.5.2.275087). This release includes the update from FMOD to FMOD Ex, and well as a number of other maintenance and other fixes as specified in the release notes.  However, it does not include the anticipated Vivox updates to improve SL Voice. These will be coming along at a later date.

The current plan is for this release to remain in the beta channel for at least one further update prior to it appearing in the release channel. As such, it is unlikely to be in the release viewer until late in week 19 or in week 20. Once it has appeared in the release viewer, LL will probably deploy the new viewer release process, and the beta channel will cease being used.

Viewer Release Process

Oz Linden
Oz Linden

As previously reported, the viewer release process will be changing in the coming weeks. As a part of this, the development viewer channel has already been deprecated; however it will still be a while before the new process is put into place, as further infrastructure changes are still required on LL’s part.

Concerns have been raised by TPV developers about a side-effect of the new process potentially being that the rate at which code becomes available to them may slow down, thus causing them to “fall behind” the LL viewer in terms of new functionality or capabilities. Stressing that this is not the intent, Oz Linden described process in further detail at the TPV Developer meeting, indicating that under the new system:

  • Viewer projects will each have their own repositories, which will be made available to TPVs (and others) once it is deemed they are “safe to share” as a project or “beta” viewer
    • While it has yet to be formally decided within LL, and may take a little time to work up to, critical bug fixes are liable to have their own repositories, from where they can be merged into other viewers
  • Users will be able to pick which beta / project viewer(s) they download from the Alternate Viewer wiki page without being tied to any specific update route (so you can download and run as many project / beta viewers as you like)
  • Once a project is believed to be of release quality, it will be put into a release candidate, built on the current viewer release code and released to a target number of users (as chosen by LL), alongside other release candidates being used by other users
  • When a user receives a release candidate viewer via the download page, the updates they receive will be offered on the basis of the release candidate they are currently running (for example, if a user is running the Materials RC viewer, they won’t be offered updates from, say, the SSB/A RC viewer)
  • After some period of time, and when LL have looked at the results, one of the release candidates will be promoted to the default download (without the viewer having to be rebuilt) and will be available on the main download page
  • The remaining viewer projects (at least those at release candidate status) will then be merged with the newly-released viewer code, and re-test and issue a further release candidate, which may in turn be selected as the next candidate for promotion to the default download.

He added that in terms of TPV’s concerns over code being made available to them, the level of co-operation which has been evident in the Sunshine project (SSB/A) has “not gone unnoticed” within LL’s management, and that the team involved has received a lot of kudos for the way they have handled interaction with TPVs. As such, it is likely that the Lab will endeavour to build on this going forward.

Continue reading “SL projects update 18 (4): servers, viewer release process, group bans and bits” →

SL projects update week 18 (1): viewer, SSB/A and materials

Posted on by Inara Pey

Server-side Baking / Appearance

The viewer-side SSB/A code continued in the SL beta viewer with a release on April 24th (3.5.1.274588). However, the crash rates from that version were sufficiently low for the go-ahead to be given for the deployment of the SL viewer with the SSB/A code incorporated, which reached public release on April 30th (3.5.1.274821).

SSB/A in the SL release viewer: I'm running the SSB/A-enabled SL release viewer and can see both myself and my alt (running SSB/A-enabled Firestorm) rendered correctly, and she can see fully rendered.
SSB/A in the SL release viewer: I’m running the SSB/A-enabled SL release viewer and can see both myself and my alt (running SSB/A-enabled Firestorm) rendered correctly, and she can see fully rendered.

This now means that the following viewers and clients are, at the time of writing, now SSB/A capable:

  • SL viewer 3.5.1.274821 (release)
  • Firestorm 4.4.0.33270 (release)
  • Kokua 3.5.2.27969 (development)
  • Nirans 2.2.0.2692 (alpha test)
  • Cool VL 1.26.8.2 (stable release)
  • Kirstens S19.1.19.4 (unsupported)
  • Singularity 1.8.0.4114 (release)
  • Lumiya 2.4.4 (release)
  • Metabolt version 0.9.66.0 (Beta)
  • Radegast 2.12 (release)

The remaining major players for Second Life – Catznip, Dolphin and Exodus will doubtless have SSB/A versions out in the very near future.

Z-offset

Cinder Roxley is working on an alternate approach to the issue of the z-offset and is meeting with some success. However, there is still a problem with the distance offset being inconsistently reported between the user’s viewer and by other viewers (so the avatar may appear at a different height above ground / an object when seen by others in comparison to how they see their own height. Cinder is continuing to work on the problem. If she is successful, the code will doubtless be made available to all TPVs should they wish to adopt it.

Current Outfit Folder Corruption

I reported on this issue in week 17, wherein a Current Outfit Folder (COF) corruption can leave a user unable to log-in to SL and – unless they have a Premium account – beyond official help. This has been something of a longstanding issue, as per JIRA SVC-7653, and has an associated work-around. The concern here is that the workaround will no longer work once SSB/A is enabled server-side.

Commenting on the situation, Nyx Linden said, “we’re looking into a number of fixes around COF for followup releases,” before going on, “Yep, we have people looking at this. Please do continue to let us know as you see cases come up. I’ll sync up with our engineers looking at this and make sure that we have these cases covered.”

SUN-69

Whirly Fizzle recently reported an issue arising from the recent SSB/A code – removing any worn item from avatar results in all temp attachments being taken off (see JIRA SUN-69). This problem occurs whether or not an avatar is on SSB/A regions. It was first noted in the SL development and beta viewers, but appears common to all viewers with the SSB/A code, including the new release version of the viewer referred to above (3.5.1.274821).

Server-side Deployment

With the arrival of the viewer SSB/A code into the SL release viewer, deployment of the server-side code is liable to commence on the main grid. As previously noted in these updates, the plan is for a “constrained” number of regions on Agni to be SSB/A-enabled in order to load test the system. It appears likely that these regions will not be a part of the normal Release Candidate channels (although this is not absolutely clear).

The purpose of this action will be to further stress / load test the new server-side baking service and (hopefully) ensure there is sufficient hardware deployed to support the capability and that there are no unexpected issues arising from large numbers of people starting to the use the system.

Continue reading “SL projects update week 18 (1): viewer, SSB/A and materials” →

SL projects update: week 16 (4): More on SSB, materials and FMOD Ex

Posted on by Inara Pey

Server-side Baking / Appearance

Viewer Releases

An updated beta viewer was released on April 19th (3.5.1.274264, with release notes here), which contains a range of updates, including several for SSB/A. Speaking at the TPV Developer meeting on Friday, 19th April, Oz Linden indicated that the current plan from the Lab is that this is likely to be the last beta viewer release for the SSB/A code unless a major blocker shows up. Assuming this doesn’t happen, then it is more than likely the SSB/A will move to the SL viewer release channel and arrive as a viewer update towards the middle of week 17 (week commencing Monday, 22nd April), which should hopefully be an automated update for most users on the SL viewer, given the majority appear to keep that option active on their viewers.

Given us, it is liable that we’ll start seeing more TPVs updates appearing in the near future – and people using TPVs are going to need to start installing and using those updates rather than remaining with older versions of their viewer if they are to avoid the “grey people” syndrome as the server-side of SSB/A is deployed.

Users will need to update to version of their preferred viewer supporting SSB/A as they are made available to avoid seeing grey people
Users will need to update to a version of their preferred viewer supporting SSB/A as they are made available if they are to avoid seeing grey people once the deployment of the server-side of SSB/A commences

Server-side Deployment

The precise means by which the server-side will by deployed is still not absolutely clear. As noted a number of times in this blog, Nyx Linden is hoping that things will progress somewhat cautiously, possibly starting with a set of “carefully selected and constrained regions on Agni” as the viewer code reaches the SL release viewer. This still appears to be the case, but it is possible that it will not – as Nyx has previously hinted – roll through the Release Candidate channels.

“I don’t know whether it will go through the normal RC process,” Oz Linden commented at the TPV Developer meeting, “Because it’s not actually a server software change; it’s a configuration change, so they don’t need to deploy it through the RC progression. All they have to say is, ‘Yes, throw the switch!'”

If this approach is taken, it’s currently not clear whether or not it will require a region restart.

In terms of time frames as to when this might happen, things are similarly unclear at this point – a lot depends on how well the testing on the selected Agni regions progresses. However, Oz suggested that the time frame in which the “switch may be thrown” to be anything between 2 and 6-8 weeks from when the viewer-side code appears. His analogy was that of a bell curve, wherein the switch-over could occur at the top of the curve – but could, if circumstances dictate, occur at either end of the curve.

Communications

It is still hoped that there will be a concerted effort on the Lab’s part to communicate server-side baking ahead of any server-side flipping of switches. A blog post is apparently in preparation, which should go out when the SSB/A code is issued in the release viewer; whether this will be supported by other means of communicating the changes is unclear.

However, communications on the whole is not easy – even with the TPVs also liable to be spreading the word through blogs, etc., (as Firestorm have already). This is because even with the official blog, TPV blogs and blogs such as this one, the vast majority of SL users do not read blogs.

Matters are also further complicated by the fact that there are over 1700 different viewer strings which are used to connect to SL (even if not on a daily basis). These not only include the official viewer and current versions of TPV-registered viewers, but also many instances of older versions of TPVs, Snowglobe (1.x) based viewers, several versions of the official 1.x viewer (some of which date back over 5 years), viewers which are not registered with the TPV directory, self-compiled versions of various viewers, and so on.

As such, whatever the effort made to communicate the arrival of SSB/A is liable to be missed by a good number of users and people are going to find themselves facing grey avatars as a result of the switch to SSB/A, because many of these additional viewer strings will not have the necessary viewer-side code. This inevitably means that there is going to be some disruption and upset. While this in turn doesn’t mean that attempts to communicate the coming change shouldn’t be made – but it does mean that even with the best efforts of the Lab and TPVs combined in communicating SSB/A, there is going to be an outcry. So anything all those who are aware of the upcoming changes can do to communicate it to others – particularly when there is a visible log post from LL on the matter which can be referenced – can only help lessen the volume of that outcry.

Continue reading “SL projects update: week 16 (4): More on SSB, materials and FMOD Ex” →

An OpenSim material(s) girl

Posted on by Inara Pey

Those of us who spend the majority of our time in Second Life are just starting to get our heads around materials and opportunities it presents for enhancing mesh, prim and sculpt builds and attachments. Now OpenSim may not be that far behind, as Marcus Llewellyn commented on this blog, and has himself explained on Bearly Written, where he tells us:

Dahlia Trimble, one of the core developers of OpenSimulator, has begun work on a module that gives OpenSim support for new materials on prim, sculpt, or mesh builds. The module that enables it is really more of a demonstration right now; it has issues setting materials, and they will only persist until a region is restarted …. Still, it’s a start, and an exciting one!

The work is still at a very preliminary point right now, as Marcus points out, with the server-side code still very much in its infancy. The work is also hampered by the fact that the only viewer currently capable of rendering materials is a project viewer from Linden Lab which isn’t actually intended to be connected to OpenSim (due to Havok licensing restrictions). However, this latter aspect should change once the code reaches a point where it is suitable for merging into third-party viewers.

Both of these point mean that there is still much more work to be done – but Dahlia, with assistance from Marcus himself and Nebadon Izumi has made a good start on things, and the simulator code is already available for those who want to give it a go or help-out with the work.

Marcus has more information on the project over on his blog, and I refer you to him for a good overview of the project. IN the meantime, here’s a video of Dahlia’s work. Kudos, Dahlia!

Related Links

With thanks to Marcus Llewellyn

SL projects update week 16 (1): SL viewer, materials, SSB and other bits

Posted on by Inara Pey

SL Viewer Updates

There’s no movement on the release viewer, and likely won’t be until Server-side Baking moves to it, having finally arrived in the Beta viewer on April 12th (see below). The Development viewer was also updated on April 12th, with the release of version 3.5.2.273873, which includes both SSB and CHUI updates.

Materials Project

An update to the materials processing project viewer was released on Friday April 12th – 3.5.1.273855 – with a series of bug fixes included in it. There are further updates on the way, with the next release due around the middle of week 16, which will have further bug fixes and, hopefully, some Alpha mode updates as well. Commenting on the latter at the Content Creation User Group on Monday April 15th, Geenz Spad said, “Actually just got normal maps working on alpha blended objects, and trying to get everything else working on them as well.”

One fix currently pending is that for MATBUG-16, Changing one material, or setting causes another material texture to be lost. This is an issue which can happen as a result of several factors. For example, setting a normal or specular map for one face of an object can result in maps already applied to other faces of an object either being removed or replaced with the most recently added map. The same issue can occur when applying a setting such as glossiness to one face of an object using materials.

MATBUG-16 demonstrated using 2 deiffuse maps and their associated normal maps. (l) the prim with a diffuse map added to one face & with the "stone" normal map still showing for all faces. (r) the normal map add
MATBUG-16 demonstrated using 2 diffuse maps and their associated normal maps. A prim previously set with a stone diffuse map and associated normal map has a green diffuse map applied to one face – the normal map is unaffected (l). However, when the normal map is updated, it changes for the entire prim (r)

This problem doesn’t happen every time mixed materials elements are used on object faces, but can occur when adding multiple materials elements to an object in quick succession. “There are a couple of problems there,” Oz Linden said while discussing the problem at the Open-source Dev meeting on Monday, April 15th. “The updates to the server are happening faster than it will allow, which is one problem. The other is that the updates are not applied locally as smoothly as they should be.”

Tonya Souther, who re-worked the Build floater for materials processing added, “Yeah, that bug has been driving me batty ever since I first did the UI. And I think that’s due to the design of the system…the UI has to ask the server for the material separately, and apply the values retrieved from it to the UI components when they arrive. That ‘s the only way that the UI won’t get out of sync with the actual values stored on the server … I just need to find a way to make the delay not apparent to the user and handle changes that come along in that period.”

For now, the answer seems to be that if you experience any issues with normal / specular maps vanishing or being replaced when using multiple maps / effects across different faces of an object, then allow a short pause between adding the various maps / effects so the viewer and server can keep pace with your work.

Elsewhere, Geenz Spad, one of the architects of the materials processing system, has started a new blog series on materials, Second Life Materials:  A Content Creator’s Guide. In the first part of the series, he answers the question, What’s a material? In the next installment, he promises to take a look at some of the tools which can be used to create normal maps.

Server-side Baking

The viewer Server-side Baking /Appearance code reached the Beta viewer in week 15 with the release of 3.5.1.273869 on April 12th. The initial stats apparently show it is doing well, crash-wise, but the status of incoming bugs is currently unclear. However, it still looks as if the code is currently on course for around a two-week stint in the beta viewer prior to moving to the release viewer channel.

A key bug fix for the system has been SUN-57, which now allows multiple layer of clothing to be worn / swapped on regions which are not running the SSB server-side code (on Aditi), which removes a potential road block from server-side code deployment (remembering that for a time during the server-side deployment, updated viewers must support both the old and new avatar baking services).

The SUN-57 issue, as defined by Whirly Fizzle: left - Outfit A from her My Outfits folder replaces whatever she was previously wearing, and appears correct; centre - after a relog, she repalces Outfir A with Outfit B, and again, everything appears correct; right - she replaces Outfit B with Outfit A, but her skin fails to bake correctly, the head and legs showing the skin associated with Outfit A, the torso still showing the skin from Outfit B (shown naked for clarity) - images courtesy of Whirly Fizzle / JIRA SUN-57
The SUN-57 issue, as defined by Whirly Fizzle, which saw issues occurring in avatar baking using a viewer supporting the upcoming “new” SSB/A service and changing outfits on a region only supporting the current avatar baking process, which saw outfits and skins failing to update correctly following changes. Reportedly now fixed

There are still no definitive timescales for any Agni deployment for SSB/A. As previously reported in this blog, it is still unlikely that any major deployment operations will commence prior to the SSB cove reaching the release viewer.

Other Items

I recently blogged about Oculus Rift and  speculation as to whether it would see use in Second Life. On April 7th, Jon Brouchoud blogged on why SL would be a “killer app” for the headset – an article which has seen widespread reprinting / referral in SL / Opensim related blogs. While I have no particular opinion either way as to Oculus Rift / Second life (although how it will work with the SL UI does intrigue me), I have to admit the following video demonstrating Oculus Rift had me smiling from ear-to-ear. It’s not really related to Second Life, but it is well-worth watching.