Category: SL User Group Meetings

SL projects updates 22/2: LSL functions for materials avialable for Aditi testing

Posted on by Inara Pey

Maestro Linden used the Server Beta meeting to announce that Simon Linden’s work on adding some LSL support for materials is now available for testing on Aditi.

Regions roller-test102 and roller-test103, both on channel DRTSIM-253, have the server-side scripting support (note the SLurls are for ADITI).

Please note that this is very much a work-in-progress, and the Lab’s own testing is still underway.

The following details can also be found on the Server Beta Meeting wiki page.

LSL fucntions for handling materials
Parameters have been added to the llSetPrimitiveParams() and llGetPrimitiveParams() functions to enable scripted control of materials maps

Materials can be added to object faces with llSetPrimitiveParams() functions using the following parameters:

  • [PRIM_SPECULAR, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
  • [PRIM_NORMAL, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians]
  • [PRIM_ALPHA_MODE, integer face, integer alpha_mode, integer alpha_cutoff]
    • Valid alpha_mode options are PRIM_ALPHA_MODE_NONE, PRIM_ALPHA_MODE_BLEND, PRIM_ALPHA_MODE_MASK, PRIM_ALPHA_MODE_EMISSIVE

Materials can be read with the various llGetPrimitiveParams() functions using the following parameters:

  • [PRIM_SPECULAR, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
  • [PRIM_NORMAL, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians]
  • [PRIM_ALPHA_MODE, integer face] returns [integer alpha_mode, integer alpha_cutoff]

Additional Notes

  • Behaviour for both getting and setting materials parameters should basically correspond to behaviour with PRIM_TEXTURE
  • The color vectors use 0.0-1.0 as the range, as with llSetColor()
  • The integer parameters for PRIM_SPECULAR correspond to the same values that you see in the build tool
  • Components of a material can be ‘reset’ as follows:
    • PRIM_NORMAL and PRIM_SPECULAR settings are set to default values by setting the texture to NULL_KEY
    • PRIM_ALPHA_MODE settings are set to default values by setting the alpha_mode to PRIM_ALPHA_MODE_BLEND – mask_cutoff is actually reset to 0 unless the alpha mode is PRIM_ALPHA_MODE_MASK
    • When PRIM_NORMAL, PRIM_SPECULAR, and PRIM_ALPHA_MODE settings are all set to default values, the material is deleted from that prim face, and LI may be updated accordingly
  • This new scripted capability will only work on the nominated test regions
  • ALM must obviously be enabled.

Known Issues

  • The version currently on Aditi lacks proper throttling, so there could be performance issues if scripts behave badly. A throttle will be added in due course
  • There is a viewer rendering issue, where the face will not be rendered and you’ll see log spam (BUG-6187). This can happen:
    • If the viewer has ALM enabled
    • And a prim face has a material on it
    • And PRIM_ALPHA_MODE is PRIM_ALPHA_MODE_BLEND (this is the default after a material is added)
    • And the diffuse texture does not have an alpha channel (e.g. plywood)

With reference to BUG-6187, Maestro added, “One thing to keep in mind …  is that if your diffuse texture lacks an alpha channel, you’ll also want to set the alpha mode to PRIM_ALPHA_MODE_NONE to avoid the bug, even if you really just want to add a normal map.”

The bug itself doesn’t mean the alpha mode should be set every time a materials map is changed, only when adding a material to a face which previously didn’t have a material. Maestro went on to give some further information on the issue:

What happens when you add a material via the build tool, is that the viewer inspects whether the current diffuse texture has an alpha channel and automatically sets the alpha mode to ALPHA_MODE_NONE if the diffuse texture is opaque, but keeps it at _BLEND if there’s an alpha channel. Unfortunately, the simulator can’t do this, because it doesn’t necessarily have the texture asset and doesn’t have the right libs to process texture assets in that manner. The build tool has some trickery where it always greys out the UI for alpha mode when the texture doesn’t have an alpha channel. Anyway, it’s kind of a hassle, but once PRIM_ALPHA_MODE is set to something ‘friendly’, you should be able to update normal or specular settings without touching it again.

As this is a viewer rendering bug, there is no timescale as to when a fix may appear.

The Lab is particularly interested in seeing how use of these new parameters may affect performance (such as through rapid and repeated changes to maps), and what kinds of rates cause these issues, so that they can more accurately assess the required level of throttling.

Depending upon how further testing goes, what additional changes the Lab needs to make, and what has already been scheduled at the time, these updates might be available on an RC on Agni in a few weeks.

SL projects updates week 22/1: LSL functions for materials, group bans

Posted on by Inara Pey

It’s a light start to project news from the lab this week.

Server Deployments Week 22

There are currently no planned deployments for the week.

Materials LSL Functions

There’s still no firm date for when this are liable to surface for testing, but speaking at the Simulator User Group on Tuesday May 27th, Simon Linden indicated the time is getting “closer”. In the meantime he re-iterated the get and set functions currently being worked upon, which remains as per my week 21 report, namely:

Get functions:

  • [PRIM_SPECULAR, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
  • [PRIM_NORMAL, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians]
  • [PRIM_ALPHA_MODE, integer face] returns [integer alpha_mode, integer alpha_cutoff]

Set functions:

  • [PRIM_SPECULAR, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
  • [PRIM_NORMAL, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians]
  • [PRIM_ALPHA_MODE, integer face, integer alpha_mode, integer alpha_cutoff]”

The same access rules will apply to materials as for diffuse (texture) maps.

Most people may already be aware that llSetTextureAnim() will apply an animation equally across all three maps applied to an object / object face. However, the Lab is not currently looking to add additional parameters to llSetTextureAnim() so that each type of map independently of the others. Offering an explanation as to why this is the case, Simon said:

I’m guessing that would be pretty ugly to implement … or would need some careful design and thought as it couldn’t create new material entries under the hood.  I think that will have to be a follow-on feature … I can imagine it might create some cool effects but it would have to be carefully done not to blow up the materials accounting.

Group Bans

Simon indicated that the remaining back-end server updates for the group ban service may have been deployed on Tuesday May 27th. If so, it is possible that an initial server-side RC deployment of the group ban code might occur in week 23, together with the appearance of the group ban viewer. however this is pure speculation, and depends on how long the Lab want to let the back-end updates run prior to making a visible code deployment. More is likely to be known following the Server Beta meeting later in the week.

SL projects updates 21/2: grid issues, server updates, viewer

Posted on by Inara Pey

Server Deployments week 21 – Recap

On Tuesday May 20th, the Main (SLS) channel received the server maintenance package deployed to Magnum in week 20.This includes a bug fix for a networking-related issue that sometimes affects busy sims. Issues encountered during the deployment, but unrelated to it (see below) meant it had to be curtailed.

As a result, the Main channel deployment resumed on Wednesday May 21st, with the result that the deployments scheduled for the 21st in fact took place on Thursday May 22nd, as follows:

  • The BlueSteel and LeTigre RCs remained on the Sunshine / AIS v3 server-side code, and received the networking-related bug fix deployed to the Main channel
  • The Magnum RC received a new project, which includes changes related to the ‘Experience Tools’ project.

More on the Log-in and Grid Issues, Tuesday May 20th

Simon Linden identified the issue which caused log-in issues on Tuesday May 20th
Simon Linden identified the issue which caused log-in issues on Tuesday May 20th

During the Server Beta meeting on Thursday May 22nd, Simon Linden, who identified the problem, gave a further explanation of Tuesday’s grid issues, which prevented people from logging-in to SL.

Essentially, the log-in server was failing to give the viewer the correct token for it to connect to a region, so people actually got through the log-in phase when starting their viewer, but never connected to a region. “The conversation between the login server, your viewer and the region didn’t work any more,” Simon said.

Maestro then added, “After logins were restored, there was a period where the inventory servers got pretty ‘heated up’, probably from people logging in after hours of downtime, so inventory was bad for an hour or two.” It was apparently at this point that the decision was taken to suspend the Main channel server deployment and resume the work on Wednesday May 21st, pushing the RC updates into Thursday.

It is not anticipated that the problem will recur now it has been identified and rectified.

As a result, the scheduled maintenance that had been planned for Thursday May 22nd was cancelled. This work has yet to be rescheduled, and is apparently to be focusing on the database hardware. “Sims should have slightly faster access after the maintenance,” Maestro said of the work, “though I wouldn’t promise anything major.”

The Grid Status page will carry the revised date and time of the work once it has been rescheduled.

SL Viewer

As noted in these pages, The Lab released its Oculus Rift project viewer to the public on Wednesday May 21st, with an announcement in the main blog. The viewer, version 3.7.8.289834, is aimed at getting people started on using the Oculus Rift in Second Life, rather than at providing a finished product with UI optimisations, and appears to be aimed towards encouraging early adopter of the Oculus Rift to try-out Second Life.

Also on Wednesday May 21st:

  • The Zipper viewer for faster installation was promoted from project viewer status to release candidate status with the arrival of the Zipper RC viewer, version 3.7.9.290133 in the release channel
  • The Sunshine / AIS v3 RC viewer returned to the release channel in the form of version 3.7.9.290131, referred to as “Sunshine v2”.

These two viewer updates see the total number of release candidate viewers in the release channel rise to four once more. As also, details of updates in my Current Viewer Releases page.

Group Ban list

One of the required central updates for the group ban updates was deployed to Agni on Wednesday May 21st. A further update is needed before a server RC with the group ban code gets deployed, however. These updates are related to the central service to manage group bans.

 Other Items

LSL Functions for Materials

Not a lot to add here. As mentioned in part one of this report, Simon is now actively working on this functionality. He didn’t have too much to add during the Server Beta meeting, other than Maestro Linden has also been looking at the work Simon has done and has fixed a few issues. There’s still no date when the work might become visible for people to poke at.

LSL Functions for Projected Lights

Talk of LSL functions for materials saw talk of LSL functions for lighting projectors resurface (see SCR-163), prompting Simon to ask, “Does anyone have ideas how people might cause trouble with the projector LSL functions? I wondering how it might cause problems, other than lots of updates … and if it would be any different from rezzing stuff?” Nothing of any serious impact could be identified, although it’s not clear whether the Lab will poke at that or not once the materials LSL functions have been sorted.

Hiding Objects from View and Parcel Privacy

BUG-5671 is actually a feature request, and concerns the provision of a check box in the viewer’s Parcel Properties so that all objects outside that parcel would be not be rendered for anyone within the parcel boundaries. The request appears to be for a server-side function, and the JIRA has seen some heated debate on the matter.

Simon Linden revealed that while working on the parcel privacy option (which hides avatars inside a parcel, and blocks their chat from those outside of the parcel (and vice-versa), he looked at also blocking object views, “and even played with a prototype,” he said. “It’s pretty ugly because you end up with nothing there … at least in my simple code. “Then you walk onto the parcel and all the trees and house and stuff pops up … it was odd.”

However, he revealed the request has been imported by the Lab, so there might be some interest in doing something with it. Part of the debate around the idea on the JIRA has been on whether the setting should be enforced server-side or just within the viewer (so the user retains the choice as to what they see outside a parcel). Commenting on this, Simon said, “server-side would be better so you wouldn’t get updates for things you can’t see, but a cosmetic viewer-side option might be possible.”

So that’s another one to watch out for.

SL projects updates 21/1: server, viewer, LSL and materials

Posted on by Inara Pey

Server Deployments Week 21

Main (SL) Channel

On Tuesday May 20th, the Main (SLS) channel received the server maintenance package deployed to Magnum in week 20.This includes a bug fix for a networking-related issue that sometimes affects busy sims.

Issues encountered on the grid, but unrelated to the new code deployment, interrupted the latter. Commenting on the situation at the (late-starting) Simulator User Group meeting, Simon Linden said, “I believe the rollout stopped in the middle, and things will get patched up tomorrow morning. We’re still picking up the grid pieces and will sort out the clean up plan later in the day.”

BlueSteel and LeTigre RCs

On Wednesday May 21st, the BlueSteel and LeTigre RCs remain on the Sunshine / AIS v3 server-side code, and receive the networking-related bug fix deployed to the Magnum RC in week 20 and to the Main channel on Tuesday May 20th – see here for details.

Magnum RC

On Wednesday May 21st, the Magnum RC should receive a new project, which includes changes related to the ‘Experience Tools’ project.

SL Viewer

The de facto release viewer updated on Monday May 19th to version 3.7.8.289922, formerly the Maintenance RC comprising fixes in Recent tab, Chat, LSL editor, land management, etc; GPU table updates; crash fixes & performance improvements – release notes here.

Also on Monday May 19th, the following RC viewer updates occurred:

  • The Sunshine / AIS v3 RC was temporarily removed from the Alternate Viewer page, but is expected to return soon
  • A new Memplug RC viewer, version 3.7.8.289942 was released, containing a number of fixes for memory leaks which are expected to result in improved viewer performance and a reduction in crash rates.

LSL Functions for Materials

Materials processing: LSL capabilities for materials
Materials processing: LSL capabilities for materials now being looked at

Further to discussions in week 20, Simon Linden had some news on the much-requested LSL functions for materials processing, saying, “I can say I was trying to grief myself with materials LSL functions the other day. I hope we can talk more about that on Thursday at the beta user group.” He went on to outline some of the functions for manipulating materials that he’s been playing with:

Get functions:
[PRIM_SPECULAR, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
[PRIM_NORMAL, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians]
[PRIM_ALPHA, integer face] returns [integer alpha_mode, integer alpha_cutoff]

Set functions:
[PRIM_SPECULAR, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
[PRIM_NORMAL, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians]
[PRIM_ALPHA, integer face, integer alpha_mode, integer alpha_cutoff]

He went on, “There is a magic default value using NULL ids that represents “no material” … so it can be removed.”

Simon also indicated that at some point soon (no date as yet), there will a few regions (most likely on Aditi, the beta grid) to try-out the new functions with the aim of seeing how the capabilities are used, how they get abused and then how SL behaves, so that some appropriate limits can be imposed to prevent deliberate or accidental abuse.

Other Items

New Mesh Avatars and the AMD/ATi Issue

On Thursday May 15th, Linden Lab launched their line of new mesh avatars to something of a mixed response. Unfortunately, said avatars may have fallen a-foul of a long-standing  rigged / fitted mesh rendering issue affecting people used AMD / ATi graphics systems with recent Catalyst drivers, and which sees rigged / fitted mesh stretching to the 0,0,0 coordinate of a region – see BUG-6065, which offers advice on circumventing the issue.

SL projects updates 20/2: server, group bans

Posted on by Inara Pey

Server Deployments Week 20 – Recap

There was only one server channel deployment in week 20, which went to the Magnum RC.

This was a new sever maintenance project deployed on Wednesday May 14th, which included a bug fix for a networking-related issue that sometimes affects busy sims, which Maestro Linden described as, “busy sim hosts would suddenly run into a bunch of networking issues, where you’d see failures creating inventory, accessing capabilities, etc.” The problem can also apparently affect LSL email registration for receiving email from outside the region, causing it to break without automatic recovery.

Maestro indicated that the Lab has a hotfix for regions reporting the problems (although that number appears to be low) which involves a configuration change for the sim host, but the update deployed to Magnum (and which will obviously progress to the other sever channels) has this config change set by default.

SL Viewer

There have been no further updates to any of the SL viewers currently in the release channel or available as project viewers.  Releases are as per my Current Viewer Releases page.

Group Bans

The group ban work is inching closer to the main grid. However, it’ll still be another couple of weeks (ish) before anything visible is seen as far as this capability is concerned. As noted in week 19, the Lab will be deploying things cautiously, with an initial back-end host code update being undertaken first, prior to anything being seen on the simulator channels.

“We’re just running some final tests at this point; the server which runs the group ban service also provides some other services, and we want to check that those didn’t break,” Maestro Linden informed the Server Beta User Group on Thursday May 15th.

He went on, “After the back-end is out, we’ll want to give it a few days to verify that nothing broke because we don’t want to roll back the backend service after group ban is on server RC.”

This probably means it’ll be another couple of weeks before the server-side code appears on a server RC channel. The plan is that when that happens, a formal project viewer with the viewer-side group ban code will appear for public use.

When formal deployment to one more simulator RCs does commence, it is important to remember that until the server-code has been fully deployed across the main grid, the group ban functionality will only work as advertised on those servers / simulators / regions which have the necessary server-side code. It therefore may appear to give unpredictable results.

For example, you will only be able to effectively ban people from you group when the viewer is connected to a server supporting group bans (although they do not need to also be using the group ban viewer in order to be banned). Also, even when someone is banned from your group, they could successfully rejoin it from any simulator / region which does not have the server-side code deployed to it (leading to further confusion as they’ll appear in both your group members list and your group ban list).

Obviously, these issues will go away once the server-side code is fully deployed across the main grid. However, until such time as that has been achieved, people should be aware they may encounter what appear to be “issues” with the functionality simply because it isn’t available right across the grid.

More information will be posted on this when the project viewer surfaces and the code has been made available of a server-side RC.

SL projects updates 20/1: server, viewer, LSL and materials

Posted on by Inara Pey

Server Deployments, Week 20

There was no Main channel deployment or rolling restart on Tuesday May 13th, and neither the BlueSteel or the LeTigre RC channels will receive an update or should undergo a restart on Wednesday May 14th.

The Magnum RC should receive a new sever maintenance project on Wednesday May 14th, which includes a bug fix for a networking-related issue that sometimes affects busy sims.

SL Viewer Updates

The SL Maintenance viewer was updated on Monday May 12th to version 3.7.8.289922. This viewer includes multiple fixes to Mac viewer; fixes in Recent tab, Chat, LSL editor, land management, etc; GPU table updates; crash fixes & performance improvements.

LSL Functions for Materials

The subject of scripted control for materials was once again raised at the Simulator User Group meeting on Tuesday May 13th. Commenting on the matter, Simon Linden said:

I am looking at it but not promising anything. We’re trying to be really careful to understand how the server and viewers will react when stressed with a lot of material churn. From what I can tell, fast-moving material-based animation will not work well … that’s likely to be throttled or blocked somehow. But supporting something like a hud or other control that could adjust the look of an object … where it’s done rarely … is definitely possible.

As noted the last time this subject was raised, there are concerns over how LSL control of materials might impact system performance, either deliberately (via rapid and multiple flipping of maps, hence Simon’s comment on throttling the speed at which changes could be made), or unintentionally, such as using them with objects which may already have a large performance impact (such as animated mesh tails).

During the meeting, there was discussion on options for animating normal and diffuse maps, remembering that they can already be animated in lockstep with their attendant texture (diffuse) map. During this discussion, Simon commented on some of the difficulties in animating  materials independently of the texture map:

The materials LSL support would include changing the offset, repeat and rotation values for the two maps, just like for regular textures. The update problem hits if you look at the way materials have been optimised between the server and viewer and how updates are sent. Materials are referred to by a number ID … so you get updates that say “this face has material 1234” on it, the viewer, if it doesn’t know what 1234 is, has to ask the server.

Now, if you change the offset … you have a new material 34356, the viewer has to again find out what that is, but this time it already has the actual specular and normal maps, so no download there.  And when you switch back to 1234, it has all the info and can draw it faster.

Summing-up the situation in general, Simon concluded, “I hope there will be something to play with eventually on the beta grid … we’ll probably want to experiment there and figure out what kind of limits are effective.”