SL projects update week 50 (2): Fitted mesh, deformer, viewer code contributions

Mesh Deformer and Fitted Mesh

The future of mesh garments / wearables created using the now SL-defunct mesh deformer was the subject of some discussion at the Open-source Contributions meeting on Wednesday 11th December. While the deformer was never officially adopted by the Lab for use within Second Life, it was available in various test and experimental viewers, and the code could also be included in self-compiled viewers if people knew how.

Fitted mesh is coming....what of the future for garments made for the deformer?
Fitted mesh is coming….what of the future for garments made for / via the deformer?

This means that there are garments within Second Life that were created and uploaded for / with the deformer code, and which can resize with viewers using that code. However, as is the case with Fitted Mesh, the clothing would not deform when using a viewer without the requisite code. The same will be true once the Fitted Mesh updates reach a release candidate status and start to be more widely adopted: while Fitted Mesh (and Liquid Mesh) garments, etc. will deform to an avatar’s shape, items created using the mesh deformer will not; they will continue to behave like any other rigged mesh item.

This likely means that as the Fitted Mesh code does become more widely adopted, people will stop using any garments / attachables created using the deformer code, and the availability of such items in SL and on the SL marketplace will decline over time.

Whether or not this means deformer-based items will vanish from people’s inventories is something only time will tell. From the Lab’s perspective, the work involved in trying to pro-actively determine a method of identifying assets using the deformer code and removing them from the asset servers / inventories isn’t likely to be worth the end result. Therefore anyone with “old” mesh deformer garments and attachables will probably retain them until they opt to delete them from their inventory.

It appears unlikely that viewers using the deformer code will be pro-actively blocked from SL. What is likely to happen is that the code simply will not be formally adopted by those variants of TPVs which do not connect to any other grid than Second Life. However, this does leave a further interesting question as to the future of the mesh deformer, which has potentially seen far wider use in OpenSim communities than Second Life. While it would seem likely OpenSim will adopt the viewer-side changes required to enable Fitted Mesh (at least in the majority of cases), at this point in time, it is not clear whether the mesh deformer will be entirely abandoned. Whether there will be sufficient pressure within OpenSim for the deformer code to remain in use, and whether TPVs will feel obliged to incorporate the deformer into their viewers / OpenSim variants of their viewers as a result, remains to be seen. Currently, the only grid which has any kind of significant investment in the deformer is InWorldz, which provided funds for the code to be further enhanced and adopted it into their dedicated viewer in July 2013.

Materials and Numbers

Statistics are always a hard thing to determine. Back in the day, there was much controversy over figures released as to the adoption of mesh within SL following its deployment. The figures offered-up by the Lab at the time were vague enough that they could be taken to mean that mesh was either being rapidly adopted, or was seeing very slow growth (with the reality lying somewhere in between). This was not an attempt by the Lab to fudge issues at the time; it simply underlined the fact that numbers aren’t always the best means of trying to quantify something, so it’s perhaps better to allow the passage of time to speak for itself.

The most recent figures for materials suggest that over half of the regions in SL now have at least one materials-enabled item within them, and around 10% of avatars apparently utilise at least one materials-enabled item.  Again, these are figures that are likely to be interpreted either way, depending on how people look upon materials as a whole. Certainly, the term “object” is sufficiently vague so as to be pretty worthless as am objective yardstick, as it likely covers everything from an individual prim through to entire linksets, which leads to a huge variance in the visibility of objects using materials. On a personal note, I can only say I’ve made extensive use of materials in my house, and am more than pleased with the results.

I've used materials on my house; particularly on the stonework and stucco textures to prevoide added depth. Materials on the whole appears to be slowly gainly momentum
I’ve used materials on my house; particularly on the stonework and stucco textures to provide added depth. Materials on the whole appears to be slowly gaining momentum

Upcoming Code Contributions

There are a number of third-party code contributions in development for the SL viewer, some of which I’ve previously reported upon, and which are now progressing towards a point where they may well have public visibility through the likes of a release candidate in the new year.

STORM-1981 and STORM-1831

STORM-1981, contributed by Jonathan Yap, is intended to change the behaviour of tracking beacons to help make locating items in a region somewhat easier (e.g. locating lost items or scripted objects which are causing issues, etc.).  Under these changes:

  • Beacons would begin at a height of 0 metres and extend up to the maximum unassisted flight ceiling (5,020 metres)
  • The beacon colour will be blue from 0 metres to the base height of the object being tracked, and red from 5,020 metres down to the height of the object being tracked
  • Users can optionally set the beacon to pulse towards the target object using the CheesyBeacon debug setting (Advanced->Highlighting). The blue beacon will pulse up towards the object, the red beacon will pulse down towards the object.
Tracking beacons will be changing under STORM-1981, making it easier to locate objects, etc.
Tracking beacons will be changing under STORM-1981, making it easier to locate objects, etc.

STORM-1831 covers the work being undertaken by Ima Mechanic, with assistance from Oz Linden, to improve syntax highlighting in the viewer’s LSL editor by allowing the viewer to obtain the information required for syntax highlighting directly from the simulator the viewer is connected to. This should eliminate issues with the current manually updated files used to manage syntax highlighting falling out-of-synch with new LSL syntax as new functions and parameters, etc., are added. Folded-in to this work should also be a change to the source code text allowance in the viewer’s LSL editor, increasing it from the current 65,000 characters to around 256,000.

The server-side cap updates required for both STORM-68 and STORM-1831 have been combined and passed into the simulator release stream, and while it is unclear as to when the cap updates will reach a server-side release candidate package, their progress is being tracked. Obviously, both STORM-1981 and STORM-1831 require viewer-side updates as well, and these will hopefully appear in viewer release candidate form once the server-side updates are sufficiently deployed.


A number of TPVs include the ability to specify the default permissions applied to a new prim object (cube, cylinder, torus, etc.) on creation. STORM-68 aims to add a similar capability to the LL viewer (and which will quite possibly supersede the capability in TPVs once implemented). This work is again coming from Jonathan Yap, although it requires server-side updates, which Andrew Linden has been taking care of. However,  this work has hit some problems in viewer / server interactions, which may be down to timing issues between requests and acknowledgements being sent between the viewer and  the simulator and vice-versa. As such, further testing is required, so it’s possible this work might take a little longer to appear in the new year.


Fitted mesh: “LL’s assessment here is mostly good” – Qarl

The major topic of conversation during the course of the week has been the Lab’s announcement that they have released a new project viewer which can be used to make suitably rigged mesh garments deform to match an avatars shape as it is adjusted using the viewer Edit Shape sliders. It does so by using a modified version of the avatar skeleton and collision bones, as I was able to preview just before the project viewer was launched.

Rigged mesh deforming to changes to the pectoral sliders in the Fitted Mesh project viewer
Rigged mesh deforming to changes to the pectoral sliders in the Fitted Mesh project viewer

Since the Lab’s announcement, the response from various sections of the community have been mixed. Some have welcomed the new with open arms; some have questioned the overall flexibility of the solution compared to others, some have regretted the “loss” of the deformer and some have reacted in outright hostility towards the Lab.

In terms of the technical aspects of the solution, Karl Stiefvater (Qarl Fizz), who coded the mesh deformer, took time out to leave a comment on STORM-1716, the JIRA for that project, which reads:

Several people have asked me – this seems like the best place to answer.

LL’s assessment here is mostly good. In almost all situations, the simplest solution is the best one – and collision bones are indeed MUCH simpler than the mesh deformer. As I see it, collision bones have two downsides: 1) they are substantially harder to use for the person creating the garment and 2) probably don’t track as well to the avatar shape.

In the end, the evaluation must be made by the content creators who use the tool.

I will reiterate that the two-year delay and refusal to communicate are unacceptable.

Avatar collision bones (image courtesy of Gaia Clary)
Avatar collision bones (image courtesy of Gaia Clary)

This would seem to be a reasonable assessment. The use of collision bones is technically easier and, as noted elsewhere, is less reliant upon a large amount of code being added to the viewer which then needs to be managed and maintained as the viewer evolves, but it does have some drawbacks.

Commenting further on the subject in the Metareality podcast on Friday November 22nd, Karl added:

It [the avatar skeleton] already had a bunch of these bones in it for collisions. I have never, ever notices that someone shoots a bullet at me, and my avatar is fat, it actually hits me as if I were fat … It’s incredible that they put that kind of detail into it ten years ago. But, OK, they did. So my feeling – just to head-off any drama – is that it’s a nice solution. It is definitely a simpler solution, which is preferred in all software engineering, and probably all of life.

He went on to reiterate the fact that a downside of the approach is that it can making creating and rigging mesh garments harder, although as William Reed Seal-Foss observed:

Well, speaking from an artistic standpoint … and knowing how to rig, that’s already not fun, and it’ll make it more not fun, but it’s not going to be like you have to learn to do something new.

Pressed on the matter, Karl reconfirmed that while the Fitted Mesh approach may have weaknesses, he does feel that it is a good solution, noting, “Obviously, I’m invested with the one that we did, but this is good. This is good,” before also noting that as a technically simpler approach, Fitted Mesh is likely to hold-up better over time when compared to the deformer.

This still leaves the question as to whether personality may have played a part in the Lab’s decision. In the podcast, Kimberley asks Karl outright if he believes this to be the case, and he indicates that he believes so, stating, “I heard back from two different people inside the lab that told me that Linden Lab would never accept my code.” One would very much hope that matters weren’t influenced on the basis of personality; but the fact that the Lab previously rejected code from Karl for reasons which appeared tenuous at the time, would seem to be point to there being an issue of some description.

The debate over the pros and cons of each system will doubtless carry on in some quarters, as will the theories as to why one was selected over the other. In the meantime, feedback on the Fitted Mesh viewer is being generated and the Lab is working on updates. In terms of the technical aspects  / limitations of the system, it remains to be seen how they may impact things. As it is, the approach has arguably been used to good effect by the likes of Redgrave and other designers and has proven popular among consumers. Hopefully the same will prove to be the case as this solution proceeds through to a release status and as it is adopted by third-party viewers.

Related Links

Lab looks to make mesh garments fit better with the Fitted Mesh project viewer

secondlifeOn Wednesday November 20th, Linden Lab surprised the Second Life community by announcing the release of the Fitted Mesh project viewer.

Project Viewer is aimed squarely at resolving the thorny and oft-critiqued issue of making mesh clothing fit a wide variety of avatar shapes, as the blog post itself notes, reading in part:

Since the introduction of Mesh to Second Life, creators have faced challenges fitting Mesh garments to the Second Life avatar. Because mesh objects are not resizable in as many ways as the avatar itself is, it has been difficult for mesh garment creators to provide garments that adapt to the shape of the avatar in the way that the image-based clothing layers do. While many creators have made heroic efforts to provide products in a range of sizes, and some have collaborated to define a set of standard sizes that work reasonably well for much of the user population, many have found that mesh garments just don’t work well enough for their avatars. Mesh garments also don’t move with the body parts affected by avatar physics.

Users have developed two approaches to address these problems:

  • Rigging garments to the “collision bones” of the avatar skeleton (often marketed as “Liquid Mesh”). This works in current Viewers for some body parts, but there are some avatar shape parameters that do not have corresponding collision bones, so garments do not adapt to fit everywhere on the body.
  • The “Mesh Deformer” project added code to the Viewer to dynamically compute how to modify each garment shape by looking at how the vertices of the avatar were changed from that of the female and male base shapes.

The Linden Lab development team has studied both approaches, and compared their effectiveness, maintainability, and performance. Neither approach completely eliminates the occasional need for an alpha clothing layer to prevent small parts of the avatar skin from appearing through garments, but both work quite well at resizing garments so that they fit the avatar and move naturally with it. While the collision bones method requires the creator to do some additional rigging, we have decided that because it leverages more of the existing avatar shape system it is likely to be the more maintainable solution and to perform better for a wider range of users.

While the two current approaches to fitting mesh clothing are mentioned in the blog post (“Liquid Mesh” and the mesh deformer), it’s worth pointing out that the “Liquid Mesh” solution is actually based on an idea first demonstrated by RedPoly Inventor as far back as June 2012 – and it turns out that his approach is the one that the Lab, via Oz Linden, acknowledge as the one that first got them “started down the path of using collision bones to do this.”

At the time Liquid Mesh first appeared, there were concerns as to its impact on the market and the potential for content breakage should it prove popular only for something like the mesh deformer to eventually arrive in Second Life, prompting calls earlier in 2013 for the approach to be blocked by preventing mesh rigged to non-standard collision bones from being uploaded.  At the time, the Lab remained silent on the matter, although many did blog on the potential pros and cons about the approach, including myself. Strawberry Singh not only blogged, but produced a video showing her testing a pair of boots she’d purchased which utilised the capability.

Prior to the launch of the Fitted Mesh project viewer, I was fortunate enough to be given the opportunity to preview it, and get to try out some sample clothing to see how it works. I don’t pretend this is a comprehensive review of the viewer, the new collision bones or skeleton; nor is it intended to compare / contrast the Lab’s approach to other methods. It is purely intended to provide an overview of the viewer and how suitably rigged mesh garments are handled.

The New Bones

As noted in the LL blog post, the project viewers includes an additional set of collision bones alongside the familiar set of bones. These are:

  • BUTT *
  • LEFT_PEC *

* These bones are affected by avatar physics.

All of these bones, and the original avatar bones, now affect mesh clothing when the avatar shape sliders (Edit Shape) are manipulated, thus giving mesh clothing which is rigged to the avatar skeleton the ability to adjust with the avatar shape as the sliders are adjusted, thus leading to a better “fit” for the clothing.

Content creators are invited to begin experimenting with creating garments rigged to the new skeleton. To assist creators in this, a Rigged Fitted Mesh wiki page is under construction, which includes information on the existing / new collision bones, links to the male and female .fbx, .ma and .dae files, and basic instructions on getting started with creating fitted mesh, including a link to downloading the avatar skeletons and to additional external resources.

Do be aware that this wiki page is a work-in-progress, as is the viewer, and liable to both update and change.

The Viewer and a Quick Series of Tests

There are a number of important things to note before going too much further. The first is highlighted in the Lab’s blog post, and is this:

At this time, the new skeleton should be considered provisional and subject to change; we do not yet recommend selling or buying garments rigged to it. Since we may find reasons to improve it during this testing process, and any change to the collision bones will likely break garments rigged before the change, we want to make sure that we have a set of bones that we can all live with into the indefinite future before it is widely used.

The second is that as with RedPoly’s original approach and Liquid Mesh, the approach will not entirely eliminate the need for alpha layers – but then again, it’s unlikely the mesh deformer would have entirely eliminated them, either.

The third is that the viewer obviously will not work with either unrigged mesh or rigged mesh which does not make use of the new collision bones (or additional bones intended to work with the appropriate sliders).

As the test clothing passed to me was for male avatars, and presented some of the usual problems when used with a female shape (and given I have very few mesh garments in my inventory, unrigged, rigged, liquid or otherwise), Oz kindly popped over and gave an initial demonstration. As he was already wearing a mesh jacket, he quickly played with the sliders to give himself a more portly shape – with the result that his mesh jacket (as expected) no longer fitted. However, when he swapped to the rigged t-shirt in the pack, it more-or-less fitted off-the-bat.

Oz, looking more portly than his usual self, demonstrates the new project viewer and collision bones. His mesh jacket (l) which is not rigged to the new bones, fails to adjust to his altered size. The t-shirt which has been rigged to the bones, however, does (r)
Oz, looking more portly than his usual self, demonstrates the new project viewer and collision bones. His mesh jacket (l) which is not rigged to the new bones, fails to adjust to his altered size. The t-shirt which has been rigged to the bones, however, does (r)

Continue reading “Lab looks to make mesh garments fit better with the Fitted Mesh project viewer”

Liquid Mesh: looking from all sides

I’m prefacing this article by saying I’m not a fashion blogger, nor am I particularly fashion-oriented SL purchaser. So this piece isn’t an examination of “Liquid Mesh” clothing from a fashion / fit standpoint. Nor is it intended to be an in-depth technical examination of the technique and how it deforms, its pros and cons, creation issues, etc. It is simply intended to offer up general information on what the technique is, what the concerns are, and how people might best determine whether it is an option for them.

A Little Bit o’ History

When the capability to support mesh within SL was first being developed, that it could be used to create clothing etc., didn’t appear to factor into the Lab’s thinking, and so how such items might be made to fit avatar shapes properly wasn’t of major concern to them. However, during the Mesh Closed Beta, a method was proposed whereby wearables could be weighed to the avatar’s collision volumes, a technique which, if used, would allow them to deform somewhat to the avatar’s shape.

Avatar Collision volumes (image courtesy of Gaia Clary)
Avatar Collision volumes (Gaia Clary)

AshaSekayi Ra notes that at the time, Prep Linden requested clothing samples weighted using the technique be passed on to him so that the Lab could take a look at the idea. However, she didn’t hear anything further on the subject, despite supplying samples herself. Asha also thinks that Prep may have heard of the technique as a result of a conversation with RedPoly Inventor.

Collision volumes are essentially a simplified version of the avatar form primarily used to between your avatar and other avatars / objects. As Gaia Clary recently explained, they give a rough approximation of an avatar’s shape and they can be adjusted via the Edit Shape sliders. So, clothing items weighted to them can be adjusted somewhat in line with the avatar’s shape.

That said, there are limitations. For one thing, there are only 19 collision volumes; and this limits how and where they can be weighted by default, and how well clothing using them can deform with changes to the avatar’s shape. For example, there is no collision volume for breasts, so clothing using the technique won’t deform to breasts or breast size changes.

In June 2012, RedPoly Inventor again drew attention to the idea during a Content Creator’s meeting, releasing a video of the technique, as well as a demonstrator dress.

By his own admission, the solution was not perfect due to the lack of suitable weighting points in the collision volumes, as noted above. To overcome this, he suggested the development of addition “bones” (weighting points), which he called “cbones”. However, given there is generally little appetite within the Lab to tinker around with the avatar to any great extent, it was unlikely this latter idea was going to be taken-up, and after a while the use of collision volumes for mesh weighting / deformation seemed to quietly slip away.

Moving Forward

Since then we’ve had yet more delays with the development and release of the mesh deformer for a wide variety of reasons. That no official deformer has appeared has seen a number of content creators producing mesh wearables which use collision volumes for weightings / deformation in a manner similar to that demonstrated by RedPoly Inventor.  Perhaps the first on the scene was Redgrave, back in late 2012, with their Liquid Mesh range (the name which is now synonymous with the technique), with others such as Egoisme and Bax also producing their own items as well. As such, the debate around the approach has been ebbing and flowing for a while, and has recently seen renewed discussion.

The system isn’t perfect, as noted above; the need for alpha layers isn’t necessarily eliminated for example, and because collision volumes are only a rough approximation to the avatar shape, problems can still be encountered when making shape changes even where the two do align. But even with the potential shortfalls, the fact remains that in many cases, this method can result in clothing items which do fit an avatar’s shape more reasonably than by purely relying on a set of “standard sizes”, as Strawberry Singh demonstrated in a recent video which accompanied a blog post on the subject.


Continue reading “Liquid Mesh: looking from all sides”