At the weekend, Tranquility Dexler, the CTO of InWorldz, Tweeted about the work Qarl Fizz (Karl Stiefvater) has been undertaking in order to implement the deformer for InWorldz, and the fact that Qarl has a patch which should enable TPVs to integrate the”fast deformer” into their code.
The link in the Tweet leads to a post on Qarl’s blog which gives further information on the project:
The team over at InWorldz recently asked if i could help them integrate the clothing deformer into their new mesh viewer. which is nice, I think, because people really want to fit their clothing. and so far they can’t.
But the InWorldz guys took it a step further – they asked if there was anything I could do to improve the code. and I said yes, it could be made faster. and they put-up a bit of money to make it happen.
Attached is a patch to the deformer code which (by my quick estimates) makes the deformation process 21 times faster. many thanks to David and McCabe for making this possible.
This has led to some speculation as to what impact the patch might have on the Lab’s work with the deformer.
I would hazard a guess and say, “Initially, not a lot.”
I say this not to denigrate LL or to suggest that LL have no interest in implementing the deformer.
Rather, I say it simply because the Lab will likely proceed at their own pace as and when the resources are available to focus on the work they have – as a result of the many and varied robust discussions held on STORM-1716 – determined as needing to be carried out before they move the deformer to a released status.
This does, however, leave TPVs with a dilemma. Do they push ahead and adopt the code, and risk issues down the road when LL start to update the deformer themselves while opting to ignore Qarl’s latest work? Or do they play safe and wait to see what the Lab opts to do?
There is some speculation that were TPVs to incorporate the code into alpha / experimental versions of their viewers, it might tip the balance towards the Lab renewing work on the deformer (and / or adopting them code) sooner rather than later. However, there is a question mark over this.
While TPVs can produce “experimental” viewers utilising code which “breaks” the “shared experience”, it has always been intimated by the Lab that they can do so only as long as such viewers don’t enter into widespread use. While it isn’t easy to determine how LL would police this in practice (block a given viewer string? Issue a warning notice? Something else?), it might deter some TPVs with larger communities from making the code available except under very controlled conditions. If so, this might serve to dramatically reduce the visibility of a “working” deformer and possibly leave the Lab free to sail its own course.
Another option for TPVs – at least those who support OpenSim – is to integrate the code into their OpenSim versions. If nothing else, adoption of the code into OpenSim versions of various viewers might in turn see a more widespread use of mesh clothing on OpenSim, something entirely in keep with the initial goals of the project.
Posting on STORM-1716, Henri Beauchamp has already indicated he’ll be taking both routes: all three branches of his Cool VL viewer will incorporate the new code but only the experimental branch will use it when connected to SL; his legacy and stable branches of the viewer will only use the code when connected to OpenSim.
In the meantime – and again, absolutely no slight towards Linden Lab – kudos to the folk over at InWorldz for moving to adopt the deformer.
Related Links
- Speedy delivery – Qarl Fizz
- News about the Mesh Deformer – Shug Maitland
- Mesh deformer coverage in this blog
My thanks to Tranquility Dexler for the Tweet, which alerted me to the work, and to Shug Maitland, for poking me to blog about it.
Inara Pey: Living in a Modemworld 
It’s always been my intention to add deformer support to Firestorm when connecting to OpenSim grids once the code was finalized and rigged mesh clothing began to be more adopted in OpenSim.
LikeLike
Never doubted it :).
LikeLike
Makes sense. That reminds me of a recent comment I read that “OpenSim looks like SL from 4 years ago”, which is completely wrong. SL and OpenSim share 99% of a common set of overlapping features, but each has something which is unique to them and which (sadly) is not present in both. Fortunately for OpenSim users, practically any new feature that LL develops becomes quickly available in OpenSim as well — often, things that had been around for a while as “experimental” (like, say, saving Windlight settings, meshes, materials…) become “core features” as soon as LL announces them.
It would be interesting to see the reverse happening, on something as eye-catching as mesh deformers 🙂 Oh, sure, there are a few things that have trickled down from OpenSim back into SL… one recent example is the LSL support for JSON processing, but since that affects only a few thousands of scripters who need it, it escaped the radar of most 🙂 (and no, it’s not the only example, just a recent one).
No, honestly, the major difference these days is that OpenSim grids lack content — specially, the amount of high-end content that is available easily in SL. And, of course, the Balkanisation of OpenSim (each tiny grid living in isolation of all others — when hypergrid teleporting works so well that it’s uncanny how it’s done, but, of course, all commercial OpenSim grid operators turn hypergrid off, emulating LL in their isolationist doctrine). Put them together, and it means that there is not going to be a massive exodus from SL to OpenSim 🙂
I’m actually being mean to LL. They have done an awesome job in increasing the overall performance of SL in all regards, while still adding tons of new features (specially since Rod is at the helm of LL). But the truth is that OpenSim is not lagging behind so much. Only a couple of years ago I was tearing at my hair about the way avatars bumped into things and behaved unpredictably under OpenSim’s unreliable physics engine. And I would yell in frustration when I changed a script inside a prim and saved it — because, in 2009, OpenSim would not save it. Nor would it allow easily to save appearance or attachments — I used to fill whole sims with prim hair that went haywire when I tweaked a parameter, and jump all over the place, and have to delete it from the database.
To show how things have evolved on both platforms, I was working on a rather complex piece of software today, which is being developed simultaneously in SL and OpenSim. I had to stop working on the code last Wednesday. Today, when I logged in, I was confused, because my avatar was supposed to be still running an attachment with the latest code, and, searching for it on the inventory, I just saw an old version. There were some prims missing, too. Confused, I started to restore things from my (external) backups and from subversion… when I realized that on Wednesday I had been working on SL, but today, I was on OpenSim 🙂
My avatar looks the same in both, except for hair and clothes — thank goodness I created my own shape in 2004, so I can always bring myself to any grid 🙂 But because I do my tests on “mostly empty” sims, using normally the same viewer, with an avatar that looks the same and has similar folders on both platforms… there are so few visual clues that I’m actually on a different platform, that sometimes I forget where I am 🙂
LikeLike
Yeah, I don’t get the “OpenSim is X years behind SL” statements from some within SL – the same way as I don’t get the fact that some in OpenSim constantly need to see everything the Lab does as being somehow deliberately aimed at either poking SL users in the eye or trying to “damage” OpenSim (a recent example of the latter being the Havok sub-licencing deal).
In mean respects, the deformer project underlines the fact that there are many more similarities between OS and SL than there are differences, and people using either / both are actually bound by the same interests / desires / goals / hopes. Right back at the start of the project, when funds were still being raised to finance the initial work, the potential for the deformer code within both SL and OS was clearly identified, discussed and embraced.
LikeLike
I just want to see 1 thing from open sim on Sl, Npc scripts!
Creating a mirror of the avatar i’m at the time, saving it to a script, making it rezz and use pose balls, walk, follow a pattern, interact with or when asked!
Is the only thing that i do miss from there, besides free content, full perms and being God on my regions!
And of course the spirit of community and help that any would find from the small but always present core of users!
LikeLike
One of the things LL has to concern themselves with is permissions on items that make up an appearance. OpenSim’s NPC appearance functions don’t check permissions. Instead, there’s a sort of honor system, and it’s expected that those functions will only be enabled for certain users who can be trusted to respect property rights. LL would either have to restrict that functionality in a similar manner, or come up with a whole other method of dressing up NPCs.
Although OpenSim makes NPCs look easy, there’s a lot of stuff behind the scenes that makes this a whole lot more complicated than it might appear. OpenSim NPCs can’t actually own anything, they have no inventory, they can’t join groups, they can’t leave the region they were created in, etc. Although they’re super, super useful in a controlled and locked down environment, there are a lot of potential griefing and implementation issues LL would definitely feel the need to address.
LikeLike
“Rather, I say it simply because the Lab will likely proceed at their own pace as and when the resources are available to focus on the work they have…”
It’s been two years since the mesh was released, and year and a half since this patch was first submitted. It has always puzzled me why you’re so protective of Linden Lab, bending over backwards from even the appearance of criticizing them.
LikeLike
I’m perfectly prepared to critique the Lab where and when it is either justified or might actually be productive.
Railing against the Lab simply because it is the Lab has always appeared to be pointless (if not entirely counter-productive) to me, as has some people’s need to launch ad hominem attacks on Lab personnel based on what appears to be a personal dislike of an individual. Therefore, I try to avoid both.
Where the deformer is concerned, there are many factors which have influenced its development and many people have their own opinions and multiple different requirements / demands have been put forward, which have often led to conflicts between those making the suggestions / demands / requirements. Ergo, the issues with the deformer are not entirely of the Lab’s own making.
LikeLike
Lack of a deformer was the main issue users brought up during the development and beta test of the mesh project. Charlar Linden who led the project at the time flatly refused to talk about it. All this is two and a half years ago. In internet time that’s like decades. The omission was so glaring that people took their own money and payed for it to be developed only for Linden Lab to ignore it for a year and a half.
How many years does it take for you to think that critique would be justified?
LikeLike
You’re prone to focus on the negative. Let’s look at the positives.
Since that time, we’ve seen scope creep, we’ve seen negative feedback on the deformer as Qarl coded it, we’ve seen demands for the deformer to handle elements outside of the original specification. We’ve seen alternative approaches, we’ve seen uninformed opinions being voiced which have at times become accepted as “fact”. All of this has led to the project being pushed and pulled in a variety of directions, which has in turn put the Lab squarely between a rock and hard place in terms of expectations and potential user backlash – particularly if they issue something which is largely perceived as “not working”, whether or not it fulfils the original specifications for the work.
At the same time, the Lab has been trying to push ahead with a long-term agenda to deal with issues and problems which have also been of significant concern to users – and like it or not, their resources are limited, and those involved in the project are not necessarily those in a position to demand resources or dictate where available resources should be directed.
If / when the Lab pro-actively states that there will be no deformer, or when they actively demonstrate that they have the capacity to overcome the current concerns they have with the code but refuse to do so, then I’ll have something to say. Whether you accept it or not, we’re not at that point yet.
LikeLike
You are prone to write long apologist essays on why Linden Lab should not be criticized. Thank you for proving my original point.
LikeLike
ROFL. If you say so, Latif. If you say so. 😀
LikeLike
You know short and sweet it the lindens grid. Mouse yells at the elephant so what. I have ported that code to 3 viewers and it works ok. I not going to get on a soap box and say it the best thing since Ice cream. It works and those viewers need more work to stay stable.
Viewer with the code in linux keeps groing up to around 2 gigs of ra, unexceptionable same viewer with out the patch is around 800 mb of ram uses. the 64 bit build swelled to 2800 mb.
this all can be fixed it takes time.
remember the very stable SL viewer in linux is running at 846 mb on my machine after 4 hours of use. that is good. storm-1716 my build of that code more than three times.
Is it good or bad. Just a mouse complaining about an elephant .
🙂
LikeLike