Category: SL User Group Meetings

SL Project news week 44/3: mesh deformer

Posted on by Inara Pey

Testing is continuing with the latest release of the Mesh Deformer project viewer, which can be used to deform mesh items to either default or custom human shapes. While the pool of test items remains small, people appear to be testing using their own creations, with at least some feedback being given to the JIRA (STORM-1716), which remains open to comment. If you are testing the deformer using the latest project viewer, please be sure to provide feedback on your results – be they with default shapes or custom shapes – to the JIRA.

Some problems with breast fittings might be down to an incompatibility between Avastar and the viewer, which is currently being corrected

Most of the results obtained to date appear to be satisfactory, although some issues still remain with custom shapes. Darien Caldwell, working with Gaia Clary, has identified one issue which exists specifically with the Avastar add-in for Blender co-produced by Gaia.

Avastar is a Blender add-on for Second Life mesh creators and animators which provides a wide range of capabilities, including (for mesh creation): SL shape import into Blender, SL shape sliders support, support for attachment bones, and so on.

The issue has been that Avastar’s sliders have been based on a scale of 1-100, whereas the viewer’s sliders operate on a scale of 0-100 , leading to some scale miscalculations within Avastar which in turn have led to issues with mesh fitting over body parts such as breasts. According to Darien Caldwell, she and Gaia now have this “pretty well nailed” and an update to correct Avastar will apparently be out shortly (Update: please see Magus Freston’s comments at the end of this article).

This still leaves the broader deformation issue, as reported recently, which is still being looked into, and awaiting some feedback from Qarl.

Other issues outside of these which have arisen with the deformer have been largely the result of unrealistic expectations – that it will, for example, mimic facial morphs or hand movements closely or some changes to feet. However, in these situations, it is important to remember that the deformer was never developed to deal with these, as it works off the avatar’s bone structure, and facial features and hands don not have any bone structure within the avatar associated with them.

Time Frame for the Deformer

While progress with the deformer continues to look good, there remains no ETA as to when the code will appear in the release version of the official SL viewer.

The major reason for this is the ongoing problems with the Beta release channel for the viewer (of which more in the next update for this week!). As it stands, the deformer is positioned roughly at the back of the queue of releases which are being held as LL work to resolve the current crash issues with the Beta viewer. This means that, at least until the Beta issues are resolved, there is no official ETA for the deformer code reaching the release viewer. However, the latest revisions are starting to be incorporated into some TPVs.

In the meantime, and if you have been testing the project viewer, please remember to give feedback via the JIRA.

Performance Concern

While it is not actually an issue with the deformer per se, commenting at the Content Creation User Group on Monday 29th October, Siana Gearz highlighted a potential problem with mesh clothing utilising the deformer and avatar physics.

The concern is that the deformer uses the same morph-based schema as is used by the avatar physics system. This means that the GPU has to do a lot of additional calculations for the polygons in an item of mesh clothing to simulate movement (such as “bouncing boobs”) when avatar physics are in use. This obviously leads to a performance hit. So long as the polygon count in clothing is kept low, the impact is minimal, but the concern is that clothing build using high polygon counts to provide detail could have a larger impact on the viewer.

One possible way for this to be avoided, should it become an issue, is for clothing makers to optimise their mesh clothing with lower poly counts – and the forthcoming materials processing capabilities should go a long way towards helping with this.

Related Links

SL projects news week 44/2: server, group services, mesh and more

Posted on by Inara Pey

Quick Links

Server Updates

Deployments this week are being delayed some 24 hours, which means the main channel deployment will not take place until Wednesday 31st October, and the RX channels on Thursday November 1st. This has led to concerns that the main channel deployment / restarts may impact any Halloween events taking place across the grid on Wednesday 31st. Simon Linden promised to raise the concerns at an internal LL meeting taking place later on the 30th October, however, at the time of writing, the Grid Status page reports that the deployment will go ahead, starting at 05:00 SLT on the 31st.

In the meantime, the deployments for the week remain largely as previously indicated:

  • The main channel should receive the code currently on BlueSteel and Magnum. As mentioned above, the code has no externally visible changes but has some system level adjustments – release notes
  • LeTigre will receive a further update for the code currently running on it, which will include a number of bug fixes and pathfinding updates – release notes
  • On Friday 26th October, Simon Linden indicated to me that Magnum should be receiving the code planned for week 43 (the llSensor() problem has been fixed) which will include Baker Linden’s Group Services code currently on Snack, however, as of the Simulator User Group meeting on the 30th October, the final release notes for Magnum had yet to be published, so the update may still be in a state of flux
  • BlueSteel should get the same code as is on LeTigre.

Interest List

Andrew Linden has fixed a bug wherein some child prims in linkset fail to rez and he has carried out further work on performance issue he reported last time. This turned out to be an issue with the code which caused the simulator to send a full update of everything within view to the viewer each time an avatar within visual range moved. Understandably, on  crowded regions, this led to performance issues.

The code is in the process of being revised to ensure it only calls for “terse” updates to be sent to the viewer, which will help ensure more relevant information is sent to viewers when updating, which should reduce the performance hits.

Group Services

Baker Linden, speaking at the Simulator User Group on Tuesday 29th October, said that the server-side code for this project, which should improve the load times and editing abilities for very large group lists, seems to be working “moderately well” since the deployment to the Snack RC channel last week. However, some bugs have been found, Commenting on these, Baker explained that, “The group name, description, and other things don’t load right now on the Snack RCs.” However, the bugs have been investigated and fixes found, which should be merged into the code ahead of the planned deployments on Thursday November 1st. The fixes have also been tested on Aditi, where they’ve been found to induce a slight lag on group loading.

For the time being, testing this now code continues to require a dedicated SL project viewer (available for Windows, Mac and Linux), until such time as issues with the SL beta viewer code can be fixed and merges with viewer project code resumed / made available to TPV for integration.

Avatar Baking

Work is still progressing, Nyx Linden confirmed, talking at the content Creation User Group on Monday 28th October. How far down the road the work is, is unclear. The server-side of things will apparently be using the code being developed for the viewer, and it is this which is the focus of attention for the present, as has been the case for some time.In talking to TPV developers on the subject the last time the matter came up, Oz Linden confirmed LL’s plan is still to give TPVs “at least” 2 months (eight weeks) notice prior to anything being rolled out for testing, in order to give TPVs sufficient time to incorporate the code into project viewers of their own and assist with the overall testing.

SL Issues

Mesh Alpha Issue

Theresa Tennyson demonstrates the skinned mesh / alpha issue

Also during the Content Creation meeting, a problem with alpha textures as applied to worn skinned meshes was brought up. Theresa Tennyson demonstrated the issue during the meeting, which somewhat resembles the old invisiprim  / alpha issue.

Siana Gearz suggested two possible causes for the issue, “[The] first is that rigged mesh transparent surfaces appear to be drawn before prim transparent surfaces. [The] second issue is that the shader apparently writes depth for whole fragment, not just for relatively in transparent pixels.”

Nyx Linden requested a JIRA item be raised for the issue, again highlighting the problem with the recent JIRA changes, in that outside of those with access privileges to the new system, no-one could actually confirm if a JIRA had already been raised.

ETA 31st October: Seems a public JIRA on the matter is available – see MartinRJ’s comments which follow this article. Many thanks, Martin!

With thanks to Theresa Tennyson for the Simulator UG meeting transcript

SL project news week 44/1: viewer updates

Posted on by Inara Pey

A quick start-of-week update on the status of releases with the offical SL viewer. News on specific projects (Mesh, deformer, interest lists, etc.) to follow in the week.

Beta and Development Viewers

The beta viewer situation remains in review, with the latest release – 3.4.1.266251, released on the 24th October – still available for download. Crash rates remain the major issue to unblocking matters and getting things moving again.

In the meantime, an updated development viewer (3.4.1.266120) was released on the 25th October, but otherwise things remain largely unchanged, and as stated above, project related viewer releases remain blocked. Expect further updates to be reported later in the week.

FMOD

The aim remains for LL to use FMODex within viewer builds following FMOD’s decision to discontinue making core FMOD libraries available for builds see JIRA OPEN-150). However, the issue is not currently a priority within LL due to other matters (such as resolving beta viewer crashes and unblocking the release pipe).

OpenAL has again be suggested as an alternative to FMODex; however, commenting on this, Oz Linden again repeated that, “I don’t think it very likely that we’re going to use OpenAL.” In the meantime FMODex is in use within the Singularity viewer, and that code has recently been ported into Firestorm, where it is currently being worked on.

CHUI

The Communications Hub User Interface project viewer launched last week. As I reported at the time, this is an attempt by LL to re-centralise communications within the viewer, and has both good and bad points to it.

The fully expanded Conversations floater in the CHUI project viewer

As might be expected with an initial pass of a project viewer, CHUI has generated extensive feedback from testers as to issues and problems both large and small. These very much reflect the fact that CHUI is still in its nascent stages, and that further work will be going into it to both iron-out bugs and improve performance / capabilities. A survey on the project viewer is due to be made available this week, whether this goes ahead based on the level of feedback currently being generated through the JIRA (which has been reasonably high from those testing the new functionality almost feature by feature), remains to be seen.

SL project news: week 43/4: server updates

Posted on by Inara Pey

Week 43 Deployments

Main Channel

Tuesday October 23rd saw an update to the main channel which should have minimal impact on things, the changes having previously been on the Magnum RC channel. LL have been monitoring the deployment and have seen no adverse impacts.

BlueSteel RC

The BlueSteel RC channel received a further update to the current server maintenance project aimed at general stability improvement.

LeTigre

LeTigre is currently the focus of the server modernisation project, and as such received further updates to the deployment of Havok 2012.1. This means that mesh vehicles will continue to be unable to cross from LeTigre into regions running on other server channels for the time being.

As previously reported in part one of this week’s project news, LeTigre contains an updated cURL library which may cause problems for services using an external website for frequent data updates. The issue affects llHTTPRequest.

Essentially, the problem is that until now, the cURL library used by LL uses an explicit call to ensure data being returned from an external web service (such as information relating to the health status of breedable animals) is “fresh” data, rather than anything which may have been cached along the way. As such, specific functionality hasn’t previously been required within LSL to ensure this is the case.

However, The new cURL library deployed to LeTigre no longer attached the explicit call (technically a Pragma: no-cache header) to outgoing requests. This means that information being returned as a result of a call to an external service may in fact come from data cached along the way (such as from an intermediary server). Obviously, receiving “old” data would not be good for things like breedables, which could end up dying.

To overcome this, LL have added a new flag to the llHTTPRequest function to achieve the same result as used to be achieved via the old cURL library attaching the Pragma no cache “request”. In the meantime, anyone with breedables or other services which rely upon frequently updated data from an external web service have been advised to test their products on LeTigre.

Magnum RC

The Magnum RC channel was to have received a series of bug fixes, together with Baker Linden’s code for large Group Services. However, a showstopper issue was discovered with llSensor(). As a result, the release was rolled back and replaced with the BlueSteel deployment.

Also to have been included with this release is a new capability allowing the simulator to report information about script permissions granted to objects within a region. This capability requires an update to the viewer in order to be used (the code for which is currently held-up due to the beta viewer issues). Once the viewer code has been released, the new capability will allow users to list all items in a region to which they’ve granted permissions (such as items which have been granted animate permissions) and, if required, revoke them.

Please use the page numbers below to continue reading this article

Pages: 1 2

SL project news week 43/3: viewer status updates

Posted on by Inara Pey

SL Beta Viewer

A new Beta version of the beta viewer was release on the 24/25th, (3.4.1.266251), which has more-or-less the same visible changes as the previous release, except that tcmalloc has been re-enabled as LL seek to determine whether stability issues have been improved or not. However, given the high crash rates experienced with the previous release, Oz Linden is requesting people take time out to give the beta a run. Speaking at the OpenDev meeting on Thursday 25th October, he said, “Run the beta viewer a lot. We think this one will be good, but it takes a lot of usage to find that out and things won’t get unstuck until we do.”

Tcmalloc has been re-enabled with the latest beta release, and this probably means that those using cloud storage such as Microsoft Skydrive and others (such as Cloud Drive – see FIRE-7520 – are liable to encounter issues using it.

The intent at LL still appears to be the complete disabling of Tcmalloc from the viewer code, however, the attempts to do so to date have only met with partial success – the “fix” for MS Skydrive, for example, apparently only worked for some instances, not all.

Commenting on the situation at the OpenDev meeting, Oz said that efforts to completely disable tcmalloc are “taking too long”. As a result, and to prevent work with tcmalloc from adversely affecting attempts to stabilise the viewer, the decision has been taken to move the work on tcmalloc to a separate branch of the viewer code for the time being, with efforts on the beta branch focusing on stability.

In the meantime, code releases remain blocked, pending confirmation the beta release has improved on previous crash rates (which were around 14%).

Mesh Deformer Viewer

As reported in part 2 of this week’s project news, a new version of the Mesh Deformer project viewer appeared over the weekend – 3.4.1.266081, dated October 20th. In addition, Darien Caldwell has made updates to the SL wiki page on the avatar shape XML format which are related to the project.

The updated shape selection options for mesh clothing and human shapes in the mesh upload floater, as seen in the latest version of the Mesh Deformer project viewer

The current thinking is at present that the latest version of the viewer requires wider testing, so if you are involved in mesh clothing / shape creation (humanoid shapes, remember), then you might want to download the viewer and try it yourself. Commenting on the JIRA (STORM-1716), Darien notes:

If people could provide feedback on the use of the custom base shape part specifically, that would be great.

Keep in mind the potential bone length problems outlined above: do these affect your creations negatively when used with custom base shapes?

And is the potential workaround of setting bone lengths to the defaults a problem for your workflow?

Those and any other issues, please post. Thanks 

Initial feedback from those who have tried the viewer have been largely positive, although the issue with custom shapes and certain sliders, as previously reported in these pages (and on the JIRA) remain. Darien has been looking a little deeper into the latter issue, which affects a total of eleven shape sliders, and seems to have found the potential cause:

“The bone length deformation seems to be performed in the function LLRiggedVolume::update(). The deformer is doing its processing before this is reached, and when creating the custom base shape, it’s never run on that custom base shape. So the bone length deformations aren’t included.”

Instead, the current  deformer code assumes that all joints in a shape have the same scale, and that the scale is uniform in all axes. This is fine for a standard shape, but doesn’t work so well with custom shape forms, and wouldn’t work were scaled bones within avatar shapes ever to come about. The solution for this issue is unclear; the current plan is for Darien to write-up her findings for LL, so that someone there can look into the code as well.

The problem: bone length deformation is performed outside of the deformer code, which in turn appears to assume that all shapes use the same, uniform scale for joints. When working with a default shape, neither of these issues present themselves in obvious ways. When working with custom shapes, however, the problems become very evident. In this image a tall, then shape is use to generate an upper body mesh (flesh toned). When uploaded and applied to the shape itself (shown in black), the discrepancies become clear. Had the mesh been correctly deformed according to the shape data, it should more closely match the original shape

Group Services Project Viewer

Baker Linden’s server-side Group Services code for handling very large in-world groups was rolled out to four regions on the main grid on the 25th October, as reported here. However, due to the issues with the beta viewer code as reported above, testing of the new code requires the Group Service project viewer. If you do manage any group(s) with more than 10K members, you may wish to download the project viewer and give things a test on the nominated regions (see link above).

The viewer is available in Windows, Linux and Mac flavours.

Related Links

New Group Services code now live on Agni

Posted on by Inara Pey
Large group loading: a familiar problem

The Group Services project is an attempt to improve the management and editing of large SL groups by replacing the current UDP-based service (which has capacity issues with the size of group lists it can comfortably handle) with a new HTTP-based service.

Oskar Linden has announced that the new code for handling large groups is now live on four regions on the main grid. His announcement reads in part:

These fixes were released to Magnum this morning, but then we found issues in llSensor() that required us to remove the code from a channel as large as Magnum. We have a very small qa channel called the Snack RC Channel that we put the changes on.

 – https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_Snack/12

You will need to be  a member of the group Second Life Beta to access them. You can join that group here: http://world.secondlife.com/group/19657888-576f-83e9-2580-7c3da7c0e4ca

The four Snack test regions are:

Currently, the viewer-side code required to use the new service is only available in a project viewer, which is available as follows:

The viewer side code, as I’ve been reporting in these page, is currently being held-up from more widespread use by crash issues impacting the SL beta viewer code. As such, TPV developers are being encouraged not to merge the code for the above project viewers with their own development viewer code for the time being.

In the meantime, if you manage a large in-world group with more than 10K members, you may wish to download your relevant flavour of the project viewer and try-out the new code on the nominated regions.

Related Links