Category: 2013 Project Updates

SL projects update week 17 (1): Server releases, SSB/A, particles

Posted on by Inara Pey

Server Deployments – Week 17

SLS Main Channel

On Tuesday 23rd April, the SLS Main channel received the update package deployed to the three Release Candidate channels in week 16, primarily comprising the new server-side LSL Animation Override capabilities, complete with a fix for BUG 2164, wherein the new capabilities could conflict with built-in animation poses in chairs, etc., as discussed in my week 15 updates.  This deployment additionally includes the slight region performance improvement when there are no pathfinding characters present. Release notes are available.

Release Candidate Channels

On Wednesday 24th April, the RC channels should receive the following updates:

  • BlueSteel and LeTigre: should gain a new project which brings preliminary server-side support for experience permissions – release notes
  • Magnum: should gain a new server maintenance project.  This update brings some new minor features to LSL, and fixes some crash modes – release notes

So the long-awaited experience tools / advanced content creation tools permissioning system looks to be finally on its way, a little under a year since an exploit caused them to be withdrawn after their initial deployment.

Viewer Updates

Development Viewer Updates

The SL development viewer has been through a rapid series of updates over the last few days of week 16 and the start of week 17, with version 3.5.2.2744 released on Monday April 22nd. While release notes are not available, it is thought it includes (among other things), the fix for music stuttering every few seconds when using FMOD EX, as submitted to LL by Latif Khalifa  (see OPEN-173).

Particle Project Viewer Soon (?)

It appears a new particle project viewer may be on the horizon in the near future. If it does appear, it is likely to be primarily aimed at testing a new capability to help deal with griefing attacks which use particle emitters. Speaking at the Simulator User Group meeting, Simon Linden said:

We’re doing some testing and may get a project viewer out, which would allow you to test it and (I believe) let other viewers check out the source code. This is right-click on a particle, and it kills the generator … We’ve tossed around a few ideas about blocking particles in other ways but definitely want to get these first steps out the door.

This sparked further discussion on ways and means to help stop particle griefing, which has been on the increase across the Mainland of late. However, given that particles are a viewer-side effect, “stopping” them is actually easier said than done from a server-side perspective. One idea which gained some interest, if it is feasible, would be a block of any particle emitters belonging to an avatar banned from a region / parcel.

In the meantime there are means of stopping the viewer from rendering all particles – such as CTRL – Alt – Shift – +, or going to Preferences > Graphics > and dropping the Particle Count slider to zero. These again only work in your own world view, and while not always ideal, do present an option.

Asked if such a particle project viewer might include the new LSL particle capabilities already deployed server-side, Simon could only say, “Hopefully yes … I’ve been working on getting that chunk of code solid for the last few days. Unfortunately it’s pretty easy to crash at this point and so it’s not ready for consumption.”

The particle ribbon effect  is a particle which repeats the texture horizontally, and can follow the object creating them, which offers a lot of potential uses, as which forms a part of the new particle capabilities – soon to be seen within a project viewer? – Time will tell.

Server-side Baking / Appearance

The viewer-side code for SSB/A is starting to appear in more TPVs:

  • Cool Viewer has had SSB/A support in the “Experimental” branch for a while, and this moved to the “Stable” and “Legacy” versions on April 20th – see the Cool VL website and release notes
  • Singularity released version 1.8.0 with SSB/A support on April 21st, which I’ve reviewed
  • Firestorm released version 4.4.0 with SSB/A support on April 22nd, which I’ve reviewed
  • Kukua has had an experimental / development version since the start of April (version 3.5.1) which also incorporates SSB/A.

The status of the SL beta viewer with the SSB/A code will take place around the middle of week 17, when a decision taken as to whether to incorporate the code into the SL release viewer or run a further beta release. The expectation is that the code will move to the release channel unless a last-minute significant issue is found within the code which prompts a further run in beta.

Assuming the code does make it to the release channel, it is likely that a release viewer will appear early in week 18 rather than late week 17, due to the time required to test and QA a build.

SUN-72 – Fix Submitted

One issue which is known to exist within the current beta release of the SSB/A viewer code and which has caused considerable problems is SUN-72 – if you have inventory items with special characters (including the likes of asterisks) in their names, they will fail to load. Similarly the use of accented characters (e.g. such as René) in things like chat log path names, the logs are not saved.

Nicky Dasmijn of the Firestorm team developed a patch for this specific problem which is already incorporated into the recent Firestorm 4.4.0 release, and which has been contributed to, and accepted by, the Lab for integration into the SSB viewer code. Hopefully, it should be appearing in the next SSB viewer release, whether beta of SL release viewer.

Sun-38 – Avatar / z-offset

As noted in my last major update on SSB/A, the ability to offset an avatar’s height on-the-fly to accommodate various animations (e.g. kneeling), or to adjust an avatar’s height when sitting / walking of floors, etc., and which will effectively be “broken” as reported in  SUN-38, remains an issue for many.

While the Lab have produced an alternative approach which addresses some issues around avatar height offset using new appearance sliders, and which Nyx Linden and others have been continuing to tweak, there is no solution on the horizon for maintaining any form of on-the-fly adjustment; nor does the proposed solution work with no-mod shapes, as noted when I first  reported on the “fix”.

During the Content Creation User Group meeting on Monday, April 22nd, a request was made for the Lab to not shut-down the existing baking service until such time as  SUN-28 is “solved”, which prompted Nyx to comment:

SUN-38 is not currently considered a blocking issue for our initial release. It’s on our list to investigate, but we don’t have a patch or update immediately. There is a new hover parameter, which should work for attachments that affect your avatar, but the bug reported is also discussing the need to adjust the offset on the fly without changing wearables. Having both the new and the old system enabled is not an option … We are investigating options, but it is not a hard requirement for the initial release.

Continue reading “SL projects update week 17 (1): Server releases, SSB/A, particles” →

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

SL projects updates Week 16 (3): server, viewer, and Aditi summaries

Posted on by Inara Pey

Server Deployments week 16

  • On Tuesday April 16th, the SLS Main channel received Monty Linden’s HTTP updates, which were deployed to BlueSteel and LeTigre in week 15, after having previously been on Magnum for testing – release notes
  • On Wednesday April 17th, the three Release Candidate channels (BlueSteel, LeTigre and Magnum) all received the same package after a planned deployment to BlueSteel and LeTigre had to be abandoned due to scheduling issues. The package deployed included the new server-side LSL Animation Override capabilities, including a fix for BUG-2164 wherein the new capabilities could conflict with built-in animation poses in chairs, etc., as discussed in my week 15 updates. The Magnum release are linked to for reference.

Following the SLS Main channel deployment there were a number of reports of significantly higher ping rates with regions being reported on the deployment thread, which prompted Monty Linden to comment, “There was a significant networking event today that has cleared.  Back to normal at this point…” Other than this, and reports of animation issues, which again may have been the result of server-side work, the deployments appear to have rolled-out smoothly and without significant issue.

SL Viewer Summary

Materials processing: the project viewer gained a further update on April 17th, with the deployment of release 3.5.1.274082, which includes bug fixes and some work on alpha masks. The bug fixes are hard to relate to public MATBUG JIRA items, as they all reference NORSPEC issues, which is LL’s internal materials JIRA reference. A further update to the project viewer is anticipated on either Friday 19th April or Monday, April 22nd.

Materials porject viewer: second update now available, third update to follow soon.
Materials project viewer: second update now available, third update to follow soon.

Server-side Baking / Appearance: speaking at the OpenDev meeting on Wednesday 17th April, Oz Linden indicated that SSB will have at least “one more spin” in the beta viewer before appearing in the SL release viewer. A further update was made to the SL development viewer (3.5.2.274273) on Thursday April 18th, so the beta update is liable to be appearing very shortly.

Further viewer updates: once SSB moves to the release viewer, it is likely that the FMODex update will move into the beta viewer; this should also include a fix for the issue with the Mac version of the viewer wherein it crashes whenever headphones are unplugged (and which, incidentally, is the most widely reported crash issue with the Firestorm viewer).

Aditi Issues

While Aditi has received attention recently in order to overcome logging-in and inventory issues, it still as a way to go before everything is “fixed”. Commenting on this at the Beta Server meeting on April 18th, Monty Linden commented, “[The] beta grid is going to get some attention in the login/inv area. But [I] don’t have a date. The problems are (mostly) understood.”

The password-change-to-update-your-Aditi-inventory might be changing as things are looked at and further updated / corrected. Commenting on this at the Beta Server meeting as well, Simon Linden said, “That trigger was done as a quick-and-easy way to stop having to ask a Linden to import your account.”

In discussing the asset system and inventories, Simon re-iterated that while there is a central asset system, it is really one very large storage system, and that, “The real magic isn’t the asset system, it’s your inventory database. Your inventory is what says which assets are yours.” It is syncing the inventory databases between Aditi and Agni which had become an issue, and also somewhat labour-intensive for LL but for the password change trigger.

Monty, with tongue firmly in cheek, suggested an alternative as to how the inventory / asset system works: “Inventory is recorded onto Post-ItTM notes and optically scanned at rez time.” Which, on reflection, is likely to confirm suspicions many have had!

Other Items in brief

Monty Linden
Monty Linden

HTTP Work

The next round of HTTP work is still being defined within the Lab. When asked what this might comprise, Monty replied, “Mesh download is going to get attention. It currently shotguns our services without really performing well.”

He went on, “Might do an experiment or two with pipelining. – but no promises, still setting priorities.”

It is the last remark which is important: things are still being decided in terms of further work and priorities where HTTP work is concerned. This was further underlined again by Monty when he indicated that “phase 3” of the work (the immediate follow-on to the last block of work) may well be “all viewer-side”, given that the initial work (texture fetching) was primarily viewer-side work and the last batch of work was exclusively server-side. So this appears to be a case of wait and see which route he and the Lab opt to take.

Advanced Creation Tools Permissions

July saw the launch of the first phase of the Advanced Creation Tools, also referred to as experience tools. Following problems with an initial deployment of the tools in June, which resulted them being exploited as a means of griefing, the “first phase” of the release saw the tools implemented with existing permissions system in place, with the intention of updating the permissions system to allow the tools to be more fully used “in the future”. Work on the new permissions system was stalled for a number of months, but has recently been getting more attention and work. The current situation appears to be that the permissions system may well be ready, but those working on the project are still, “sorting out how and when that’s going to be made available.”

Diagonal Region Rendering Issues

While fixes have been deployed to assist with issues with regions sometimes taking a long time to correctly handshake and cache with one another following a restart, this issue of regions which are diagonally opposite one another sometimes failing to render remains. Simon Linden had indicated that a potential fix for this issue was with QA as long ago as week 8; however it appears that the work may have hit problems or actually be stalled. In replying to a comment on the forum deployment thread relating to the issue, Maestro Linden replied with a simple, “Correct, that bug has not been fixed”.

No fix yet; status unclear
No fix yet; status unclear

 

SL projects update 16 (2): Server releases; region crossings

Posted on by Inara Pey

Second Life Server (Main) Channel Week 16 Deployment

On Tuesday April 16th, the SLS Main channel received Monty Linden’s HTTP updates, which were deployed to BlueSteel and LeTigre in week 15, after having previously been on Magnum for testing.  These updates can be briefly summarised as:

  • More complete and more correct headers on texture and mesh fetches – these should ensure the viewer is better able to handle objects as they are downloaded to it
  • Keepalive connections for some HTTP-based services

For more details on the project, please refer to both the deployment release notes and to my overview of Monty’s work.

 Second Life Release Candidate Week 16 Deployment

On Wednesday 17th April, all three RC channels should receive the same update package. This comprises the server-side LSL Animiation Override capabilities, this time complete with a fix for BUG 2164, wherein the new capabilities could conflict with built-in animation poses in chairs, etc., as discussed in my week 15 updates.  This deployment additionally includes the slight region performance improvement when there are no pathfinding characters present. Release notes are available

Originally, a separate package had been in preparation for deployment to BlueSteel  / LeTigre, but this has had to be postponed due to “last minute scheduling issues”, according to Simon Linden when speaking at the Simulator User Group meeting on Tuesday April 16th. While attempts were apparently being made to get an alternative project into RC, it was “down to the wire to complete testing” at the time of the Simulator UG meeting, and an announcement confirming BlueSteel and LeTigre would receive the same package as Magnum was posted to the deployment thread not long after the meeting finished.

Object Return from Region Edge

A further update which should reach all three RC channels on Wednesday April 17th is the fix for https://jira.secondlife.com/browse/BUG-313 (estate tools do not return objects between 255 and 256m ) / https://jira.secondlife.com/browse/BUG-2021 (Auto-return not affecting objects at 256m), which see objects right on the region edge sometimes slipping into a “limbo” which prevented them from being returned either under Auto-return or when using estate tools.

There is some concern that the fix, once deployed, may not correct all issues. However, until it is deployed, there’s no actual way of knowing – so further updates may well be following.

Region Crossings

Since the deployment of the fix for BUG-1814 making region crossings in vehicles has been seen as noticeably better by many people. However, some have noted problems which appeared to be linked to crossings between regions running on different simulator versions, and this was discussed at length at a recent Simulator User Group meeting.

Kitto Flora suggested the problem was not so much with different simulator versions, but due to network traffic, commenting, “It’s directly related to your Net traffic rate when you cross. If its 500k – fail maybe 20% of time … If its 50k it rarely fails.”

While I have been flying extensively over the past week, particularly over Blake Sea and the south-lying regions and over parts of Nautilus, I’ve not been monitoring net traffic during my flights – although I do reduce Draw Distance when flying and tend to shunt graphics quality down to medium-low – so cannot comment on Kitto’s observations. I can however state that when I did encounter problems beyond the expected temporary loss-of-control  / rubber-banding – such as my camera skewing off to once side of my aircraft as shown below – it always coincided with a move between one simulator version and another, and never between regions on the same simulator version. So I guess more test and observations are due on my part after this week’s deployments!

Flight testing region crossings: when moving between regions running on different simulator versions, I invariably encountered greater issues (such as the camera being shunt, as shown above) than when crossing between regions on the same simulator (note the chat console reports, lower left and notifications. top right).
Flight testing region crossings: when moving between regions running on different simulator versions, I invariably encountered greater issues (such as the camera being shunt, as shown above) than when crossing between regions on the same simulator (note the chat console reports, lower left and notifications. top right).

The discussion on region crossings raised additional questions. One of these was whether or not the speed one crosses between regions made any difference. Simon Linden replied:

Your speed in-world shouldn’t have any effect on actually making it or not, but faster crossings will show the errors in predicting where objects will be more. Such as the rubber band effect when crossing … your viewer sees you going a certain speed, and keeps moving you that way, while you hit the crossing, get some lag as the data is transferred to the new region, and you’re stuck into the world, then sling-shot back to the new position. 

Questions / comments were also raised around the subject of region crossings and idle regions: specifically whether crossing into an idle region was subject to additional delay as the region “woke up” and that some have experienced issues with regions which are apparently idling being unresponsive to new child avies, and people “bounce” off the border prior to being able to cross. Responding to both the question and the comments, Simon said:

You actually shouldn’t ever be able to do that. It won’t be idling if you can see into it … Also, remember idle regions are not dead, they [are] just are running at a slower frame rate, just like loaded down regions do.

Missing Prims

There are currently no updates on the “missing prims” situation which has been previously reported in this blog, and which has grown markedly more apparent since the last set of interest list updates.

Andrew Linden was not at the Simulator User Group meeting on Tuesday April 16th to discuss either, but is almost certain to be asked at the Beta Server meeting on Thursday 18th April, if he attends.

Related Links

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.

SL project updates week 15 (2): Materials, AO capabilities and group bans

Posted on by Inara Pey

Server Deployments Week 15

  • As reported in the first part of this week’s update, there was no Main channel deployment on Tuesday April 9th, the result of issues arising with the previous week’s RC deployments, which LL wanted to fix rather than having them propagate across the grid
  • Magnum retained the same package as week 14 (Monty Linden’s next batch of HTTP updates) and a fix for a crash mode
  • Continuing issues in getting the anticipated updates for the BlueSteel and LeTigre deployment packages ready meant that on Wednesdays April 10th meant that these two channels received the same package as the Magnum RC channel.

The switch-out with the Magnum code being deployed to BlueSteel and LeTigre meant that those regions “lost” the new LSL Animation Override capabilities – existing scripts using the capabilities will still run, but new scripts using the functions cannot be compiled.

Materials Processing

Viewer Update and Documentation

Discussing the materials project at the Open-source Development meeting on Wednesday, April 10th, Oz Linden indicated that an updated version of the project viewer should be available shortly – possibly by the end of the week, as  “lots of fixes are accumulating”. In the meantime, a mixture of Linden Moles and volunteer users are working on materials-focused updates to go into the Good Building Practices guide to help other users get to grips with materials processing and optimising things for SL use. In the meantime, the Materials Data information on the SL wiki continues to be updated.

As pointed out by Mona Eberhardt in the comments relating to materials in this blog, Laverne Donat has produced a very tidy and short demonstration of materials in SL, which I’m including here.

Alphas, Transparency and Costs

Laverne also asked, via Plurk, if and how a specular map can have transparency with the materials processing, before going on to comment (via my blog) that, “After some testing, it seems that you can get specularity with diffuse maps with alpha masking, but not with diffuse maps with alpha blending. I don’t know what the intended behaviour is, but that’s how it works at present.”

This prompted Geenz Spad to reply, “The intended behavior (eventually) is that alpha blended objects will be able to support both normal mapping and specular mapping. Currently this is a work in progress, and due to its current state, it hasn’t been added to the viewer just yet.”

As Alpha Blending is currently the Alpha Mode which is unaffected by the materials / LI accounting situation which has been reported by Qie Niangao, I asked Geenz if Alpha Blending was liable to “trip over” into the LI accounting system, rather than being “grandfathered” (as currently appears to be the case). He further clarified the situation by replying, “Only if you use other material parameters (such as specular mapping, normal mapping, etc.). The only reason why we didn’t add support for shiny on all semi-transparent surfaces, is because it would break content.”

Future Development

In terms of future development, it is unlikely that anything will be happening soon, other than enhancements / fixes for what is currently in the project viewer. While there is a roadmap for future features and additions to the materials system, the Lab is wisely not commenting on plans and direction at this time. Rather, they prefer to see what the overall take-up with the new system is over time and how people start using it (which may in turn affect how and what the Lab decides to do with regards to a “materials round 2”). However, one thing which does appear to be clear is that there are no plans within the current roadmap to extend materials processing to include avatar skins and clothing layers.

AO Capabilities Update

New server-side AO capabilities: udpates delayed until week 16
New server-side AO capabilities: updates delayed until week 16

Although it did not get deployed in week 15 (but should see the light of day in week 16, commencing Monday, April 15th), the update to the new AO capabilities which should have reached BlueSteel and LeTigre is intended improve compatibility between the new animation override system and other scripted objects that animate avatars (such as poseballs). The update was developed as a result of Code Violet raising a JIRA (BUG-2164) pointing out that the new capabilities did not “play nicely” with things like sit animations in poseballs / furniture.

Maestro Linden, speaking at the Best Server meeting on Thursday, April 11th, described the situation thus:

If a user had a custom ‘sit’ animation set, the seat wouldn’t be able to stop the animation properly because if the seat called llGetAnimationOverride(“Sitting”), it would get an empty string unless the exact animation also happened to be in the seat’s inventory. Kelly has a nice solution to this problem, which is to make ‘llStopAnimation(“sit”)’ stop your custom animation, if you had overridden your sit animation. Conveniently, this change means that existing poseballs won’t need any updates to play nicely with the new AO system.

The Beta Server meeting saw some discussion on the new AO capabilities, which enabled Maestro and Kelly Linden to offer further clarifications.

Continue reading “SL project updates week 15 (2): Materials, AO capabilities and group bans” →