Category: SL User Group Meetings

Mesh deformer and standard sizes: Qarl speaks

Posted on by Inara Pey

There has been much in the way of heated debate on the subject of the mesh parametric deformer and standard sizes for avatars of late. So much so that in this week’s Metareality podcast, Kimberly Winnington (Gianna Borgnine in SL), deformer coder Karl Stiefvater (Qarl Fizz in SL) and in-world content creator Cathy Foil discussed the debate at some length and touched on other aspects of the deformer project.

The following is a summary of the core aspects of the discussion, presented in the panelist’s own words. My thanks to Kimberly for allowing me to produce this piece.

[2:10] Kimberly Winnington (KW): As it stands now, mesh items have to be built to the default avatars like the Ruth Avatar and then be deformed.

[2:32] Karl Stiefvater (KS): There’s a slight difference between Ruth, the actual Ruth – a lot of people call different shapes “Ruth”,  so that’s a bad term to use – and the important shape, the one that you get when you say, “Hey, I want to do a shape!” and you don’t touch any of the other dials … and I call that the “default shape”.

[2:58]  KW: So as it is now, clothing has to be built to that default shape before it can be deformed.

[3:04] KS: Right.

[3:05] KW: And it’s been suggested it should … that group of things like the default avatar should include some sort of standard size as well, even though that’s not officially a feature at this time.

[3:22] KS: That is correct. The rationale there is the deformer isn’t perfect and if you start with a shape that’s closer to your end shape before you actually tweak it, you can get superior results … Even if the deformer worked perfectly, when you design a shirt with a floral print … and you put it on someone with their body weight turned all the way up … the floral print is going to be distorted … So with the new system, the artist could say, “I’m going to repaint that floral print so it doesn’t get stretched out.”

[4:19] KW: There’s this fight going on. Emma Gilmore, also known as Elie Spot – she is of course on the standard sizing side, she was one of the people who worked with a bunch of other designers and came up with the standard sizes. And then I guess on the other side of the argument is Maxwell Graf … he’s on the side that the standard sizing is a marketing ploy and is awful and we shouldn’t even tolerate its existence. And I guess I’m somewhere in the middle of those two arguments on the basis I kind of agree with the standard sizing – not as the official solution because I don’t want to change my avatar …  so I’m all for the deformer and do not want to have standard sizing as the only solution.  However, I would have a much better chance of fitting into something without a lot of stretching if I stretched from a size that was closer to my avatar than the default avatar …  But I still think that it’s at least a solution that should be discussed; where the starting-off point for the deformer should maybe be closer to a standard size.

[6:56] KS: It sounds like you and I are in agreement …

[7:15] KW: The other thing that came up was … Emma was talking to you about possibly having a way they could convert current meshes without having to re-upload, and you had suggested to her that she post on the JIRA and get some feedback from some other people. So the problem became she posted on the JIRA and she posted a Plurk about both these issues. like let’s discuss where we should start from and lets talk about whether we should be re-uploading or converting and how should we do that … So it started this huge fiasco where everybody kind-of attacked her both on the JIRA and totally all over Plurk, and were like, “you’re wrong, you shouldn’t be posting here…” … I actually agree with her and think she has a good point; but whether you agree with her or not, the topics she brought up are important for us to discuss as a community, especially designers and people who want to wear mesh. Because once the thing is final – you know how things go in Second Life; it will come out and everyone will be unhappy with it but it will be too late to do anything about it. So you have to do it now …

[9:59] KS: The deformer isn’t perfect. There are problems and what she’s proposing … is an extension … so it doesn’t take anything away from what you had before; it’s just adding new features. So how can you hate something that has everything you want but has this extra thing that somebody else wants? How does that engender white-hot hatred? I don’t understand.

[10:36] KW: I think there’s two things. I think the first on is not understanding that it works in collaboration with the deformer. So I think there’s a lot of people…they hear “standard sizing” and they are automatically like, “No”, without understanding that it’s not going to work like standard sizing is now … that you have to fit to that standard size.  This is just in collaboration with the deformer, and I almost want to name it something else….

[11:03] KS: How about “alternate bases”? … Alternate bases, everyone.

[11:14] KW: The other thing that comes up is that a lot of people feel like that if we make a solution that fits … then Linden Lab will stop trying to think about trying to create a new overall avatar mesh.

Karl Stiefvater (Qarl Fizz)

[11:47] KS: I don’t thing that we’ve forced them to do anything ever … They’ve never given in, ever! So I don’t see that as a smart strategy … One thing I want to add to this, tho, is this other aspect  that I don’t think anybody knows about. And that is, Linden Lab, internally, is … struggling with a question that is probably going to delay the deformer even more. And that is, they don’t know if they like the default avatar as the base. They think there might be a better base. … Then the question is, so how do you pick a better base? Some of them are suggesting … that adding curves is easier than removing curves, so if the base was something that had no boobs, that had no curves or shapes whatsoever, that might perform better … But they have no system in mind for making this call. So this is like one of those objections that can never be necessarily resolved, which is very dangerous for the project. So one of the things I like about this alternate bases idea is it neutralises this potential problem, because if they think there is a better base avatar, we can just add it later. As soon as they decide what that perfect base is, we’ll just add it to the list. So it’s beneficial for reasons completely unrelated to the whole fight right now, so that’s something to keep in mind. That’s mainly why I’m sort-of leaning this way … because it kills two birds, and one of these birds is otherwise potentially project destroying.

[14:23] Cathy Foil (CF): Is it possible to have the content creators load-up their own custom bases for their mesh? Would that be possible? Or would they have to create their own blend shapes so they work with the sliders?

[14:40] KS: No … they would have to use the existing shapes, the existing parameters. But they could specify their own set of parameters; that’s doable, but I’m a little bit afraid that that’s over-designed … so I think that maybe down the road that’s a good option, but I think for right now just a set … just six or seven different bases….

[15:16] CF: I did have a wackadoodle idea I wanted to put forward. I know it’s probably way too late in the development … right now you have the avatar mesh is driving the deformer of the mesh clothing, and I thought of the idea of having “deformer underwear” so to speak,  an invisible mesh that you wear so that the avatar’s mesh deforms the underwear but then the underwear deforms the clothing mesh … so that the designers could create custom underwear that would only fit over certain parts of the avatar if they wanted or they could have more vertices in the underwear that would spread out the deformer so that they would deform the clothing mesh maybe a little bit more evenly.

[16:08] KS: That’s a clever idea … but no it’s too late for that! [laughs] But that’s interesting and that could definitely be in version 2 … Then clothing could work on avatars that are completely alien, you know, something you couldn’t dial around … like an elephant .. you could create an elephant avatar and then your hoodie or your dress would fit…

From here, the discussion moved out to talk about design techniques before moving on to the remaining topics of the podcast. For those interested in the mesh deformer and the ongoing debate, I thoroughly recommend listing to the podcast in its entirety, which also includes issues such as DMCA, copyrights and a discussion about the use and impact of the SL Marketplace.

Related Links

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

Posted on by Inara Pey

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

Mesh Deformer update: release from Qarl, request from Oz

Posted on by Inara Pey

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.

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

Posted on by Inara Pey

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

Pathfinding: llVolumeDetect(TRUE) and Land Impact changes

Posted on by Inara Pey

There are a couple of changes in the works relating to the forthcoming arrival of Pathfinding in Second Life.

llVolumeDetect(TRUE) Exploit

In the first, the use of llVolumeDetect(TRUE) to create partially phantom linksets will no longer work. Always something of a system exploit / hack, this approach has nevertheless seen widespread use across SL in buildings and vehicles. So much so that when it was discovered that the hack no longer worked in the Pathfainding test regions, it was initially reported on the JIRA as a Pathfinding bug (Pathbug-69).

However, as Falcon Linden points out in the “bugs” JIRA:

Thanks for your interest and passionate comments. First, let me address one of the root issues here: reliance on undocumented behavior that is known to be a bug. I realize that there are many cases of this in SL. I also realize that all of us, as game developers either in RL or SL, will do whatever it takes to implement a feature we want, even if that means exploiting known bugs or idiosyncrasies. The problem is that continued development of a platform (e.g., SL) often precludes backwards compatibility, particularly when systems have exploited “micro details” of the platform. 

Which is not to say Linden Lab is unsympathetic to the issue. Far from it; as in the same statement Falcon goes on to explain:

All of that being said, we as SL developers continue to try to preserve backward compatibility where we can. In this case, I have been able to find a compromise between new features and existing content. Here’s how it will work:

1) If a linkset uses the hack and also uses new accounting (aka mesh accounting or land impact), the first time it is rezzed on a pathfinding sim the hacked prim will be set to physics shape type none. Since the linkset already uses new accounting, this will not negatively impact land impact (in fact, it might reduce your land impact). It may affect a small amount of content that relies on link number of higher numbered prims in collision events by way of llDetectedLinkNumber()

2) If a linkset uses the hack and does NOT use new accounting, the relevant prims will be modified such that they collide only with the terrain. Other than that, behavior should be unchanged. This may impact some land vehicles that previously had hacked phantom prims which did not collide with the terrain.

3) No new linksets can be created that use the hack, and any linking or unlinking event (other than seating an avatar) will remove the hack on existing content.

This should address most of the concerns here. In the future, to create content where only some prims are involved in physics collisions, you will have to use the physics shape type feature.

Ergo, while the arrival of Pathfinding will herald a closure of the llVolumeDetect(TRUE) exploit / hack, LL are attempting to ensure that the impact of the closure in terms of content breakage will be minimal – if it is noticed at all.

Changes to Land Impact Calculations

Coupled to the above change is the announcement that Linden Lab is looking into changing how Land Impact is calculated as a part of the overall Pathfinding roll-out. Nalates Urriah was the first to break the news on the proposal, which  will bring a greater degree of granularity to Land Impact increases.

Under the current system, adding scripts to linksets can result in a sudden (and sometimes dramatic) leap in the Land Impact value. With the proposed changes, this will no longer be the case, with changes resulting from the use of scripts being more gradual. Speaking at the Simulator User Group meeting attended by Nalates, Falcon Linden explains the proposed changes thus:

[17:00] Falcon Linden: Changes to Land Impact that you’ll actually like for a change!
[17:01] Falcon Linden: We’re changing streaming cost for prims to be capped at 1.0 and we’re changing server weight to be: 0.5 * num_prims + (0.25 * num_scripts) but capped at num_prims
[17:01] Falcon Linden: so instead of going from half prim count to prim count by adding one script, it will be a more gradual change to encourage fewer scripts
[17:01] Falcon Linden: right now it’s not capped 
[17:03] Falcon Linden: okay
[17:03] Falcon Linden: here we go
[17:03] Falcon Linden: I have here a linkset of three distorted torii
[17:03] Falcon Linden: The two child prims are shape type NONE and the root is convex hull
[17:04] Falcon Linden: under the current scheme, its download weight is 13.7, its physics weight is 1.6 and its server weight is 1.5
[17:04] Falcon Linden: total LI 14
[17:04] Falcon Linden: under the new scheme, download weight will be 3, the other weights will be the same in this case, and the overall LI will be 3
[17:05] Falcon Linden: if I add one script to it now, the server weight will go from 1.5 to 3.
[17:05] Falcon Linden: In the new scheme it will go from 1.5 to 1.75.

It should be noted that the latter change is still very much a proposal, although it does appear that it is more than likely to go ahead, given it is beneficial to both Pathfinding and the platform as a whole.

With thanks to Innula Zenovka.

Mesh Deformer 0.3 code available

Posted on by Inara Pey

Update: Sometimes working on multiple posts to your blog isn’t a good idea. Between drafting and pushing this one, Qarl updated his code, as Cinders points out. Sorry Qarl! Correct link is here. 

Slightly later than he’d hoped, but keeping to his promise, Qarl has released version 0.3 of the Mesh deformer, stating:

Quick announcement – I’m releasing version 0.3 of the deformer code. Primary changes: 1) should now apply cleanly to recent linden viewer code, 2) deformation tables are computed in the background on another thread, so no frame stalls.

There appear to be a couple of elements missing from the patch – as spotted by Henri Beauchamp in a comment following Qarl’s post, so developers may want to hold-off grabbing the code for a bit.

I’ll be watching the various Viewer blogs for updates to see when the patch is incorporated. It’s likely to make an appearance in the likes of Cool VL and Dolphin very rapidly, providing the code is stable. Niran V Dean is planning to make a Full release of Niran’s Viewer 1.33 in the next couple of days, so this might also see the code included – we’ll have to wait and see.

Linden Lab had a Development Viewer in the offing for the deformer. This actually dates back to January, but didn’t get any further than an optional development Viewer due to assorted issues. Marine Kelley, who uses the V.3.2 reported that she’d removed the deformer from her last release due to crash issues, which may be related to reasons why LL never moved the code further along their Development cycle. However, as Qarl appears to have specifically addressed some (or all) of the issues, we may yet see the deformer appearing in something like an official Project Viewer sooner rather than later.