Qarl Fizz change his code posting and the missing parts are up. So, presumably Third Party Viewers have the code and are able to compile viewers with the feature.
Henri Beauchamp’s Cool VL is likely going to see a new version release today.
Henri Beauchamp 4.25.12 / 10am
New patch ported to the Cool VL Viewer and working fine (a new release including it will likely be published tomorrow or the day after).
The issue with “jumping meshes” (see my comment for v0.2) is yet still not solved (but I implemented a work around for it in the Cool VL Viewer, that at least doesn’t trigger the “jumping mesh” issue with avatars not wearing deformed meshes).
I was unsure what Henri meant by ‘jumping mesh.’ I have seen mesh winking in and out of existence using Niran’s viewer… whatever, reading the referenced comment:
Henri Beauchamp 3.20.12 / 4pm
There are two problems with the current implementation of mesh deformers:
1.- it causes some avatars wearing rigged meshes to “jump” up and down annoyingly every 10 frames or so, even when their mesh is not deformed.
2.- it causes huge ‘hiccups’ (frame freezing) when many avatars wearing deformed mesh rez (for example, after a TP with avatar wearing defomed meshes.
Problem #1 is in fact in the current viewer mesh code that causes the “jump” sometimes, when rebuildRiggedAttachments() is executed. Since your code adds such a call to LLVOAvatar::updateVisualParams() and since the latter function is called periodically for each avatar, the jumps happen for any avatar wearing rigged meshes with a non-zero offset.
I implemented a workaround for the Cool VL Viewer (it will be in the upcoming v188.8.131.52 release), which only calls rebuildRiggedAttachments() from updateVisualParams() if the avatar is actually wearing a deformed rigged mesh, but the true solution would be to call rebuildRiggedAttachments() only if an actual change happened in the visual parameters.
For problem #2, you could perhaps throttle the deformer tables creation to one every few frames (which would cause deformed mesh to “fully rez” (be tailored) progressively). Another solution is to optimize the code (perhaps would it be possible to use SSE2 ?…).
Also releasing will bel Niran’s. The NiranV Viewer will likely release on 4/27 according to Niran. (Reference)
The Chalice Yao NaCl viewer, which is mostly intended for Chalice’s and friends’ use, will include it.
Firestorm will not include it according to Ansariel Hiller of the Firestorm Development team. (Reference)
Firestorm will not add this feature until it’s officially released in Linden Lab’s viewer because it falls under section 2.k of the Third Party Viewer policy.
I disagree. But, it’s the team’s decision as to how they interpret 2.k to apply here. If they want to exclude it for this reason, they can.
2.k : You must not provide any feature that alters the shared experience of the virtual world in any way not provided by or accessible to users of the latest released Linden Lab viewer.
I don’t see that it changes the shared experience, as I see a different render only in a viewer with the feature. The feature makes no change to the data in the Linden Lab® servers, the shared experience. What one using a standard LL viewer sees does not change because I use a viewer with the feature. I thought Oz was clear on these points. But, the Dev’s do get to talk things over with Oz in private meetings… at least to some extent.
I don’t expect to see it added to the Exodus Viewer any time soon, but they may surprise me. I understand they are or one of them is working on changes to the avatar. So… contributing to this project in a different way.
In the comments on Qarl’s post is another interesting point regarding the possibility of having a switch to select various base avatars on which to base the mesh deformation. Quoting:
Darien Caldwell 4.25.12 / 9am
I’m a little confused by some statements being made in this thread:http://www.sluniverse.com/php/vb/general-sl-discussion/72081-qarls-mesh-deformer-latest-news.html
Seems some are saying the base shape will be variable? How would that work? Would be nice to get some clarification.
qarl 4.25.12 / 10am
there’s been a proposal to allow for alternate base shapes – a male base, and possibly multiple sizes for both male and female. sadly this work was not scheduled in the original bid, so it’s unclear how it will be funded.
but the idea is to simply allow an additional parameter when uploading the mesh – along with the existing “please deform” option, a second option to specify the base shape.
The emphasis is mine.
I take it to mean that is not part of Qarl’s scope of work as he sees things. Second Life users will likely try to keep pushing features into the project. I see the use of various base avatars as something never thought of when the project started. Even the render-no-render flag may not have been thought of at the time. In hindsight the render flag seems too important and basic a part not to be included. But, selecting which avatar to base the Deformation on is more of an optional thing. Welcome to the grey world of software development.
Since Qarl is developing the code, it is pretty much up to him. So, I don’t expect to see this base avatar choice any time soon.
There is some drama playing out. For now I’ll avoid it, just know it is causing some annoying delays. Also, as usual, the drama divides Second Life users. 🙄