#SL Deformer Update Wk17

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

@Qarl

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

Hello Qarl

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 v1.26.4.5 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.

Additional Info

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

Darien –

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.

 Drama

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. 🙄

9 thoughts on “#SL Deformer Update Wk17

  1. The Cool VL Viewer v1.26.4.10 has been published today with Qarl’s new code and also a handy workaround by me for distorted avatar skeleton when you remove some rigged meshes (see http://sldev.free.fr/forum/viewtopic.php?f=3&p=3505#p3505 for details).

  2. The mesh deformer falls exactly under TPVP 2.k: It alters the view in a way that some people are not able to see – basically the same as the old Emerald secondary attachment spots. And Oz has clearly stated that such modifications are not allowed anymore.

    • There is quite a bit of difference. Emerald changed what I saw in my SL viewer and posted data to the the servers as to where attachments were. The current Mesh Deformer only changes what one sees in their own viewer and anyone using it will not change what I see when using a standard LL viewer. However, because the final version of the Deformer will post a use-no-use-flag to the server Oz says it will fall within in 2.k. So, he is treating it as as a 2.k item now.

      • Nalates – Oz has specifically told me that the deformer falls under 2.k whether or not it has that flag. no, i don’t understand the logic.

        • The reason is very simply: If you wear some clothing that looks okay for you because of the deformer but for somebody else it looks completely messed up (body parts sticking through etc.), then this is a different shared experience, thus it’s falling under 2.k.

          Compared to the old Emerald secondary attachment spots, this is actually the same: For people with viewers with support of secondary, everything was fine. For all others, stuff was floating around. The deformer is the same in the very end: For people with deformer, stuff looks fine, for all others it’s broken. You don’t need to be a rocket scientist to imagine this is the reason the deformer falls under 2.k – no matter how you try to turn it.

          • In the end, when the Deformer is released, your point of view will be correct. But, at the current time everyone sees the mesh the same, except the one using the Deformer. The common and LL shared experience is currently everyone pokes through mesh. The Deformer currently only changes things for those using it. That is not a change of the current shared experience. Only our individual experiences. So, I disagree that it breaks 2.k. I understand your’s and Oz’s viewpoint.

            I see the Emerald attachments as way different. Data was sent to the servers and everyone using a LL viewer was affected. The Deformer as it is now only affects the one using it.

            What we have right now is no different than my changing the gamma in my system. No one else can see that change. Nor is Niran’s viewer having a different final render a change to the shared experience or a violation of 2.k. For now the Deformer is not changing the shared experience. But, eventually it will.

            Oz has apparently taken the long term view of what the feature will be. And since it will at some point be a change to the shared experience the project falls into the scope of 2.k now, in the Linden thinking. For those working backward trying to figure out what the Linden policy means by how things work and Lindens enforce policy, the Deformer is a confusing example because the Deformer’s current and future behavior are different. Without an explicit consideration of time in a statement saying the Deformer violates 2.k now, just confuses issues.

            The work around is to label any viewer with Deformer 0.3 included as an experimental or test version. Amethyst/Niran went though that with Oz in Thursday’s meeting.

          • yes, i understand that argument.

            my problem with it is that it can be applied to nearly any change to the visual representation of the world. like shadows. (if everyone has a shadow viewer, they’ll make content which looks different/poor to non-shadow viewers.) but Oz says shadows are ok.

            so in the end, the rule boils down to “ask Oz for permission.” he more or less concedes this is the case.

  3. Pingback: Nirans Viewer Release 1.33 Review

  4. from what I see the Firestorm team is making their decision based on Oz’s statements that the deformer DOES violate 2.k until they decide to roll it out… They may personally agree with you, but until the Linden Ghods decide otherwise… >shrugs<

Leave a Reply to qarl Cancel reply

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