Mesh Deformer Update 2013-16

If you didn’t read through my index of or listen to the Metareality podcast What is the Problem?!?, you missed Karl Stiefvater’s comments on the mesh deformer. Karl was addressing a point that has come up in JIRA 1716.

Its in the math... by: AJC1 @ Flickr

Its in the math… by: AJC1 @ Flickr

In some version of the Mesh Deformer Project Viewer there was a significant delay between the time a mesh garment was worn (rezzed) and the Deformer started deforming it. In some cases on some computers that was 2 to 4 minutes.

These tended to be older computers, high polygon count mesh garments, and an earlier Project Viewer. When I say hi-poly, some skirts have way more polygons than the entire avatar. I’ve seen some boots with a single boot that has more polygons than the avatar. I can turn on wireframe and the mesh is so thick it looks solid.

No matter what we do, there will be some delay before the Deformer can start deforming ridiculously high polygon count garments.

But, discussion in the JIRA, which is not supposed to happen and why it got locked down, is that something better has to be done to eliminate the delay. The proposal is that the calculations the Deformer does to create the matrix for deforming a mesh garment be cached on the SL servers and sent to other viewers, perhaps saved with the mesh garment.

I thought if one really does have to cache the calc’s to get acceptable performance then may be save them with the Appearance in the new Server Side Appearance (Baking) process currently being worked on. It is already going to be caching appearance and forwarding it to viewers as needed. So, it seems reasonable to cache any appearance related things there. Of course that would add a significant delay to the development process for the Mesh Deformer.

In last week’s podcast Karl says those talking about caching the calc’s don’t know what they are talking about. Well… that’s certainly true of me in this case. The quote of Karl from the audio is: “With a little bit of effort the viewer side could be made faster. [I suppose meaning the deformation calc’s could be faster.] And it wouldn’t be an issue at all. Whereas if you store it on the server that is a huge amount of data. It is more than the mesh data itself.

That suggests we would be more than doubling the amount of data that has to be downloaded with mesh garments. Karl is telling us it is faster to calculate the needed values on the viewer side than attempt to calc, upload, store, and download the calc’s… and I would assume that means in a general sense it would require more time to just download them than calc them.

You probably know that avatar appearance has been and currently is baked on the viewer side. After almost 6 months of research the Lab decided that that process could not ever be reliable enough to avoid bake-fail. For that reason they went to work building server side avatar appearance baking, now called SSA: Server Side Appearance.

The proposed calc, upload, save, and send as needed for Deformer calc’s is very similar to the viewer side avatar bake process we use now. While we can’t know all the problems the Lab found with the avatar bake process, I think this is similar enough that the Lab will not think well of caching Deformer calc’s. Especially if the viewer side calculations are only a problem for poorly designed mesh garments.

So… no caching of the calc’s.

2 thoughts on “Mesh Deformer Update 2013-16

  1. Would caching it server side not prevent the mesh from moving with avatar physics and facial features? I know this was not the intent of the deformer but it was a nice perk. Also could a malicious viewer not upload bad cache data leading to a griefer issue, or possibly just a badly coded viewer?

    • Whether it were cached server side or calc’s by the viewer one would be supplying the same data to the Deformer. So, I don’t see it would make a difference to the operation.

      If it were cached, there would have to be some server side protections to check what viewers send.

      But, that apparently is not going to be an issue.

Leave a Reply

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