Further call for deformer assistance: it’s needed, but don’t panic!

Last week Oz put out a call for help with testing the Mesh Parametric Deformer than Qarl Fizz has been developing, and which is now available in a Project Viewer (as well as some TPVs).

The response to that call has been somewhat slow, prompting Oz to pass a further comment on the JIRA related to the deformer (STORM-1716):

Oz Linden added a comment – 08/May/12 8:59 AM

Perhaps this issue really isn’t all that important, or worth the trouble to integrate.

So far, only one designer has responded with one test garment.

Let me be clear – the lack of test material is a major blocker for testing, and therefore accepting, this proposed feature. If you want it, step up and do it soon.

The comment has been reported elsewhere (and remarked upon in the comments following my original piece on the call), and has caused some consternation.

However before people start taking Oz’s comment to heart as a sign that he or LL want to “kill” or “drop” the deformer, I spoke to Oz directly on the matter after reading the comment and he wryly admitted that it was intended as an attention-grabber and that, indeed, several more mesh designers have come forward indicating that they wish to engage in the testing as a result. When I asked him about the shock value of the comment, he replied, “Yeah, it was certainly intentional, and I would not have actually dropped it. But it is true that it would have taken far, far longer (months maybe).”

So does this mean we should ignore the underlying call for help?

No – we just shouldn’t panic about the deformer being dropped. Help is still needed. So, if you are a mesh clothing designer, or know of a mesh clothing designer, then please consider getting involved in the work / asking them to get involved in the work.

Related Links

Viewer release summary 2012: week 18

This is a weekly summary of changes to all SL Viewers / clients of which I’m aware and which are in popular use across the grid / listed in the TPVD. Detailed links to said Viewers / clients can be found in my Viewer Round-up Page. The links supplied in this summary are either to change logs or to reviews within this blog.

Updates for week ending: 6 May, 2012

Several updates occurred this week, with Dolphin, Niran’s and Zen in particular all making two releases apiece.

  • No changes to the official release or Beta of the SL Viewer
  • The SL Development Viewer rolled to 3.3.3.255742 on May 4th
  • The SL Mesh Deformer Project Viewer received and update (blog post) on May 3rd
  • Dolphin went through two rapid-fire releases, with 3.3.6.23776 appearing on May 1st, followed by 3.3.7.23790 on May 4th
  • Niran’s Viewer rolled to version 1.34 on May 3rd, and then version 1.35 as this update was being prepared overnight on the 6th/7th
  • Zen Viewer released versions 3.3.3.1 and 3.3.3.2 in short order on May 3rd and 5th respectively, change logs for both here
  • Cool VL Viewer rolled to 1.26.4.11 on 1st May, with change log here
  • Lumiya released version 1.3.4 on May 5th, with changes noted here.

Related Links

Mesh Deformer update: release from Qarl, request from Oz

Qarl has updated the mesh deformer. speaking in the Metareality podcast today, he states:

[57:15] I’ve pushed another version of the deformer today. It does male and female avatars; so that answers people’s questions who are upset about that. And I would say that we’re getting pretty close to the final product. If you … haven’t been following it closely, waiting for it you should check it out. 

He goes on to comment, in response to a question about what people should be looking for in using the deformer, “I don’t think regular people should check it out. Content creators should check it out, I should say that …. Because in order to use it you need to mark the mesh as being deformed, and the only way to do that is to create your own mesh and upload it.”

The update is available in a Linden Lab test build.

This may sound like, “Well, duh!” information, but the fact that the deformer is still in development and at this point really only applicable to content creators, is worth pointing out. It also leads-in nicely to the next piece of news.

At the same time, OZ has updated the mesh JIRA with the following request:

If you are a clothing designer interested in getting the mesh deformer integrated into all SL viewers, you can help both make it better and get it integrated more quickly:

We need a collection of test garments that we can use to evaluate this feature, and to form the basis of an ongoing regression test of it once it is integrated. These need not be “good looking”, and in some cases should not be (so we’re not asking you to give away your best commercial work). What we need is deformable mesh garments, based on either the unaltered “new shape” (female), or that shape changed to male; the garments should be designed to explore the limits of the technology as well as to showcase the normal easy cases.

Some examples I can think of (but I expect that you as designers and fashionistas can think of more and better):
a full length garment (ball gown, trenchcoat, kaftan)

  • garments designed to be close fitting around problem areas like the shoulders, breasts, and butt (or whatever areas you think are problems)
  • garments designed to stand away from the body in some areas (capes, high collars, flared or puffed sleeves and pants, hoop skirts)
  • very small garments that cover limited areas (gloves, shoes, scarves, shin and thigh pads)
  • garments designed to layer with each other (a close fitting shirt with a jacket to wear over it)

It would probably be useful for these test garments not to be textured for normal use — instead, give them simple high contrast patterns like checks or stripes that make it easy to evaluate how textures are altered by the deformations.

If you’d like to contribute items for this effort, please:

  • Upload them with the current version of the official Project Viewer for the Deformer. You can find a download link on the test build wiki page, and record the full version number of the viewer you used (from the Help > About Second Life floater).
  • Put a copy of the garment (no-modify is fine, but please allow copy and transfer) into a Notecard that describes what the garment is intended to demonstrate or test. Links to images of what you think it should look like would be useful; be sure to include the version number from the viewer in the Notecard.
  • Send the Notecard to Oz Linden
  • Optionally, attach the mesh file to this issue

I’d like to get Contribution Agreements from anyone submitting garments; contact me for details on that if you need them.

I will establish a way anyone can pick up copies of the test garments that we incorporate into the test suite.

The deformer itself has given rise to much debate on the current SL avatar – Nalates Urriah provides some solid insight into this; which has also lead to debates on “standard” sizing I’ve touched upon here. Part of this debate has also ranged on the JIRA – although there is a JIRA dedicated to matter of the avatar itself (STORM 1800) and Oz has requested that discussions pertinent to that aspect of things be carried out on that JIRA.

Related Links

With thanks to Pete Linden & Gianne Borgnine.

Whither Exodus? Why, heads down and busy!

There have been questions and comments on Exodus floating around in various places, with people wondering what is happening and when the next release might come out. As an Exodus user myself, I fired-off an e-mail to Clix and the team recently to see if they’d be willing to shed a little light on what’s going on.

While the reply was a little shorter than I’d hoped – but then I did ask a couple of questions on releases that the team may not want to commit to, date-wise – Clix did provide a little update:

The team has been busy with personal projects and real life commitments. Naturally this has slowed down production. In addition we have been submitting code upstream to Linden Lab that has been accepted and rolled out in the most recent official viewer release.

Exodus is being actively worked on and will feature a wide range of fixes, performance improvements as well as some neat new features. Our next release will address any and all license concerns. We will continue to produce the best TPV for gamers and visual artists in Second Life. Stay tuned for new feature announcements!

The license concerns mentioned potentially refer to J2C / KDU usage issues. Whether or not this is the case, it is fairly clear from comments passed elsewhere that there has been strong cooperation between LL and the Exodus team in sorting any problems out, which has to be seen as being a good indicator when it comes to LL / TPV cooperation in general, something that has been grumbled about by some commentators following changes to the TPV Policy recently.

One thing is very certain: given the popularity of Exodus amongst users, that the Viewer is being actively worked on will come a good news to many, so keep an eye on the Exodus blog page.

Land Impact change: “Is it a prim? Is it a sculpt? It’s a…”

Update May 14th: Speaking at the Simulator User Group meeting on May 1tth (transcript), Falcon Linden confirmed that under the new mesh accounting system, sculpts will be capped at 2: [16:43] Falcon Linden: Namely that sculpts will be capped at 2.0 streaming cost, not 1.0. (Note, that’s a CAP, so if they were less than 2.0 in new accounting before, they’ll still be less than 2.0).

Update May 5th: Nalates carries a very in-depth piece on the proposed Land Impact changes and pathfinding in general, written as a result of recent UG meetings.

Nalates Uirriah caries more on the proposed Land Impact changes which look as if they will be implemented as a part of Pathfinding – and the news carries something of a possible warning.

While the new accounting system promises to offer benefits with regards to prims, and help encourage scripting efficiency within rezzed linksets, just how it will impact sculpties is unclear.

Sculpts have always been something of a problem-in-waiting since their introduction. Like complex prims (tori, etc.), sculpts were given the same “impact” cost as “regular” prims under the old accounting (prim count) system. So wither you rezzed a cube, a torus or  sculpt, they all had an impact of 1. However, like mesh, sculpts are more complex than regular prims and could be said to be somewhat more complex than tori in terms of their download weight due to the need for a texture and a sculpt map to be downloaded and applied to the object.

When Land Impact (initially PE, or Prim Equivalence at the time) was introduced, sculpts continued to be treated as prims – although from comments made at the time, it was evident that, at least on technical grounds, some Linden Lab staff were unhappy with this. However, it is hard to see how the accounting system could have been adjusted to account for the extra “cost” of sculpt without causing mass upset and potentially some breakage across the grid.

The new accounting system that has been proposed, and was revealed in part last week by Falcon Linden as Nalates reported, is specifically to be applied to “legacy prims”.  However, whether sculpts are to be classed as “legacy prims”, it would appear, is still a matter to be determined within the Lab.

Speaking at Monday’s Content Creation Group meeting, Nyx Linden had the following to say on the proposed changes:

The proposed streaming cost cap, if implemented and deployed (nothing is final until it is released), would affect legacy prims – streaming cost of meshes would not be capped. It would affect legacy prims even if they are linked to meshes (and thus fall under the new accounting system). Please note that this is a proposal, and we reserve the right to change any part of it if necessary before release.

“Whether sculpties will be considered “legacy” or not in this context is not 100% determined yet. Since they do require more texture data to display properly, we need to carefully consider exactly how to weight them. The proposed server cost change would be independent of prim type. It’s still in the early stages so bear with us if we end up needing to make tweaks between now and release, but we wanted to let everyone know that changes would be coming.”

After noting that the new accounting process will also be used for linksets using the new physics shape types as well as those containing meshes, Nyx concludes:

“I don’t want to speculate as to the exact status of sculpties under the new streaming cost rules, as we’re still discussing it internally, but your concerns are being considered when looking at the numbers and algorithms.

The problem here of course is that LL are once again in something of a corner. Altering the impact cost of sculpts is going to have potentially far-reaching effects which are unlikely to be seen as positive. It may even negate the changes being made to llVolumeDetect(TRUE), given this hack is often used in linksets involving sculpts. At the same time, and has been pointed out by Chalice Yao, sculpts could be considered tori, so treating them as legacy prims would make the new accounting system even more worthwhile.

Similarly, Qie Niangao points out that currently, the LI calculations are somewhat biased with regards to mesh:

Yes, but on the other hand, the LI calculations are terrifically generous to Mesh content for exactly the reason that Nyx (bizarrely) mentions as a problem with sculpties: extra textures. Although it’s true that a sculpt necessarily involves a sculptmap as well as a (single) surface texture, a single Mesh can have eight 1024×1024 textures and still get a 0.5 land impact.

It is clear that things are in a state of flux – and that LL are considering options and concerns. Overall, the proposed changes are being regarded as being favourable to all at this time where script costs are concerned. Whether this remains the case will be dependent on what – if anything – needs to be changed in order to handle sculpts.

Related Links

Viewer release summary 2012: week 17

This is a weekly summary of changes to all SL Viewers / clients of which I’m aware and which are in popular use across the grid / listed in the TPVD. Detailed links to said Viewers / clients can be found in my Viewer Round-up Page. The links supplied in this summary are either to change logs or to reviews within this blog.

Updates for week ending: 29 April, 2012

Several updates this week – most from “the usual suspects” :), but also one or two changes to the Round-up page itself.

  • The SL release Viewer updated to release 3.3.1.254524 on April 24th
  • The SL Development Viewer rolled to 3.3.3.254948 on April 26th
  • The SL Direct Delivery Project Viewer is removed from the Round-up Page, as DD is launched and the Project Viewer itself has not been updated post-launch
  • The SImplified Inventory Project Viewer will remain until the status of that project (active / defunct?) becomes clearer
  • Dolphin released version 3.3.5.23763 “Fellini” in April 28th, bringing with it an adaptation of Marx Catteneo’s machinima tools (in turn based on work by NiranV Dean). I’ve run a small review here
  • Niran’s Viewer itself reached a full release on the 27th April, with a host of features and revisions which I review here. This release sees Niran’s Viewer listed on the Third-party Viewer Directory
  • Zen Viewer reached release 3.3.3.0, also on the 27th April  which includes a number of updates, including the latest release of Qarl’s parametric deformer
  • Cool VL Viewer rolled out 1.26.4.10 on the 26th April. Among the changes made is a “Rebuild avatar” feature (in Advanced -> Character) allowing to rebuild your avatar skeleton from scratch after removing a rigged mesh which deformed the said skeleton, and the latest release of the parametric deformer
  • Two rapid-fire updates were made to the Lumiya Android client on the 29th April, with versions 1.3.2 and 1.3.3 being released in short order and available through the Android Market and Google Play respectively. Each includes a number of updates & improvements.

Related Links