Mesh clothing deformation: alternative approach suggested

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

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

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

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

“That is not possible with this.”

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

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

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

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

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

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

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

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

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

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

Related Links

With thanks to Nalates Urriah.

Viewer release summary 2012: week 25

The following is summary of changes to SL viewers / clients (official and TPV) which have taken place in the past week. It is based on my Viewer Round-up Page, which provides a list of  all Second Life viewers and clients that are in popular use (and of which I am aware) and which are recognised as being in adherence with the TPV Policy.

This summary is published every Monday, and by its nature will always be in arrears. Therefore, for the most up-to-date information on viewers and clients, please see my Viewer Round-up Page, which is updated as soon as I’m aware of any changes, and which includes comprehensive links to download pages, blog notes, release notes, etc., for Viewers and clients as well as links to any / all reviews of specific viewers / clients made within this blog.  

A relatively quiet week. I’ve attempted to add summaries of what might be regarded as “core” changes / fixes to Viewers (where possible); these aren’t in any way supposed to be exhaustive – that’s what release notes and change logs are for! Hopefully, they’ll give a flavour for what has changed within a release.

I’m curious to know how many find these summaries and the main Round-up Page useful, and whether the additional information on release changes as seen here would be more appreciated if seen in the main Round-up Page.

Updates for the week ending: 24 June, 2012

  • SL Viewer updates:
    • Beta version: 3.3.3.259953, June 18 (release notes)
    • Development: rolled to 3.3.4.259223, June 9th, which adds Kity Barnett’s contributed spell check to the Preferences -> Chat (button)
  • Dolphin rolled to 3.3.10.24429 on the 25th (just after this summary came out, so I’ve updated) – release notes here
  • Kokua experimental rolled to 3.3.1.22989 Beta-1c on June 22nd, with a mesh uploader fix
  • Restrained Love rolled to 3.8.3.3 on June 24th, which includes Kitty Barnett’s spell checker contribution to LL’s official code (available in the current LL Dev release) and numerous bug fixes (release notes)
  • Zen Viewer updated to 3.3.4.2 on June 21st, core updates: additions to the Grid Manager and updates to HACD and OpenAL (release notes)
  • Cool VL Viewer rolled to 1.26.4.19 on June 23rd – core changes: Implemented an import feature for Shape, Hair, Skin and Eyes in the appearance customize floater; Exposed the “Show media HUD” option in Preferences->Audio and Video; improved the texture exporting algorithm for the Object backup feature to prevent it hanging; increased the maximum size of scripts sources from 64Kb to 128Kb; numerous bix fixes  (change log)
  • Libretto rolled to 0.18 on the 20th, core updates: fix to a “clothing not rezzed issue” and fixed avatars not being removed from radar when moving out of range (release notes)

Related Links

Viewer release summary 2012: week 24

The following is summary of changes to SL viewers / clients (official and TPV) which have taken place in the past week. It is based on my Viewer Round-up Page, which provides a list of  all Second Life viewers and clients that are in popular use (and of which I am aware) and which are recognised as being in adherence with the TPV Policy.

This summary is published every Monday, and by its nature will always be in arrears. Therefore, for the most up-to-date information on viewers and clients, please see my Viewer Round-up Page, which is updated as soon as I’m aware of any changes, and which includes comprehensive links to download pages, blog notes, release notes, etc., for Viewers and clients as well as links to any / all reviews of specific viewers / clients made within this blog.  

A relatively quiet week. I’ve attempted to add summaries of what might be regarded as “core” changes / fixes to Viewers (where possible); these aren’t in any way supposed to be exhaustive – that’s what release notes and change logs are for! Hopefully, they’ll give a flavour for what has changed within a release.

I’m curious to know how many find these summaries and the main Round-up Page useful, and whether the additional information on release changes as seen here would be more appreciated if seen in the main Round-up Page.

Updates for the week ending: 17 June, 2012

  • SL Viewer updates:
    • Beta version: 3.3.3.259197, June 12th – core fixes / updates: VWR-8761 Cannot delete object description; VWR-21538 SLVoice does not exit after viewer exits;  SH-2668 “ocean” water is always 20m high instead of the Region Water Height; SH-2689 worn mesh rezzing issues; improved language support (VWR-21538VWR-23844VWR-26542VWR-28950; implements STORM-1819, Ternary/graded shadow support (release notes)
    • Development: rolled to 3.3.4.259223, June 9th
    • Pathfinding: 3.3.2.259040, June 11th
  • Dolphin Viewer rolled to 3.3.924419 on June 14th – core changes: fixing graphics bug partially breaking UI; updates to latest LL Dev Viewer & Marine Kelley’s RLV 2.8.3.2; incorporation of  Liny Odel’s fix for SH-3153
  • Niran’s Viewer rolled to 1.41 on the 11th June – UI tweaks, Windlight preset additions and tweaks, additional work on translating panels & right-click menus; bug fixes for Viewer crashing on Invalid Texture Index and RLV/a minimap issue (release notes)
  • Cool VL Viewer rolled to 1.26.4.17 on June 9th – core changes: fixing render crashes due to objects rezzing badly / incompletely (& a hardening of render code); improvements to the Search floater; additional v3.3 code backports, including: latest LLCurl and increasing ban line height to 5000m; arrow keys can still move avatar with chat input floater open (but not focused)  (change log)

Related Links

Mesh Deformer: updates and musings

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Related Links

Kokua and Firestorm: moves and views

It’s been relative quiet on the Viewer front of late. However, there is now news emerging about two TPVs: Kokua and Firestorm.

Kokua

Nicky Perian has updated the Kokua code on Bit Bucket to release 3.1.1.22989(Beta-1), dated June 11th. Available for Windows and Linux, it is unclear as to how “official” this release is  – there is no blog post associated with the release, nor does it appear on the Kokua wiki download page. Notice of its arrival has, however, been doing the rounds on Twitter.

I’ve not had a close look at it as yet, but it appears the release is more about bug-fixing and general enhancements of the current code (with fixes code that addresses both SL and OpenSim) more than prepping a major release and shouldn’t be treated as such – or even as a recognised experimental until the team release further information. As it stands, the release still references itself in places as the “Second Life Viewer” rather than Kokua, again indicative that this is very much still a work in progress. One thing it does do away with is the console window that would open on starting the Windows version of Kokua (and which you had to keep open while logged-in to SL in order to avoid the Viewer crashing).

I’m not recommending the release be put to general use – that is down to the Kokua team; rather I’m reporting that the version’s availability has been reported on via Twitter. Those wishing to know the exact status of the project should keep an eye on the Kokua blog, where hopefully there will be an update soon.

Firestorm

After an extended period of quiet from the Firestorm end of things, I recently noticed Jessica Lyon logging back in to SL once more after what appeared to be something of a period of absence. She’s provided a blog post at Firestorm entitled “Progress Report” , which indicates that the team had in fact  eased off from development; with some taking an outright break from things, as burn-out was becoming a factor.

The announcement highlights three things:

  • The team has new developers in the form of Holy Gavenkrantz, who has been a regular code contributor to both Firestorm and Phoenix, and Armin Weatherwax who, co-incidentally enough given the information on Kokua above, was formerly a lead developer on that project
  • And update on the status of the Firestorm 4.1.1 release, which is still officially labelled “coming soon” but which will include various requested tools and capabilities including Growl support, an LSL pre-processor, additional Windlight effects an “improved build floater”, and a host of goodies
  • The news that the team is branching development for Firestorm between Second Life and OpenSim.

This last point is interesting, as Firestorm has been gaining popularity among OpenSim users (Kitely even set it as their default Viewer).

The use of Viewers to access both SL and OpenSim has been the subject of much debate in the last couple of months since Linden Lab announced they were sub-licencing elements of the Havok physics engine. This requires that any applicable Viewer using the licenced code to only connect to LL’s own servers. In May, Jessica gave a hint that the Firestorm team were considering their options vis-a-vis SL and OpenSim, commenting on SLU that:

There is the possibility that we could have Havok code disable when the viewer is not logged into the SL grid. I have asked Oz if this would be acceptable and he is looking into it. If it turns out this is NOT acceptable, we will provide two versions of our Firestorm viewer. One for SL and one for everything else.

While she has not followed-up the comment with further information directly, it would appear from the blog post that – for whatever reason – the Firestorm team has opted to take the route of developing two flavours of the Viewer. It will be interesting to see how this actually plays out.

Lumiya: manage your inventory

Lumiya continues with what amounts to almost weekly releases, with version 2.0.4 arriving  in Google Play on June 10th, bringing with it the first cut at inventory support, as well as a host of other features.

Inventory Features

The inventory capabilities comprise the ability to view your inventory; copy, rename, move and delete inventory items; edit asset permissions and the ability to share inventory with other users. The inventory display can be accessed from most of the Lumiya screens via your device’s Menu button, and uses the familiar suitcase icon.

Inventory access in Lumiya (click to enlarge)

Tapping INVENTORY will display a familiar folder list, ordered in the default System Folders to Top mode. Currently this can’t be changed, but the inventory capabilities are still evolving in Lumiya, so this may not always be the case.

As with the inventory panel on any graphical Viewer, you can navigate through your folders – simply tap on a folder to refresh the screen and show its contents. To work your way back up through your inventory, tap the BACK button at the top of the screen not the Back button on your device. The latter will quit you out of inventory and return you to the screen you were displaying prior to accessing inventory.

Also, note that Lumiya will remember your last position within inventory for as long as you remained logged-in to SL, and that it is this position that will be displayed when you next access inventory; thus it is very easy to switch in and out of inventory when performing a number of activities with Lumiya. You are only returned to the top-level of your inventory if you use the on-screen BACK button or if you sign-out of your current SL session and then log back in.

Asset information (click to enlarge)

Tapping on an item in the inventory window will display the asset information for the object (see right). If the item has any editable permissions associated with it, this screen will include an EDIT PERMISSIONS button. Tapping this button will display a pop-up where you can set those permissions to which you have access: tap on the required check boxes to assign (green tick) or remove rights. When you’ve finished, tap Save Changes at the bottom of the pop-up to save, or Cancel to leave the permissions unchanged. Tapping either will return you to the asset information screen.

Tapping either of the PROFILE buttons in the asset information screen will display the associated profile information (owner or creator). Tap the Back button on your device to return to the asset information screen.

If you perform a long touch on an object item in inventory (press and hold for a couple of seconds), a pop-up menu is displayed  allowing you to copy (permissions allowing), rename or delete the object as well as providing another means of displaying the object’s asset information.

To copy an item of inventory, display the pop-up menu and select COPY,  navigate to the point in your inventory where you wish to paste the copy of the item and then tap the SAVE HERE button displayed at the foot of the screen. Note that:

  • At this point in time Lumiya doesn’t support inventory links
  • When you have copied an item, the originating folder for the item will be displayed, not the location to which you have copied it.
Edit and create notecards in Lumiya & embed attachments (click to enlarge)

The inventory functions additionally allow you to:

  • Teleport directly to a location by tapping on the associated landmark in your inventory
  • Open and read / edit (subject to permissions) any notecards in your inventory
  • Create new notecards by tapping on the Menu button on your device and then on New Notecard. When creating notecards, be aware that:
    • The notecard will be created in the current folder you are browsing, not the notecard folder
    • You can add landmarks and other notecards to a new notecard by tapping on your device’s Menu button and then on Insert Item – this will open your inventory display, allowing you to navigate to the landmark / notecard you wish to embed; tap on the item to add it to your new notecard.

Sharing Inventory

Inventory can be passed to another user (permissions allowing) via the CONTACTS screen using either the CONTACTS or NEARBY lists to select the person to whom you want to give inventory and then tapping on their name to open an IM window.

With the IM window open, tap your device’s menu button and select SHARE ITEM. This will take you to your inventory window, where you can locate the item you wish to give. Tapping on a full permissions item will automatically transfer it to the selected individual. Tapping on a Transfer / No Copy item will generate a pop-up warning you that you are about to transfer a No Copy object; click on OK to complete the transfer.

If you are offered an item of inventory, a message will be displayed in an IM window from the person offering you the item (as with graphical Viewers). Clicking on Accept in the IM window will open your inventory window, and you can navigate to the folder in which you wish to save the item. When you have located and opened the required folder, tap SAVE HERE to save the received item. Note that you can also DECLINE unwanted inventory offers, which are discarded.

Group Notices

Group notice with an attachment (click to enlarge)

Lumiya 2.0.4 also includes the ability to send group notices (with attachments). Note that in order to use this function, you must be in a group role that allows you to send notices (be an owner of the group, for example) – if you do not have such a role, the group notice option will not be displayed in Lumiya.

The option is accessed by tapping CONTACTS and then opening the IM window for the group, then tapping the Menu button on your device and selecting NEW NOTICE.

A button near the top of the screen allows you to access your inventory to attach items to the notice – once an item is selected by tapping on it, you are automatically returned to the notice editor, and the button switches to display REMOVE, allowing you to remove the item (and replace it with another if you so wish).

Opinion

This version also sees a number of nips and tucks to Lumiya; hardware keys are now supported in the 3D world view, log-in performance has been improved for those with large contact lists, etc., all of which make 2.0.4 a further very positive step forward for the client, bringing some important functionality to the client. Currently there is no support for wearing / adding clothing and attachments, but again, this is only the first release for inventory handling within Lumiya; things will very probably improve as the functionality is enhanced.

This is also the first version of Lumiya I’ve got to use on Android 4.0.3 ICS – largely because I’ve only just got my Galaxy S2 updated. I encountered no problems running on the new OS, while overall, 2.0.4’s performance on the S2 continued to match that of earlier releases on both wifi and 3G.

With all of these recent updates, Lumiya is now firmly in the lead in providing mobile access for SL on the Android platform, making it the obvious choice for those running suitable phones or Android tablets.

Related Links