STORM-1800 avatar vertex weight discussion.

[Siana Gearz]

Hai.

Mr. Oz Linden asked us to move a long-winded discussion about avatar vertex weights from the JIRA entry elsewhere, so i'm opening it here.

https://jira.secondlife.com/browse/STORM-1800

The vertex weights determine how much each vertex is affected by its closest bones of the avatar skeleton, thus determining how sharply an avatar bends in animations at joints. Excessive creasing of stomach, shoulder and thigh area when animated in SL Viewer is all down to bad vertex weights.

In my viewer, Singularity, modified vertex weights from this JIRA entry are aready deployed, under license of original contributor, Alison Alena. There are some issues with new weights that may still need correction, however i believe it doesn't interfere with fitted mesh or other features. You are welcome to experiment and judge yourselves though, opinions are welcome.

As a word of note, i don't believe moving the discussion here as requested by Oz is reasonable - i think anything pertaining to whether and how an issue is to be implemented belongs on the JIRA entry. But we don't have much choice in that matter.

[Siana Gearz]

Medhue, the way it works: there is the base skeleton, it's what, 20-ish bones. The base avatar mesh is rigged to this skeleton. Vertex weights specify, for each vertex, how much it is affected by the two base skeleton bones closest to it. When vertex weights are modified, the skeleton itself is not modified.

You should also keep in mind that in the middle of any major bone, the weight of nearby vertices is always 100% to this bone and 0% to other bones. So whether in motion or statically, no major features of the avatar mesh can be affected by vertex weights, only the specific crease where two base skeleton bones connect is affected.

You may be wondering, how it works with only two bone weights at all. Well, i can tell you that it can't work perfectly. All professional grade systems use three-bone or higher-degree weights as they allow better crotch and shoulder connections, where at least 3 bones are in proximity of the crease. However, the SL avatar is limited to two.

On top of base skeleton, there are other bones, such as for attachments, volumetric bones, and Fitted Mesh bones. They depend on the base skeleton, but do not depend on vertex weights. The avatar mesh is not rigged to any of these. Attachment creators in Second Life do rig their meshes to both these bones and the base skeleton bones though.

[Medhue Simoni]

Weighting avatars and their clothing is an "exact thing", not a "that's good enough thing". Yes, it is true that the default avatar is not the most pleasant avatar to rig clothing to, but a good rigger can get the weights to be almost exact, with little to no poke through.

Yeah, Fitted mesh is a monstrocity and it is nearly impossible to get perfect weights, but changing those underlying weights will still have a negative affect on all old fitted mesh clothing and all standard size rigged clothing. Whether the affect is acceptable to you is your own opinion. In my opinion, Fitted Mesh is not acceptable, at all, yet LL released it. So, yeah, if you don't give a crap, like LL, then you'll accept anything.

What if some1 paid me hundreds of dollars to make them a clothing item that fits them perfectly? I have actually done this for a few clients now. What about all the rigged clothing that has already been made, that are not Fitted Mesh?

I was for this correction before Fitted Mesh, because I thought LL would make a good solution that every1 would love and convert all their clothing items over to. Now, I see this is never, ever going to happen, as LL created pure junk, that is never going to be acceptable for most of the community. Instead of Fitted Mesh being a solution, it is just another option for clothing creators to choose from.

If LL wants to pull back this Fitted Mesh BS, and make it actually usable, then I'd not have a problem with implementing the better weights, as the current weights are truly horrendous.

[Perrie Juran]

---

Siana Gearz wrote:

Hai.

Mr. Oz Linden asked us to move a long-winded discussion about avatar vertex weights from the JIRA entry elsewhere, so i'm opening it here.

https://jira.secondlife.com/browse/STORM-1800

The vertex weights determine how much each vertex is affected by its closest bones of the avatar skeleton, thus determining how sharply an avatar bends in animations at joints. Excessive creasing of stomach, shoulder and thigh area when animated in SL Viewer is all down to bad vertex weights.

In my viewer, Singularity, modified vertex weights from this JIRA entry are aready deployed, under license of original contributor, Alison Alena. There are some issues with new weights that may still need correction, however i believe it doesn't interfere with fitted mesh or other features. You are welcome to experiment and judge yourselves though, opinions are welcome.

As a word of note, i don't believe moving the discussion here as requested by Oz is reasonable - i think anything pertaining to whether and how an issue is to be implemented belongs on the JIRA entry. But we don't have much choice in that matter.

---

I read it also and I agree with your assesment. 

I'm not a techy nor a creator but I've been following  the subject for quite a while.  I do understand that OZ is not obligated to explain to us the details behind his decision to go with Fitted Mesh over the Mesh Deformer but that appears to be very central to this issue.

From everything I've watched and read, unless the Deformer is going to cause major lagging issues, as a user I'd much rather have it.

I could say a few more things but I'll leave it at this, "So much for transparency."

[Medhue Simoni]

---

Siana Gearz wrote:

As a word of note, i don't believe moving the discussion here as requested by Oz is reasonable - i think anything pertaining to whether and how an issue is to be implemented belongs on the JIRA entry. But we don't have much choice in that matter.

---

I agree completely with you here. At the same time, like Oz, I don't want 50 emails about people going back and forth about BS. That said, Oz's scope for what is acceptable to talk about in the jira's seems to be extremely narrow. IMHO, LL needs as much conversation in jiras as possible, as I have little faith that they know what they are doing. Heck, they ask us every time they need meshes to test. That should tell you something about how they run their business.

[Siana Gearz]

Unfortunately i do believe rigging mesh in SL is a "good enough thing".

You can rig a mesh to a very specific shape to follow it 100% exactly, however people don't usually wear a specific shape, a mesh is usually made for a variety of shapes. Other issue is that this invites z-buffer fighting because the GPU cannot reliably determine which of the surfaces has precedence. Because of very deep z-range in SL viewer, the z-buffer precision is particularly terrible in SL, it's only good down to about 0.2-0.5cm at typical avatar viewing distance. The reason is that the viewer must be able to render objects as far as 1km away, and as close as your own boobs in first-person-view mode. Commercial titles do a multi-pass approach where for example your own first person view hands/weapon aren't rendered together with the rest of the scene at all, and don't share the same z-buffer. Also parts of the scene further than 200-500m away are also usually rendered separately. This involves gameplay and artistic design specific to the z-buffer ranges chosen for these up to 3 distinct rendering depth ranges, because intersections between these cannot be resolved - your weapon is always going to appear in front of your immediate surroundings, and the far-range objects are always going to appear behind your immediate surroundings. That is, the objects assigned to either of these 3 ranges cannot intersect themselves with objects assigned to the other range, which is not a guarantee you can easily make with user-generated content not designed with these limitations in mind.

So with rigged mesh design, you have practically two choices - either leave ample room between mesh and avatar, or prevent parts of avatar from being rendered using an alpha mask.

[Siana Gearz]

I can give you some insight why i advocated that deformer not be implemented as-is, and i believe this point of view was shared by at least some of the responsible Lindens i spoke with. Basically, with SL, for every thing you add, you need to think: how bad will it be once everyone starts using and abusing it? And get limits into the system.

Deformer worked at good performance in isolation, however, it has potential to quickly go bad with no good way to limit the issue. If a lot of people were wearing mesh deformer in crowded locations, the performance would tank badly with no way to salvage it. It's a performance dead-end. I had offered also an idea for a solution for that, but it would have needed to be deployed before mesh deformer.

The bad point is interaction between deformer and avatar physics. Every movement of boobs requires update of the avatar mesh. These are a few thousand vertices, it's a quick calculation, and it's a small upload of a new mesh to GPU on every frame, or as it stands, every few frames depending how far an avatar is from the camera and how many avatars there are in view. It gets much worse if deformed mesh needs to be re-calculated. The calculation itself is reasonably lightweight, it takes less time than pushing new geometry to GPU, and could be optimized further. However, combined with mesh attachments usually being much denser, having usually tens thousands of vertices as opposed to default avatar's couple thousand, this will saturate the link to the GPU with some avatars around making use of it, considering we're already nearly saturating it with different other kinds of information we upload to GPU every frame.

.oO(i should note, that the main memory to GPU bandwidth is really about 1-3 GB/s and we're not technically saturating it, but together with memory bandwidth overhead, driver overhead, vertex buffer overhead in the viewer, we are really limited by what we can push to GPU with codebase as it is, or perhaps even by principle of  what we have to do with truly dynamic data, it's a bit complicated but the point stands that we can ill afford to keep adding to it, particularly with no well-defined upper bound)

A possible countermeasure is reduction of avatar physics resolution for avatars with heavy deformed mesh, however i think the results would be unsatisfactory and visually surprising.

The solution i had in mind is abolishment of current avatar physics code which updates the avatar geometry from morphs, and instead implementing it with jigglebones. Then, default avatar could be a normal mesh, technically implemented with almost same code as current rigged attachments. In addition to the base avatar bones, it would be rigged to jigglebones to drive the avatar physics movements, and near-100% compatibility with existing avatar physics wearables can be retained. Currently, avatar physics is very unreliable visually, so hard 100% compatibility is hardly a worthwhile goal, the results will depend on framerate and number of surrounding avatars, but with near zero physics cost, it can be made absolutely consistent easily, and nigh indistinguishable to how it would behave in prior system for a given framerate. You could say that the current system isn't even 100% compatible with itself because the results vary so much, if you were so inclined. Due to this change, the mesh creators would have to also rig their uploaded meshes to the same jigglebones, if they want avatar physics to apply to them. This should not break prior valid rigged meshes, because they didn't support avatar physics anyway. For mesh deformer functionality, a new deformed mesh would need to be calculated once at load-time, and the expensive framewise updates would no longer be necessary.

I think Qarl Fizz didn't do due diligence with regard to mesh deformer. He delivered an incomplete, underperforming proof-of-concept implementation. It wasn't good in crease areas and did the most trivial thing there, i think some research into area influence or lowpass algorithms would have been prudent, and at least a demonstration of work done, even if they would have proven of little advantage. While it would have been an excellent solution if better developed, i'm not surprised it didn't go in, it couldn't have. The handful of lines of trivial, slow code delivered, is really disappointing for the sum he got paid.  I think the other things he is known for also haven't been thought through quite as well as possible - flexis should have been a system with perhaps a handful of matrices and skinning instead of full geometry update - it wouldn't have looked exactly the same, but close and would have been hardware accelerateable, but now we're stuck with what we have. Furthermore, this would allow to flexify ANY rigid object at no further overhead, be it a tortured prim or a sculpty or even a mesh! Sculpts are OK, their complexity is well managed, but his initial implementation was also bad, with unreliable OpenGL readback, good thing this was overcome.

[Medhue Simoni]

I've rigged quite a few clothing items for SL, and what you are saying doesn't match with my experiences. Yeah, you can use alpha layers, and should, when you can. The problem is that you can't do that all the time. In most cases, you can't use Fitted Mesh at all. The only case where Fitted Mesh works well, is if you cover the whole section. If you want some skin showing in some key areas, just give up and use standard sizing. If you have a top that only covers 1 arm, you can't use alpha masking on the other arm. 1 of the designers I rig for make a pair of short shorts with a bikini bottom sticking out. We could not use an alpha under the bikini bottoms. We ended up not making it fitted mesh because it couldn't work with fitted mesh. There was far too much skin showing. It's like LL didn't test Fitted Mesh at all. Of the dozens and dozens of clothing that I have rigged, only 2 did I allow to be released with Fitted Mesh. Everything else works better with Standard Sizing.

Since the release of Fitted Mesh, I've been considering proposing, to all the designers that I rig for, that we do custom sizes. It's not hard. Fitted Mesh is a failure, so why not. I can do it quickly, depending on the outfit. It's all about how low I can get the pricing down, and what people are willing to pay for it. Really, my only big fear is that LL will up and do something stupid, like change the default weights. IMHO, I don't think LL will ever implement this change, as they haven't touched the jira since it was written, but you never know with their track record.

 

[Medhue Simoni]

The perfect solution would have been to allow clothing creator to import their own morphs for their clothing. It would be easy to create morphs to fit any size avatar possible, and give the customer more fitting options. Heck, 1 outfit could have become many different outfits. Besides being the best solution for mesh clothing, it would have also been an awesome thing for normal meshes. LL wanted to spend as little time as possible on the mesh clothing solution, which is exactly why we got this Fitted mesh monstrocity.

[Connor Nowles]

Just for fun.. An example of what it actually can look like.. both are rotated forward -20, no vertices have been moved, only "moved" by weightpaintting.. I just put a texture on the modified avi to see the texture distortion.. :-)

[leliel Mirihi]

Flexi pre dates Qarl by a year. Also while you could blame some of that on Qarl LL has made the same mistake dozens of times throughout all aspects of SL. The company has a history of rolling out proof of concepts that were poorly thought out and often caused more problems than they solved. I think it's more a structural problem within the organization than the failings of any one person other than their inability to fight the system.

[Siana Gearz]

---

leliel Mirihi wrote:

Flexi pre dates Qarl by a year.

---

Are you sure? I'm too young to have experienced flexiprims being introduced first hand, but i heard a lot of times flexiprims being attributed to Qarl. Just googling "flexi-prim qarl linden" brings up a lot of publications (such as stories about Qarl being fired, introductions before interviews with Qarl, stories about mesh deformer) which attribute flexiprims to him specifically.

This isn't of any particular regard though, as well as what he has or hasn't done, how well or how badly. I veered off. The technical state in which he delivered mesh deformer and the disappointing amount of effort he seems to have put into it is probably one of those reasons why it's not in, which was my point.

Project dynamics is to be considered too. When someone contributes something on their own time, and he ran out of time or willpower to get it finished and polished, next person may acknowledge the effort, and in turn contribute their effort to the project. When you have a paid developer who underdelivers, nobody in the community will bother. Why? I'm gonna be honest. Jealousy is a part of it. Thinking if he gets paid, i should get paid too, but since i won't be paid, i'm not going to help.

And yes, i understand, 5 grand is nothing, it's a good bit less than my monthly salary [when i have one]. I would have expected myself to deliver more in a month though, and i would definitely work longer and under industry rate, if the trust of community was at stake, if passion is involved, if my only purpose isn't to just pull money out of someone, twiddle the thumbs for a while, and then see things crash and burn. I'm not a disgruntled ex-Linden after all.

Aaand sorry, i went into rantmode again -.- super sorry!

The solution with separate morphs and setting a versatile standard, moving the intelligence into the tool code and/or into the hands of the creator, as pitched by Geenz, was actually a good one. It too had the potential GPU upload path bottleneck issue though, something had to happen to limit the resolution of rigged mesh artificially for that not to be an issue, or a refactoring of avatar physics as i pitched.

I do think Fitted Mesh was also rolled out politically, in a hurry, and without careful consideration of whether it is ACTUALLY the proper idea. One proof is that clients shipping fitted mesh fail across the board on many ATI units across various OSes and years of driver versions, and they just brushed that aside as "driver bug" (well, what if it is - it affects a lot of people anyway, many without a viable solution!) and released regardless.

[ObviousAltIsObvious]

flexible prims, llSetCameraParams and the aborted puppeteering project were Ventrella's things. 

there was a community written flexi patch for sculpted prims, and qarl played with that, but didn't originate it. https://jira.secondlife.com/browse/VWR-9203

[Medhue Simoni]

---

Connor Nowles wrote:

Just for fun.. An example of what it actually can look like.. both are rotated forward -20, no vertices have been moved, only "moved" by weightpaintting.. I just put a texture on the modified avi to see the texture distortion.. :-)

---

This is easily the best example of why the new weights were needed, and exactly why I advocated for it for years. There is easily a dozen forum posts where I have mentioned this jira in some way or another. That said, it's not this bone combination that I'm worried about, as this would probably not affect rigged meshes that much, as it was a horrible blend of weights to begin with. It is the differences in the crotch and arm pits that would really be disasters if your mesh was rigged perfectly to the old weights.

As a creator, it is extremely frustrating to watch LL totally blunder things. Understanding that a fix like this should have been a priority from the start, is a basic thing. Yet Oz says they will look at it later. That says he doesn't understand the issue at all. Or, it says that he and the Lab are perfectly OK with having creators produce junk, not because of their own skills, but because of LL's ignorance and laziness. Who looks bad to the average user. We do, the merchants.

In my honest opinion, LL should ditch Fitted mesh, and make a big commitment to a new and improved avatar. I'm not talking about a new mesh. We can make our own avatar meshes. I mean add more bones to the avatar. Add fingers, and wings, and ear bones, and a facial rig. This would make almost every custom avatar as versatile as the default. Then, they should implement a mesh morphing system, whether inworld, or imported. The avatar is the center of the virtual universe for every single user. That is where LL should spend their time.

[Connor Nowles]

I somehow like the defauld weights on the avi.. If we add some blood, it would look like broken ribs sticking out of the chest.. Kind'a cool :-))
I believe it is said, it won't be fixed because it would break content.. But i sometimes wonder what content and how much content it would actually break...
If we look at texture clothes, that is created on the uv map so it looks good on the avi in a T pose, and then it deforms as the avi bends... With new weights it would just deform alot better..

With rigged mesh if we look at the chest, mesh rigget to the standard weights does not bend inwards like the avi also does not do, so with new weights on the avi i don't think it would be a problem.. There is also alot of problems on the rest of the avi, but not as oveious as the chest, i think the rest of the avi would only give minor conflicts if any at all...
But ofcourse there can be custom weights people made where there maybe would be conflicts if the weights on the avi was changed.. But still, i wonder how much..

If we look at fitted mesh, in wich i am no expert.. I can however see that good weights on the avi somehow follow good weights on fitted mesh..
this image below is not the avi, it is the avi as fitted mesh where i work on the belly, And the weights on the chest area are exactly the same on the modified avi and on the fitted mesh.. And it somehow seems to be true for the rest of the avi also..
And on top of that it also bends well at default size when looking at animations..
However making it fit the avi with all sliders seems to be imposible, that is pure "bleep".. :-)
But ofcourse now we also already have many different fitted mesh weights out there.. But would it give conflicts, i don't know.. new weights on the avi does not change how it deforms with the morph.. Atleast i don't think so, i don't know everything.. :-)
There can be many reasons for not fixing it.. :-)

But i do know that it will not be fixed, it is pointless to complain about it.. And in some way i can understand LL, people tend to complain no matter how much they get.. However the avi is nr1, it is what most people relate to, it is big buisness, it is the first thing people see when they join and think wow or think damn this looks crappy and leave again.. If i were the boss the avi would be nr1 priority in every way, it is the most important object in sl without a doubt and should be as flawless as possible...
But it is a nice discussion / conversation.. Or what ever.. Sry, i'm not english.. :-)

[Cincia Singh]

---

Connor Nowles wrote:

I believe it is said, it won't be fixed because it would break content.. But i sometimes wonder what content and how much content it would actually break...

---

I think you can get an easy rough estimate ... just look at how many people run their SL viewer without enabling advanced lighting, wear texture hair, complain that their computers have to run SL with a < 32m draw distance and all sliders set to low and you get a feeling for how many people are using very old content for both their avatar clothing and attachments in SL. I have ALL the content I've purchased or acquired in my inventory dating back to when I first logged into SL in 2007 and I doubt I'm beyond the bell curve of residents in SL.

[Connor Nowles]

Hmm maybe i misunderstand, but i'm not quite sure why you talk about computer preformance..? Changeing the weights makes no difference to preformance.. Old weights vs new weights is same same to the computer.. :-)
And if we talk about texture clothes the current weights breaks alot more, it almost can't get any worse, new weights can only make that part better.. :-)

If we talk about advanced lightning, I or no one who i asked to enable it has had any preformance issues with it.. The issue are if the shadows get enabled with it, but the shadows can be disabled in the dropdown menu, and you can still have advanced lightning.. :-)

I may hurt some peoples feelings saying this, but SL is a computer game, and if they lag with settings on low and draw distance on 32, then maybe they should realize that they can't play computergames on a 7 year old laptop that was made just to browse websites and edit text.. :-)
It is just unreal to expect that sl should not lag if you sit with a crappy old laptop that was never meant to play games.. :-)

[Xenhat Liamano]

To keep this thread focused on the right topic... I was wondering if someone with the required knowledge could update the modified files to be usable with fitted mesh?