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.

STORM-68

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.

SL project updates: week 49 (3): Fitted Mesh, AIS v3, Oculus Rift and more

The following notes are taken from the TPV Developer meeting held on Friday December 6th. A video, courtesy of Northspring, can be found at the end of this report. The numbers in braces after each heading (where given) denote the time stamp at which the topic can be listened-to in the video.

TPV Developer meeting (stock)
TPV Developer meeting (stock)

Release Channel Viewers

Name Updater Release Candidate

[00:17-01:40]

The Name Updater RC viewer, also released on December 3rd, has been updated to version 3.6.12.284506. This contains no functional changes to the viewer itself but contains two sets updates, hence the odd name.

The first of these is a fix for the viewer updater where problems can occur if a new update to the viewer is downloaded by the updater but deleted somehow prior to  the installer itself being executed. The second set of updates cover:

  • Changes to how the viewer packaging is done and cleans-up how the viewer channel (used to recognise the viewer and allow it to connect to the SL servers when logging-in) is distributed and established
  • Makes some changes to the viewer start-up parameters
  • Changes the package names to a uniform format which is the same for all of the operating system platforms.

The aim of these changes is to further improve the viewer build process and reduce the number of places changes have to be made in order to change the viewer channel name when building different flavours of the viewer (LL’s own or a TPV).

The RC has been performing well in terms of low crash rates, etc., and looks set to be promoted to the de facto release viewer in week 50 (week commencing Monday 9th December), and so will see-out 2013 as such if this is in fact the case.

Google Breakpad

It is possible a further Google Breakpad RC may appear in week 50.

Maintenance Release Candidate

[02:00-02:16]

The Maintenance RC viewer 3.6.12.284430, released on December 3rd  suffered an abnormally high crash rate, prompting it to be withdrawn in order for it to be looked at and crash issues diagnosed / fixed. Once these issues have been dealt with, the viewer will be returned to the release pipe.

Project Interesting Viewer

[39:24-41:07]

The Project Interesting (aka “viewer-interesting”) RC viewer has been in RC for a while and is suffering a high number of crashes, which are currently being investigated by the Lab. Unlike the Maintenance RC viewer, it has been left as an RC simply because issues are being found with it, because of both the number of people using it and the broad range of systems on which it is being run and which the Lab couldn’t possibly account for in their own testing.

At the moment, the Lab are trying to put together an update for the viewer, but they still have a couple of “pretty serious” crash issues which have yet to be resolved. However, the hope is that this may actually make it out into the world before the no change / code freeze window comes into force  on Monday December 16th, which affects all server releases and all viewer release channel releases. This would allow the updates made to get further “in the field” testing during the code freeze / holiday period.

That both the Project Interesting and Maintenance RCs are experiencing issues is something of a validation of the new viewer release process introduced by the Lab earlier this year, in that the problems being encountered with both of these viewers are not blocking the viewer pipe, unlike the situation of just over a year ago, where a series of crash issues with the old beta viewer completely halted all significant viewer updates.

Fitted Mesh Project Viewer

[02:20-03:16 / 32:05-39:20]

As noted in part 2 of this week’s report, the Fitted Mesh project viewer received a set of updates (including new avatar skeleton files) in the form of release 3.6.12.284458. The project viewer has so far received a very low number of downloads – somewhat unsurprisingly – with the total number of people using the viewer thought to be under 2,000. This means that it hasn’t as yet been used widely enough to generate meaningful crash statistics.

The response to the skeleton changes within the viewer has been “good”, and the viewer has seen a reasonable number of JIRA issues raised under the FITMESH project, etc., although the Lab cautions against anyone using the changes contained in the viewer in anything other than an experimental version of their own viewer until such time as the code reaches a Release Candidate status. The latter will not happen before the end of 2013, although there may be a further project viewer update for Fitted Mesh before the end of the year.

One thing which may happen when the viewer is approaching a release status is that it will bring with it a “significant bump” to the viewer version number, not the least of which is because users on viewers without the code may see some bizarre, or at least oddly fitting clothing on avatars using garments weighted to use the new system, as noted in my launch preview of the Fitted Mesh project.

Overall, it appears that the Lab is “pretty happy” with the way the work is developing, although they would like to see more people involved in using / testing the viewer, particularly anyone proficient in rigging mesh garments, etc, especially given the nature and state of the project, as Oz Linden pointed-out:

This is one of those times when things are in flux and can be changed… We have never made changes to the avatar skeleton casually, and we’re making a round of changes now; we’re wildly unlikely to make another round of changes for years. So if there is feedback to be had, this is the time to have it.

So if you are a creator and do have an opinion on how things might be better handled within the Fitted Mesh solution, now is the time to be involved and potentially influencing the Lab’s thinking. not every idea put forward may be taken-up; but on the other hand, waiting until the changes have been made and the viewer released will certainly mean that any ideas someone may have will have passed their sell-by date.

The Delay in Opting for this Solution

Part of the general feedback voiced when the Lab announced the Fitted Mesh viewer came in the form of questioning why it took the Lab so long to reach the decision to go with the approach. Part of the reason appears to be that mesh deformation and Server-side Appearance projects required the same expertise with the Lab to be applied to them, and so were vying with one another for manpower – and the decision was made to give the SSA project priority.

Oculus Rift Update

[24:46-26:26]

During the Server Beta meeting on Thursday December 5th, VoidPointer Linden indicated the work on making the viewer operate with the Oculus Rift headset was now “feature complete”, and that a (presumably project) viewer will be appearing “soon” with support for the headset. How soon is open to question, given VoidPointer had to be somewhat circumspect. However, following the TPV developer meeting, it appears that “soon” might actually be a little more in the realm of “later” than may be the case.

Oculus Rift viewer: "soon" probably not as close as either
Oculus Rift viewer: “soon” probably not as close as either “real soon (TM)” or “pretty soon (TM)”!

Continue reading “SL project updates: week 49 (3): Fitted Mesh, AIS v3, Oculus Rift and more”

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

SL projects update week 47 (2): server, viewer, general items

Server Deployments week 47 recap

As always, please refer to the week’s forum deployment thread for the latest news and updates.

  • Tuesday November 19th: the Main channel received the maintenance package previously deployed to BlueSteel and LeTigre in week 46. This package comprises further infrastructure changes for the yet-to-be-announced Experience Keys (experience tools) project
  • Wednesday November 20th:
    • Magnum remained on the same maintenance project as deployed to it in week 47, but which features a further update to the grey goo fence, now only applies to objects which are both large and physical. This alteration is in response to BUG-4448, wherein it was reported that building rezzers were running up against the fence when attempting to rez complex builds
    • BlueSteel and leTigre received a new maintenance package comprising those changes deployed to Magnum in week 46, with additional bug fixes.
Server Beta Meeting (stock)
Server Beta Meeting (stock)

Notes on the Deployments

Commenting on the BlueSteel / LeTigre updates during the Server Beta meeting on Thursday November 21st, Maestro Linden underlined the last four bug fixes listed in the release notes, together with the final “new feature” item, as being newly introduced with the deployment.

With regards to the BlueSteel  / LeTigre fix for  “Vehicles containing a mesh are returned to the owner upon region crossing when destination parcel is full”, he added, “I believe the issues with region crossing on vehicles due to ‘parcel full’ should be fixed, though there’s still that bug about certain vehicles sometimes going crazy upon region crossing.”

A question was asked if the change to the grey goo fence (BUG-4448) might impact llGiveInventory object-to-object transfers. Apparently there were reports n the Advanced Scripters of Second Life that people were encountering a “give inventory failure: grey goo fence: rapid or recursive inventory transfer” warning on Magnum regions following the update.

Commenting on this, Maestro Linden said, “I checked with Simon about this one; the GGF change should only affect rezzing of objects; when you simply pass items around with llGiveInvenotry(), the object geometry data hasn’t been loaded, so it wouldn’t have the opportunity to apply a penalty. However, he thinks that if you hit the GGF for rezzing objects , the GGF may also prevent llGiveInventory() from operating.”

Maestro also indicated that new restart scripts were using during the RC deployment which displayed the restart messages in “big, bold letters”. Whether these changes are in addition to the restart message changes made by Simon Linden and deployed in September is unclear; Maestro also referenced the fact that restarts will now occur as soon as the last avatar departs a region, rather than waiting for the countdown to complete, and this was a change initially deployed in September.

Week 48 (Week Commencing Monday November 25th)

A reminder that there are no deployments / rolling restarts planned for week 48 due to it being Thanksgiving week in the United States (which also means the Server Beta meeting will not be taking place.

SL Viewer

The SL release viewer was updated on Thursday November 21st to version 3.6.11.283787 (dated November 15)  – formerly the GPU table updates RC. This release contained no functional changes to the viewer, but saw support added for the following GPU families:  newer nVidia GTX 700 series; AMD R7/R9; Intel Iris Pro  (download page, release notes).

Fitted Mesh Project Viewer

RedPoly
Redpoly Inventor, who first looked into the use of custom bones for mesh garment deformation in SL

Thursday November 21st also saw the release of the Fitted Mesh project viewer 3.6.11.283899. This viewer includes a new avatar skeleton with additional collision bones which allow mesh garments rigged to the collision bone structure to adjust with changes to an avatar’s shape using the Edit Shape sliders.

The system is modelled at the approach first mooted during the Closed Mesh Beta and later prototyped by RedPoly Inventor, and which has been subsequently employed in approaches such as Redgrave’s “Liquid Mesh” range of garments.

The official blog post on the release can be read here, and I was fortunate enough to be given preview access to the viewer a little ahead of the launch, and my own overview is also available.

This approach to fitting mesh garments is still at a project status, and those trying it are requested to file any issues they have via a JIRA to the Fitted Mesh project.

Other Items

Copying Large Numbers of Items to the Inventory of an Object

Many people are likely to be familiar with this issue: select  a large number of items from inventory and attempt to drop them into the contents of a prim in a single go, and part / all of the process may fail. This is a long-standing problem, and there had been something of a limit of around 42 items which could be successfully transferred into an object’s contents in a single go. However, there have apparently been renewed reports of problems, and a suggestion that the threshold for moving a large number of objects in a single go may now be around the 30 mark. Maestro Linden has updated a bug report from Dan Linden on the issue with this information in the hope it will assist in narrowing-down the possible cause.

Aircraft Region Crossing Issues

Yuzuru Jewell reported further issues with some aircraft encountering problems on attempting to cross regions. It takes the form of aircraft using mono scripts with collision detection  are failing to cross region boundaries. A similar bug has been reported for mesh vehicles – BUG-4084 is “Mesh car starts to bounce like pinball after sim crossing”, but the Lab has been having problems reproducing that issue.  One workaround that seems to prevent the problem is for the collision event to be moved to a separate script compiled as LSL2 rather than mono.

In the discussion Maestro noted this approach had also been put forward in dealing with BUG-4084, except that in that case, all scripts were being compiled as LSL2, possibly because the issue hadn’t been identified as perhaps being with collision event handlers. Maestro believes the pointer towards collision events may well  be an interesting lead and has requested that anyone able to reproduce the issue and show that specific events / functions are responsible, it will obviously make it easier to determine a resolution.

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 3.6.11.283899 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 *
  • RIGHT_PEC *
  • LEFT_HANDLE
  • RIGHT_HANDLE

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