Category: SL User Group Meetings

A Shining announcement: major improvements coming to SL

Posted on by Inara Pey

Yesterday Linden Lab announced a major series of new initiatives aimed at improving the overall SL experience. The announcement came via a Tools and Technology  blog post, which covers the initiatives in great detail. These focus on four main areas of activity, one of which is directly related to hardware and infrastructure, and the remaining three are focused on the platform itself and are grouped under the Shining project banner.

The hardware / infrastructure element of the work is described thus:

This year, Linden Lab is making the single largest capital investment in new server hardware upgrades in the history of the company. This new hardware will give residents better performance and more reliability. Additionally, we are converting from three co-locations to two co-locations. This will significantly reduce our inter-co-location latency and further enhance simulator performance.

The Shining project is something that is already known to many SL users – especially those who attend some of the User Group meetings. It is perhaps most famously associated with the Lab’s work on the Viewer rendering code, removing outdated functions and calls no longer supported in modern graphics systems (most notably Nvidia) and improving graphics handling overall. Shining has also been responsible for other incremental improvements to issues around streaming objects and avatars.

Under the new initiative, Shining is split into three core performance projects.

Bake fail: a familiar problem for many

Project Sunshine: One of the biggest complaints from users in SL is related to avatar rezzing. This can appear slow, and usually manifests in avatars remaining grey for periods of time, or in skin and system clothes remaining blurry (see right) – and at its worst, result in a user changing their avatar’s outfit – but others either seeing the avatar still dressed in the previous outfit or naked. Collectively, these issues are known as “bake fail” and are the result of the Viewer having to do all the compositing of avatar textures locally, then sending the results to the SL servers, which then send the information back to the simulator the avatar is in to be accessed by other Viewers in the same simulator.

Under Project Sunshine, to precis the blog post, much of this work is moved server-side, using a new, dedicated server, the Texture Compositing Server, which is separate to the simulator servers. This effectively allows all the “heavy” communications and calculations work relating to avatar texture calculations to performed within LL’s servers and across their own internal network, removing the reliance upon the Viewer and on Viewer / server communications which are outside of LL’s control.

Object Caching & Interest Lists: This is intended to directly address another common request from users: improving how the Viewer handles local object caching. This effectively means that once the Viewer has information relating to a specific region, and providing the information is still valid (i.e. there have been no changes to objects that the Viewer already has cached), then it will no longer need to re-obtain that information from the server. Only “new” or “changed” data needs to be streamed to the Viewer. This should mean that on entering a previously visited region, the Viewer should immediately be able to start rendering the scene (rather than requesting a download from the server), while simultaneously requesting any “updates” from the server through a comparison of UUID information and timestamps.

HTTP Library: The final aspect of Shining’s three-phase approach is to improve the underpinning HTTP messaging that are crucial to simulator / simulator and simulator / Viewer communications (and thus key to the other elements of Shining) through the implementation of “modern best practices in messaging, connection management, and error recovery”.

Overall, Shining will be tackling some of the major causes of Viewer-side lag and user frustration in dealing with avatar bake fail and the complexity and wastefulness of scene rendering that is encountered when moving around SL.

No definitive time frames for the improvements have been forthcoming with the announcements – and this is understandable; there’s a lot to be done and matters are complex enough that LL will want to proceed with minimal disruption to the grid and to users. Doubtless, more information will be made available as becomes known through the LL forums and (possibly more particularly) via the relevant User Groups.

Mesh clothing deformation: alternative approach suggested

Posted on by Inara Pey

Updated June 26th 16:30 BST:  The discussion on this alternative continues on the SLU Forum thread (recommended reading for anyone interested, as a lot is explained succinctly and clearly). Darien Caldwell has summarised the technical aspects of both solutions (and in not having a deformation capability) in terms of who is the greatest impacted – consumers, creators and / or coders.  Similarly, in answering a question posed by Innula Zenovka on the relative advantages / disadvantages to the two ideas (RedPoly’s and the deformer), Adeon Writer commented: 

“This trick was created to address major problems with clothing, but it is a patch. And you can see the areas where it’s not patched: this only makes mesh follow a few more sliders, while the rest (especially the face) do nothing.

“Qarl makes mesh work with ALL sliders, even future ones that don’t exist yet. It is the correct solution to the problem, this is a quick workaround.

“Qarl gives the ability to make entire new human meshes fully removed from the system shape that still work with all sliders and avatar physics,

“That is not possible with this.”

This would seem to be a clear-cut differentiator that would suggest that if matters come down to a choice of one approach or the other, continuing with the deformer may well be the preferred course of action. Obviously, nothing further has been said on the matter by LL, but further updates will be posted as they become available.

Nalates Urriah brings news of a potential alternative to the mesh parametric deformer that has been under development by Qarl Fizz, and which has been reported upon extensively by Nalates, myself and others.

I’ll leave the in-depth technical explanation and quotes to Nalates – she broke the story, after all. However, to try to summarise:

  • The idea is the rather than weighting mesh clothes against the avatar “skeletal frame”, the clothes are weighted against the “collision volumes” – these are (I gather) used to detect when your avatar collides with a physical object in-world, and thus are designed to morph when you adjust your avatar’s shape
  • The approach isn’t perfect and has a number of limitations (female clothing won’t stretch with breast size changes, for example); extreme sizes cause issues (as they do with the deformer); weight painting during the construction of mesh clothing can be somewhat more problematical
  • Alpha masks will still be required in certain situations (but then, alphas were never going away anyway).

The developer of the approach, RedPoly Inventor has released a demo version of the approach using a dress, which can obtained from his store. There is also a demo video on YouTube:

RedPoly is the first to admit the approach is not perfect, but has also proposed an additional idea of developing a further set of avatar “bones”, which he calls “cbones” that would allow this approach to work a lot better. According to Nalates’ report on the mesh meeting where this all came out, RedPoly believes the development of such a new system would be relatively simple.

Interestingly, according to AshaSekayi Ra, commenting in an SLU Forum discussion on this development, the idea of using the collision volumes  was first raised in the mesh beta last year and that Prep Linden requested samples of clothes rigged to the avatar’s collision volumes, but it is unclear what happened with any tests LL may have carried out.

Right now, this doesn’t mean the end of the deformer, nor does it mean all mesh clothing issues are solved. It does, however, open-up new avenues of exploration and certainly new topics for discussion on the matter.

Reading Nalates’ report, it would appear that the idea has taken LL themselves a little by surprise, despite the fact it may well have been previously discussed, and their reaction is potentially best described as cautious.

As it stands, mesh designers such as AshaSekayi Ra and Ellie Spot will doubtless be looking at the idea, as will those with expertise in the avatar design, as well (one would hope) LL themselves. As Nalates states, there will be further news emerging on this as tests are conducted and feedback given.

Related Links

With thanks to Nalates Urriah.

Mesh Deformer: updates and musings

Posted on by Inara Pey

I’ve largely backed away from covering the mesh deformer of late because Nalates Urriah is doing a good job of reporting back on the Mesh Content User Group where it gets discussed, and I don’t really get the time to attend the meetings myself.

On June 11th, Nalates provided a summary of the most recent meeting, which includes some interesting excerpts from the conversation on the deformer. Of particular interest are a couple of comments from Nyx and Oz Linden, notably:

Nyx Linden (replying to a comment from Ellie Spot that the deformer is now in LL’s hands & is a matter of “Fixes to make it work for more extreme shapes“): The issue of extreme shapes is definitely an issue that needs to be discussed.

Oz Linden (later in the conversation): We’ve given Qarl some feedback. In its present form, it’s not quite good enough, but I don’t think we should get into details. There are problems with the avatar, and there are problems with the deformer. It remains to be seen whether or not we can fix the avatar problems (I’m looking into it from a couple of angles). But, we hope that it’s possible to make some progress on the deformer even without those fixes.

As Nalates points out, Nyx’s comment is open to a number of interpretations, some of which could be positive (and given Nyx’s nature) fare more likely) while some might be potentially more negative; as no real expansion on the comment was given, it comes down to a matter of interpretation / speculation on the matter.

However, in this week’s Metareality podcast, Qarl does comment further on the matter, in  a discussion commencing at 34:10 into the podcast:

[36:04] Qarl: Now I have to say that he’s like one of my favourite Lindens, so I doubt he was saying anything bad.

Oz’s comment – and the fact he would not be drawn into saying who at LL is working on the deformer or what the overall priority for the project is within the Lab – drew further comment from Qarl:

[38:22] Qarl: So I’m dealing with “Linden X”, who I also like a great deal and is a very nice guy. And … I think we’ve come to a place where we have agreed – I think, although he didn’t respond to my last e-mail – I think we’re agreed on what needs to be done before we can ship. One of those ideas is to … is similar to the standard sizing business that everyone is talking about, but instead of having a fixed set of sizes – small, medium large – encode the actual avatar parameters into the mesh itself, so you can have any base or any avatar shape as your base, because linden Lab wanted to have a stick figure base, and I’m like, “Well if you encode the parameters, then you guys can do that”.  … So assuming there’s enough room in the mesh asset for that, then I think that’s what we’re going to do. And then the other issue is that the vertex matching needs to be tweaked a little bit  – for our tech listeners – to take into account the normals. So its going to look at both the position and the normals when it chooses the matching spot.

Qarl’s comments prompted special guest Eclectic Wingtips to ask:

[39:48] Eclectic Wintips: So how much work is this going to be for those of us who make mesh? … If there’s multiple sizing, are we still going to need to do multiple sizing in the 3D programme [used to create a mesh item of clothing] to bring it in?

[40:01]Qarl, Oh! no, no, no. You can totally not use that at all. You just leave all the parameters the same, and it just uses the default avatar and blah, blah, blah … BUT, if you want to make an outfit that fits really well on … an anorexic model, so you tweak it for the super skinny or something, then you can set those parameters to be like “fat”, and it matches the bases of extra, extra, extra, small. 

[40:36] Gianna: But you’re setting those parameters within your 3D content?

[40:39] Qarl: within your 3D content … So the issue then becomes the GUI, because you have like a thousand parameters now you have to enter … what I think … what we’re going to default to is, you’ll have like six radio buttons for those sizes … but with very little extra effort, the Third-party Viewers will be able to expose that stuff, so you’ll be able to do anything you want; just so long as it’s in the protocol, you can open that later.

Qarl’s explanation – assuming this is what happens with the deformer – seems to offer the most flexible solution to the question of base shapes and sizing. To hear the discussion in full (and the rest of this week’s topics), be sure to listen-in to the podcast itself.

Related Links

Advanced user experience tools griefing update

Posted on by Inara Pey

Oskar Linden has provided an update / post-mortem on the recent bout of griefing that took place across the grid as a result of person or persons unknown abusing the advanced user experience code that was released onto the Magnum Release Channel two weeks ago.

The problem hit on Monday 4th June when the advanced teleport functions released to Magnum were used to teleport individuals or groups around the grid, with some people reporting they were teleported to the likes of The Cornfield, while others found themselves unexpectedly picked up and dropped into stores or meetings.

Linden Lab reacted rapidly to the issue, determining a fix for the exploit on the afternoon of the 4th (SLT) and deployed across the entire grid in a rolling restart that affected the main channel and all release channels.

The key points relating to the issue remain:

  • The exploit came about due to a permissions restriction within the advanced tools not working as anticipated
  • To prevent further misuse of the code, the advanced tools were also removed from the Magnum RC channel
  • Both the code and the associated test plans have been revised and are being run through LL’s QA process to better ensure the situation of the 4th June is unlikely to be repeated when the code is rolled-out once more
  • Coyot Linden estimates that the advanced experience tools project has been delayed by around 2-3 weeks as a result of these events
  • LL are at this point in time unclear as to when the tools are likely to be rolled back out onto a Release Channel; the slot assigned to the tools on the Magnum RC has now been taken by other security issues in preparation for their roll-out to the grid.

One immediate outcome of the griefing situation is that the teleport capability has been revised so that when someone is teleported, the function will tell them the name of the owner of the object that teleported them (thus allowing any potential abuser of the system to be reported to LL via an Abuse Report).

With thanks to Nalates Urriah.

Genie out of the bottle: advanced tools capability used for griefing

Posted on by Inara Pey

Update 11th June: Oskar Linden has provided further feedback on this situation. 

Update June 6th: Oskar Linden has confirmed that the Advanced Creation Tools capabilities that were rolled-out to the Magnum RC channel will remain disabled until at least next week, although no firm decision has been on re-enabling them.

Update June 5th 11:30 UTC: The rolling restarts completed at 03:39 UTC. At present, no further updates have been given on the forum post relating to the restarts, but this may change later during the course of today. Oskar Linden has reiterated that due to this rolling restart, there will be no main channel deploy today and that details on Wednesday’s RC deploys are still TBA. My apologies for late timing of this update; a small matter of real life prevented me putting my nose in front of the keyboard any sooner!

Last week saw elements of the new Second Life Advanced Creator Tools rolled-out to the Magnum channel. As I reported at the time, the tools were issued without the new permissions system, but with safeguards that (it was hoped) would prevent misuse.

Today, however, a party or parties unknown started to use teleport functions of the new tools outside of the Magnum Release Channel as a means of griefing. People first became aware of the issue as individuals and groups started finding themselves randomly teleported around the grid, which sparked speculation on Twitter. Later, messages started circulating in-world among groups, outlining issues, such as this one, sent out to the NCI Citizens Helper Group (with thanks to Raylene Gothly)

Ok to everyone, there is something seems grid wide, we do not know if its a bad code in certain sims or if someone has found a way to teleport grief. But its happening all over, so I’m not sure. however I’d like to let everyone know we are aware of this. Suddenly you are just teleported away, best to log off and relog to get out of it, as it seems to continue to teleport you, I was teleported 3 times when I relogged… Dont be frightened it just seems to be a mess up.

The only regions unaffected by the griefing tool appear to have been those on the Magnum RC (where the new teleport functionality has safeguards) and those sims that had script capabilities disabled. Messages were thus circulated to land holders to disable scripting in their regions to avoid the issue, at least until Linden Lab responded to the situation.

Linden Lab themselves commenced efforts to stop the problem with emergency rolling restarts across the grid, announced via a Grid status update and a forum post:

To solve a security issue with the Experience Tools that were deployed to Magnum last week we are doing an emergency simulator rolling restart deploy. This has already begun.

Regions on the following channels will be restarted with the fixed code:

Main Channel
BlueSteel
LeTigre

Magnum will not be restarted because the issue is not possible in Magnum regions. We will have no rolling restart Tuesday morning. The Wednesday morning RC channels will roll at the usual time.

We apologize for any inconvenience and appreciate your understanding.

I’ll update here when further information is available.

User Experience Tools: initial roll-out to Magnum RC

Posted on by Inara Pey

Today sees the first phase in rolling-out the new User Experience tools to the Main grid. As noted in the official release notes, the tools have been rolled-out to the Magnum Release Channel.

The new tools were previewed back in March in a rare SL blog post, which I covered at the time it was released. Today’s Magnum release adds three new LSL functions for User Experience:

  • llAttachToAvatarTemp (integer attach_point) — Follows the same convention as llAttachToAvatar, with the exception that the object will not create inventory for the user, and will disappear on detach, or disconnect. It should be noted that when an object is attached temporarily, a user cannot ‘take’ or ‘drop’ the object that is attached to them. Additionally, if this function is used with experience permissions, the user is ‘automatically’ made the owner of the object. If you use this function without the experience permission, the target MUST be the owner of the object for it to attach properly
  • llTeleportAgent (key agent_uuid, string lm_name, vector landing_point, vector look_at_point) — Teleport Agent allows the script to teleport an agent to either a local coordinate in the current region or to a remote location specified by a landmark. If the destination is local, the lm_name argument is a blank string. The landing point and look at point are respected for this call. If the destination is remote, the object must have a landmark in its inventory with the teleport agent script. lm_name refers to the name of the landmark in inventory
  • llTeleportAgentGlobalCoords (key avatar, vector global_coordinates, vector region_coordinates, vector look_at) — Teleports an agent to region_coordinates within a region at the specified global_coordinates. The agent lands facing the position defined by look_at local coordinates. A region’s global coordinates can be retrieved using llRequestSimulatorData(region_name, DATA_SIM_POS).

This initial roll-out does not include the expanded Experience Permissions System, as Oskar Linden points out in a forum post on this week’s server releases. Instead, the new functions work with the current runtime permissions system (specifically PERMISSION_TELEPORT), although plans are in-hand to roll-out the new permissions systme at some point in the future.

No details have yet been released on the Professional Creators Programme that was mentioned in the original preview blog post, but if you are interested in learning more about the tools, the Advanced Creator Tools Notification Group is still open to membership, and you are encouraged to join the Group.

Oskar notes that LL will be actively monitoring the forum thread announcing the roll-out, and anyone encountering issues with the new functions is encouraged to post feedback in the thread, cross-referencing any relevant JIRA they raise.

Given the functions are now on the Magnum RC, and people are being encouraged to provide feedback, this roll-out would appear to move the User Experience tools outside of the associated Closed Beta programme.

For ease of reference, here’s the video LL released with the original preview announcement:

Related Links