Darien Caldwell is working on what I call the second phase of the Mesh Deformer. A bug in the Deformer has come up in that process. I suppose this is a minor bug… it is easy enough to work around. But, one does have to work around it and know about it. I talked with Darien in the Open Source user group meeting, which Oz Linden rescheduled then didn’t make it to. 😛
Darien has posted an explanation of the bug in STORM-1716, which anyone can see and most can post to. This is the comment:
Darien Caldwell added a comment – 18/Oct/12 2:15 PM
Good news: I’ll be pushing out my addition to the deformer for selecting arbitrary shapes to deform against sometime later after this post.
Bad News: I seem to have uncovered an issue arbitrarily defined shapes brings to light.
This may be lengthy.
There are certain sliders that already deform mesh, pre-deformer. They are the sliders associated with armature bone length, and so are a bit special.
Those sliders (and their default values) are:
The problem I am seeing is that the deformer isn’t taking these bone length deformations into account when doing it’s calculations. As a result, any deviation from these defaults in a custom deformation base shape results in deformation errors.
I have attached some photos to illustrate. I created a mesh ‘skin’ as I have been doing, but instead of to the default shape, I created it against a very ‘non-default shape. (see non_default_test.jpg). It has a variety of slider settings, but for the purpose of this, know that it’s Height is 1 and it’s Torso Length is 90.
The mesh is uploaded with this base shape as the ‘custom’ deform base, and all is almost well, except the breasts are about one breast length too low on the avatar. (see Thin shape – Height 1 Torso 90.jpg)
I was puzzled at first but soon saw a correlation to the bone lengh sliders as you can see from some combination pictures;
Thin shape – Height 1 Torso 50.jpg
Thin shape – Height 53 Torso 90.jpg
Thin shape – Height 53 Torso 50.jpg
As we get more of these sliders back to the default values, the deformation gets more expected.
Now the stranger part.
The pictures above were taken of just the upper half of the mesh ‘skin’, what the viwewer calls “upperBody”. By itself the problem is very disinct. But this is a good analogy of a jacket.
However, if I join the upperBody to the lowerBody before export, and upload that as one mesh, the bone length slider issues seem to vanish.
Thin shape – Height 1 Torso 90 but joined to lower half.jpg
Thin shape – Height 53 Torso 50 but joined to lower half.jpg
This has some implications, depending on if it can be fixed. If it can be fixed, then yay! But if it can’t be fixed, then items created for use with the deformer will have to be constructed so these already-deforming bones are at their defaults. Not a deal-breaker, but certainly a caveat.
Also I should add the very large non-default tests i’ve done so far, don’t have similar issues. It seems mostly prevalent when the mesh is going from smaller to bigger. (Reference)
So, this part of the work is nearly complete and the code will be ‘pushed out’. I think that means there will be a test viewer somewhere.
Darien suspected this problem was in the Deformer. Using the Default Base Shapes it does not show up. Using custom base shapes it will show up. So, now that Darien has made it possible to upload custom shapes, we will be able to see the problem… well those working with the project viewer and testing the Deformer will see it. The problem won’t be in SL proper.
What’s the Problem?
Some bone changes via the Appearance Sliders are not handled by the Mesh Deformer I call version 0.4, the September version. That Deformer assumes the bone sizes and there was never a reason not to. So, it seems the bone size change in the shape is just not handled by the Deformer code. However, the viewer will deform weighted mesh when the bones change. The Deformer will handle the other deformations. So, the end user is not going to see a problem… provided creators do things correctly.
Aaaah… What’s Correctly?
I’m so sorry you asked… you did ask, right? Have I ever pointed out curiosity killed the cat? Furries beware.
It is hard to explain the problem and have it make sense. I have trouble getting my head around it. So, I’ll explain the process to get around the problem and hope you figure out what is going on from that.
As I understand it… the problem is about the default shape and the future base shapes we can make in SL. This is, of course, just for the extreme size shapes, large and small. But whatever, make a shape. Then before exporting to an XML file change the bones to the sizes given in Darien’s comment above. The Height: 53, Body Thickness:32, Neck Thickness:42, Neck Length:50… etc. All eleven have to be set to default values. Then the shape can be exported to the XML file. It not going to look the way you want it, but… it will get there.
Here I’m going to make a bit of a change and get off step-by-step to explain the Blender side. If I were using a special shape, I would export it as an OBJ file using the old Phoenix 1.5.2 (1185). See: Second Life Mesh Clothes Blender 2.6 Setup 2012 Tutorial – Page 4 and scroll to: Third Party Viewers. That would let me take the target shape into Blender or other modeling program as a base for my model. But, I am unclear on that part. It might be that I will have to export and use the shape made after setting the bones to defaultvales and model on that. I just don’t know and cannot yet experiment. More about that as we go on.
Once the model is made it can be exported from Blender then imported to SL using the XML file with the shape based on default bone settings that you exported. Once the mesh item is in SL you can wear it and set the bone sizes back to your desired settings. You should get the result you want. The viewer will handle the deformations based on the bone settings and the Deformer will handle the other settings. All this is SUPPOSED to work…
If one uses a shape in Blender that has the bones sizes at their final vales I would expect the UVMaps to be optimal sizes and most nearly match the target settings within SL. However, if one must use the shape in Blender that has the default bone settings, it seems the UVMap would be off. Whether it is off enough to make a difference, I don’t yet know. I’ll have to do some testing to see how it works.
I don’t really know whether this is a problem with Karl’s Deformer or if considering the problem as part of the original project is just pushing the project way beyond its original scope. I think adding the alternative base shapes was beyond the original scope. So, I don’t know if Karl will be willing to make this additional change to the Mesh Deformer or not. While it would be nice of him to do so, I don’t see this as something he is obligated to do. It also seems we can work around the problem easy enough.
Also, this problem has just come up… so there may be fixes that Darien has not considered, doubtful but probably possible. Also, it is only a problem for creators. I don’t want to minimize that… making mesh clothes is already a challenge. This will certainly add to the learning curve and it is hard to explain. Both of those things are going to make it a problem for the Lab that is doing all it can to keep a complex subject simple… they are trying… aren’t they?
It is too soon to get our hands on a new viewer… I think. But, soon we can test this and see if it is TOO MUCH trouble or whether we can live with it. The Lab will also be deciding whether they can live with it. They may decide to fix it… or not.
It’s going to take some time to even understand the problem and even more to find out how it will be handled.