Mesh Deformer 2013-5

There is really no new news on this project. There is an updated Deformer Project Viewer. But the update is just blending all the other viewer changes into the Deformer Project. The Deformer has not changed, as best I can tell.

In the Metareality podcast this week Karl talked about lag from the Deformer and mesh clothes. Yes, there is lag caused by both. How much depends on how the mesh is made. Just as with other mesh objects we are finding out they can reduce lag compared to prims or increase it.

Mesh clothes are always going to increase an avatars polygon count. So, they will always add some lag. How much is dependent on how well the mesh is designed. Since there is little cost difference between poorly made and well made mesh clothes there is little incentive to make well made clothes, at least from a cost perspective.

However, there is a Draw Weight that can be displayed in the viewer. If that becomes scriptable, we can have mesh counters like we have script counters. Other than that I don’t see any limits on mesh clothes quality.

The Deformer has start up lag, meaning it can take some time before you see it kick in. High poly clothes have significant start up delay. In this case by ‘high’ I mean way higher than needed.

Well made clothes can experience 1 to 3 seconds of startup lag, but generally less.

This lag happens when the Deformer calculates the mesh offsets needed. Once calculated, it doesn’t have to be calculated again during that session. Also, that calculation happens on the viewer side. So, it is not that big a deal.

I can imagine problems for those with old weak computers. That may be part of the reason that the Lab is carefully considering the Deformer.

Oz was going to try and get staff to help him reconsider the avatar and the Deformer would have been in that evaluation. His last update on the staffing request was in his words ‘mixed.’ I get that this is an ongoing effort. But, for now, I consider the Deformer project stalled.

9 thoughts on “Mesh Deformer 2013-5

  1. There is news is as much as the viewer code has been merged to 3.4.4 and there is a new release of the deformer project viewer. No overall change in functionality from what I’ve seen, however.

    Sovereign Engineer did the merge, as I’ve covered in my last update.

    • We see that differently. The Deformer has not changed. That the Deformer Project Viewer updated to stay in sync with viewer development is not what I consider “Deformer” news.

      Semantics… you did a good write up.

      PS: I changed the spelling of Sovereign Engineer. So, if that is misspelled, it is my fault.

  2. If I understand you right “that calculation happens on the viewer side” means everyone must not only draw the basic mesh item, but must then pass clothing items through the deformer. Not a problem when you are home getting ready to go out. Could be *huge* when you TP into a club! A whole new layer added to an already slow rez process.

    • That is what I am thinking. I could be wrong.

      Until I can experience it, I am not sure how much of an issue it is going to be. I suspect this is part of what the Lab/Oz wants to test.

  3. This infuriates me.

    My question is, why do not TPV’s implement this without Linden Lab?
    Wasn’t that the point of this entire project in the first place?

  4. The solution is not that “hard” or “impossible” and you know it because I already suggested on the Deformer jira. But if you mix some developers afraid of changes with some users that aproves everything that LL says without even thinking by theirself, we will end always with this slow process of improving our SL world.

    The “fix” for that lag is pretty easy. Let the viewer save the deformartion once you wear a mesh and your PC process it. Send that info to SL servers, send it back to avatars around. Just like we have been doing with baking texture layers on our avatars since ages. Want more? Make the servers to process that info like we will do with the new bake system that will be implemented soon.

    I sometimes have some really fun reading comments of people saying how hard that could be. The deformer actually saves the xml avatar shape with it for reference of the offset deformations. This means that at the server side, changes are implemented to save that “shape” info. Why not to save a little amount of data about the deformations and offsets already computed in an avatar? God, isnt so complex, are just few KB that can be compressed and sent to servers in a fraction of seconds and be downloaded later. Not like LL hardware cant deal with that, not like is that crazy the idea.

    So the main question is, why are they so afraid of simply making this method of sharing deformer info between viewers and SL? I am not programmer, but I have enough knowledge of programming to know that if a server can share textures, meshes, sounds, animations and more, there arent any problem to get one more type of asset.

    I knew this would happen since the first time I saw those rough notes about the deformer viewer. And the reasson is pretty simple. As 3D Max user, we have a similar tool for that. That tool is not too “fast” not either is improved enought and probably not ever will be perfect because there will be always limitations. Thats why my surprise after seeing how the deformer was made in few code lines.

    But well.. things are like this, we can just say thanks for all people that support this and try to make the changes that LL never want to make. Unfortunately I doubt we will see this implemented in any TPV due the new LL policy that changed right when all this started. Now we can just hope for the project to not fall at all. I wonder what would happen with all those that contributed with donations…

    • I think part of the problem is Oz is trying to get management to consider an upgrade to the avatar. Now is a good time to make that attempt. But, I doubt Oz or anyone would say say anything because of what it would do to expectations and the backlash if the project were not approved. – This is a lot of speculation on my part.

      As to saving the deform matrix as they do avatar composite texture… The process resulted in the avatar back problems we have now. That should have worked too.

      • Yeah, we got problems with the bake texture, but that was due hardware differences (GPU). Since the deformer data will be the same from computer to computer, this “shouldn’t” make any change between different hardware because all of them will use the CPU. The only “bad” side could be when someone rez very slow and you cant get its updated deformations from the server. In which case, if the viewer isnt busy with other tasks, it could process the deformations… Oh well, I think it could be really many workarounds for this. Still any of that is better than calculate all deformations over and over. Just imagine when people enter and leaves of your draw area and memory. Can be such a chaos really.

        About that “new” avatar. You know already that people want that so bad. But even with that new avatar, you will still need some ways to sort the deformations unless it includes the deformation bones. In other words, being able to change the size of bones and not just the lenght. Something similar to what wanted to do 3DO (if Im not wrong) with the collisions bones.

        Adding more bones could be another solution. If you want your mesh to deform, use all bones, if you dont, then use the common 26 ones. Kinda dirty workaround, but as always, is better than nothing.

        Whatever the idea they want to get from all this, I hope they count with us, users, and keep telling to us what is going on.

  5. I assume this stall was about Avatar 2.0?

    Because they really should consider it before wasting too much time for something already outdated.

Leave a Reply

Your email address will not be published. Required fields are marked *