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.

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

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”

SL projects update week 29 (1): server, viewer, SSB/A

Server Deployments – Week 29

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

Second Life Server (SLS Main) Channel

On Tuesday 16th July, the SLS Main channel received the server maintenance package previously deployed to Magnum in week 28, intended to fix a couple of pathfinding issues:

A slight issue at the start of the rolling restart process on Tuesday 16th July meant that some regions on the main channel experienced to restarts, with the second updating to the correct release.

Release Candidate Channels

On Wednesday July 17th, the three main Release Candidate channels should each receive individual updates, as follows:

  • Magnum will become the RC with the server-side baking / appearance project enabled
  • BlueSteel should receive a further package of under-the-hood changes related to the experience tools
  • LeTigre should receive a new server maintenance project, which includes the following fixes and new features:
    • Fixes:
      • BUG-969 “teleporting breaks collision detection state for volumedetect objects”
      • BUG-2931 “run_time_permissions no longer triggers in attachments after requesting 0 permissions”
      • A further fix for the issue of pathfinding characters using CHARACTER_STAY_WITHIN_PARCEL getting stuck if they somehow exited their home parcel
    • New Features:
      • Added “RenderMaterialsCapability” to /simulator/features cap, which indicates the access rate allowed when accessing the “RenderMaterials” capability
      • Increased the “RenderMaterials” capability access rate to 4 requests per second (up from 1)

Viewer Updates and Release Process

As I reported at the time (see New viewer release process implemented), the new viewer release process went live in week 28. I’ve provided a complete breakdown of the process and what it means in general, for those who wish to know more.

This has seen a number of beta and project viewers appear on the revised Official Alternate Viewer wiki page, with updated viewers including:

  • On July 15th the Second Life Beta channel saw a new release  – version 3.6.2.278491 (release notes)
  • CHUI updates continue to appear first in the CHUI project viewer, which released version 3.6.2.278372 on July 9th
  • The project Cocoa viewer for the Mac also updated on July 15th, to version 3.6.1.278025.

SSB/A Update

In a late change to the deployment schedule, Magnum will the RC channel to have SSB/A enabled following the rolling restarts on Wednesday July 17th.

This will include a fix for BUG-3203, the “notecard bug” I reported on in week 28 (with thanks to Whirly Fizzle), wherein  if you create a notecard in an SSB/A region (i.e. a region on the LeTigre RC at the moment) and attempt to embed anything in it (e.g. LMs, textures, other notecards), the notecard will fail to save with the message: Unable to upload (asset ID number) due to the following reason: The server is experiencing unexpected difficulties. Please try again later.

Continue reading “SL projects update week 29 (1): server, viewer, SSB/A”

Mesh deformer: moving ahead in InWorldz, but will it affect LL?

At the weekend, Tranquility Dexler, the CTO of InWorldz,  Tweeted about the work Qarl Fizz (Karl Stiefvater) has been undertaking in order to implement the deformer for InWorldz, and the fact that Qarl has a patch which should enable TPVs to integrate the”fast deformer” into their code.

Tranquility Dexler's Tweet from July 6th
Tranquility Dexler’s Tweet from July 6th

The link in the Tweet leads to a post on Qarl’s blog which gives further information on the project:

The team over at InWorldz recently asked if i could help them integrate the clothing deformer into their new mesh viewer. which is nice, I think, because people really want to fit their clothing. and so far they can’t.

But the InWorldz guys took it a step further – they asked if there was anything I could do to improve the code. and I said yes, it could be made faster. and they put-up a bit of money to make it happen.

Attached is a patch to the deformer code which (by my quick estimates) makes the deformation process 21 times faster. many thanks to David and McCabe for making this possible.

Qarl: working ti integrate the deformer code into the InWorldz viewer
Qarl: working ti integrate the deformer code into the InWorldz viewer

This has led to some speculation as to what impact the patch might have on the Lab’s work with the deformer.

I would hazard a guess and say, “Initially, not a lot.”

I say this not to denigrate LL or to suggest that LL have no interest in implementing the deformer.

Rather, I say it simply because the Lab will likely proceed at their own pace as and when the resources are available to focus on the work they have – as a result of the many and varied robust discussions held on STORM-1716  – determined as needing to be carried out before they move the deformer to a released status.

This does, however, leave TPVs with a dilemma. Do they push ahead and adopt the code, and risk issues down the road when LL start to update the deformer themselves while opting to ignore Qarl’s latest work? Or do they play safe and wait to see what the Lab opts to do?

There is some speculation that were TPVs to incorporate the code into alpha / experimental versions of their viewers, it might tip the balance towards the Lab renewing work on the deformer (and / or adopting them code) sooner rather than later. However, there is a question mark over this.

While TPVs can produce “experimental” viewers utilising code which “breaks” the “shared experience”, it has always been intimated by the Lab that they can do so only as long as such viewers don’t enter into widespread use. While it isn’t easy to determine how LL would police this in practice (block a given viewer string? Issue a warning notice? Something else?), it might deter some TPVs with larger communities from making the code available except under very controlled conditions. If so, this might serve to dramatically reduce the visibility of a “working” deformer and possibly leave the Lab free to sail its own course.

Another option for TPVs – at least those who support OpenSim – is to integrate the code into their OpenSim versions. If nothing else, adoption of the code into OpenSim versions of various viewers might in turn see a more widespread use of mesh clothing on OpenSim, something entirely in keep with the initial goals of the project.

Posting on STORM-1716, Henri Beauchamp has already indicated he’ll be taking both routes: all three branches of his Cool VL viewer will incorporate the new code but only the experimental branch will use it when connected to SL; his legacy and stable branches of the viewer will only use the code when connected to OpenSim.

In the meantime – and again, absolutely no slight towards Linden Lab – kudos to the folk over at InWorldz for moving to adopt the deformer.

Related Links

My thanks to Tranquility Dexler for the Tweet, which alerted me to the work, and to Shug Maitland, for poking me to blog about it.