• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: VWR-2374
Type: New Feature New Feature
Status: Open Open
Priority: Normal Normal
Assignee: Unassigned
Reporter: TigroSpottystripes Katsu
Votes: 1485
Watchers: 100
Operations

If you were logged in you would be able to see more operations.
1. Second Life Viewer - VWR

Allow Deformations by Reading Position Information in BVH Files/Animations

Created: 08/Sep/07 07:53 PM   Updated: 04/Sep/09 12:23 PM
Component/s: Avatar/Character, Graphics
Affects Version/s: None
Fix Version/s: None

File Attachments: None
Image Attachments:

1. screenshot-1.jpg
(256 kB)

2. screenshot-3.jpg
(207 kB)

3. screenshot-4.jpg
(233 kB)

4. screenshot-5.jpg
(208 kB)

5. screenshot-6.jpg
(174 kB)

6. screenshot-7.jpg
(205 kB)

7. screenshot-8.jpg
(122 kB)

8. screenshot-9.jpg
(83 kB)

9. Snapshot_003 (Medium).png
(1.20 MB)
Issue Links:
Relates

Last Triaged: 15/Jan/09 06:05 PM
Linden Lab Issue ID: DEV-26189


 Description  « Hide

Summary


This Jira is for official support for deformations. Deformations are what moves the bending joints of the avatar to new locations, to allow for large, small and interestingly shaped avatars with joints that bend as expected. Technically: This Jira is to allow for the reading and rendering of both rotation AND position information for any specified joint from an uploaded animation.

Desired Implementation Criteria


Enhance BVH parsing, and allow positional information as an option. This allows for single-length snap-to deformations (single looping frame) as well as animated deformations (animating a limb getting longer or shorter). It also easily allows animations to be included in a deformation, meaning instead of 19 animations (18 deformations + 1 animation) the whole thing can be done in one animation.

Specifically

  • If a joint in the hierarchy data has x, y, and zposition in addition to the standard rotation, expect to have three new values in each frame of the motion data, or second half of the BVH file.
  • Use the same "not changed between frame 1 and frame 2" tactic to ignore a joint, but separate the position and rotation. If the position changes between frame one and two, deform it. But if the rotation on the same joint doesn't, activate no animation on it – just the deformation.
  • Position information can be played like animations. That is, you can animate limbs lengthing and shortening, as well as simply snapping into place with a one-frame loop. Old deformations can do this.
  • When the deformation animation is no longer being "played," the avatar returns to normal. This can be done by replacing or adding a default priority 0 animation to the avatar that includes the default position information.
  • The limits for the distance a joint can move would be no less than it is now, which is currently dependent on the joint and shape, and allows for extremely large avatars.
  • Continue to ignore the joint offsets in the hierarchy data in the first half of the BVH files. This joint position data in the hierarchy is essentially obsoleted by the appearance sliders within Second Life. Also, the data provided in the default SL BVH files do not match the default avatar, and many people use their own models in their 3D applications which generate very different hierarchy data in their BVH files.
  • Eyes can currently be deformed, as they are a bone on the skeleton. Allowing the addition of the eye into the BVH heirarchy and their deformation – and subsequent restoration, would be ideal.

Existing problems and solutions

P: After deforming an avatar playing animations, the legs will buckle when attempting to IK at the ground. By changing the avatar's shape the hip height will be recalculated – but not to the correct spot. Occasionally, different viewers will see the avatar's hip at different default heights while deformed.
S1: Preferably, the hip height should update with the length of the legs. This would mean that existing animations can be used on a deformed avatar. Currently, completely new animations are required for the hip height to be the correct distance off the ground.
S2: If that's not possible, second choice is perhaps a script-based method of setting the hip offset to a fixed value. This would still allow existing animations to be used by manually setting the hip offset to a proper height. For example, llSetAvatarHips(AVATAR_HIP_DEFAULT) or llHipHeight(30.0)
S3: Last choice is that deformations don't effect the hip height at all. This means that all new animations will be required for deformed avatars. Since the current limit for animations is to move within a 5m box away from the avatar's hip, an increase on this level to 10m, or even better 20m would allow for avatars of an acceptable size without requiring additional scripting resources to manually lift the avatar.

P: The bounding box on a large avatar is a peaspeck compared to the avatar itself.
S1: Create a separate script function to change the avatar's bounding box size. For example, llSetAvatarBBox(AVATAR_BBOX_DEFAULT), or llSetAvatarBBox(<10.0,5.0,5.0>);
S2: Automatically increase the bounding box when an avatar is deformed.

Examples

In the BVH file, the hierarchy for the head would normally be:

OFFSET 0.000000 10.266162 -0.273764
CHANNELS 3 Xrotation Zrotation Yrotation
JOINT head

But if the joint is to be deformed, it would be changed to:

OFFSET 0.000000 10.266162 -0.273764
CHANNELS 3 Xposition Yposition Zposition Xrotation Zrotation Yrotation
JOINT head

And three additional floats would be added to the motion data on each line in the second half.


The existing problems with (old) deformations that the new deformations should solve:
----
1) Requires 18 animations to deform every joint. This can slow down the server and client.
2) All 18 animations must play at some point after a third party looks at the avatar for them to see the deformations.
3) A third party who looked at a now-not-deformed avatar and hasn't moved out of visual range and back must see the avatar play the "undeformation" animations to see them normal again. (Or, the avatar must be forced out of the third party's viewing range and back again.)
4) With the avatar being stretched vertically, if the shape changes, then the avatar will sink into the ground or float. Since when a third party loads the avatar, there's no real way to tell if the deformation animations or the shape will be applied first, then it's a dice roll if the deformed avatar is loaded in the proper order.

note

The ideas in this Jira are the efforts of a
large collaboration of avatar creators and consumers, and not solely that of the
name of the Jira creator.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Lex Neva added a comment - 09/Sep/07 08:53 AM
I think this could result in some very weird avatar behavior that generally breaks the shape system. See my comments in VWR-2242.

TigroSpottystripes Katsu added a comment - 19/Sep/07 03:23 PM
well, then just make the necessary modifications and additions to make it work without breaking anything (permanently)

you said:

"Lex Neva - 09/Sep/07 08:52 AM
I feel that if something is worth doing, it's worth doing right..."

that is what iu'm proposing here, doing it right instead of having it be a hack


Bloodsong Termagant added a comment - 28/Oct/08 05:50 AM
september 2007....

well, its a year later, now seawolf has used the 'bug' to good effect in their huge dragon avatars, but i dont see any progress to making this a 'standard' feature? it is HUGELY useful. where's all the 2242 bug supporters to vote on this?

btw, i tried hand-editing a bvh file so the head (as a test) used six channels: 3 offset and 3 rotation. i then added 3 position entries to each frame representing the head's position in the line. DESPITE the fact the bvh file listed six channels for the head in the heirarchy, sl only read 3, and pushed the next three (the angles) down to the next body part (left collar). meaning.... its not even paying attention to the channels entry in the heirarchy, but simply ASSUMING its 6 for the root and 3 for everything else. this could entail a bigger fix than we thought. :/


WarKirby Magojiro added a comment - 28/Oct/08 06:01 AM
You alreadyy had my vote.

TigroSpottystripes Katsu added a comment - 28/Oct/08 11:52 AM
I had the impression this had more votes than it seems to have right now, but my memory screws up with things much easier to remember than how many votes each of the entries I made on jira had the last time I saw the count, so it shouldn't be much of a surprise it was really mistaken about this, though I dunno if it is, or if people unvoted or had their votes removed some other way...

Ryozu Kojima added a comment - 28/Oct/08 10:06 PM
@Bloodsong
That's because the parser that LL uses doesn't support the actual full BVH specification. In a way, you could say this is a very kludgy and fake BVH support. If data isn't formatted exactly as the parser expects it, it screws up, instead of reading the the way the data was meant to be read as the BVH format is meant to do.

The hard part about having something such as this implemented, is that there are two parts of code that need to be updated/fixed.

One is the actual parser itself that converts BVH animations into LL's internal animation format. The second involves the code that is used when an animation has been told to stop playing on an agent's avatar, this code needs to be updated to return any joints to their default, or previous offsets. Basically a rewrite to treat joint offset data the same as joint rotational data.


Adeon Writer added a comment - 05/Feb/09 06:40 AM - edited
A good idea but this should also allow user settings to disregard all offset data except for hip, if they wish to. Some (many? most?) people do not want their skeleton tampered with by animations unless it's specifically for an avatar with a custom skeleton. Otherwise the only other time this is needed is when they're being griefed. Perhaps a new permission, PERMISSION_CHANGE_SKELETON, or something else. This idea opens up new possibilities, but the experience of those that don't want these kind of animations played on them shouldn't be altered.

TigroSpottystripes Katsu added a comment - 05/Feb/09 11:59 AM
well, we dont have a "PERMISSION_LICK_OWN_GENITALS" much less "PERMISSION_EXPOSE_NECK_FOR_SPAMPIRE_BITE" and yet it is allowed, PERMISSION_TRIGGER_ANIMATION should be all that is needed. If you're concerned about permanent deformations, just have one of the default anims be a low priority anim that got all offsets set to zero, this way, when an animation with different offsets stops playing things go back to normal position. And if you're concerned about animations being uploaded with offsets when there shouldn't be any offset, well, then the correct "zero offset" should become part of the format for anims for SL.

Adeon Writer added a comment - 05/Feb/09 05:14 PM - edited
That is to say, those deform animations would need additional permissions, effectively making this jira a reality and at the same time destroying a common form of greifing. (as those hacked animations would now be seen as skeleton relocators and requiring additional permissions other than the automatic animation simply by sitting.) There don't seem be to many use cases for altering someone else's skeleton (especially without explicit permission), so I feel it would work out.

TigroSpottystripes Katsu added a comment - 06/Feb/09 04:50 AM
I don't think the offsets should be treated any different from the rotations, both would still be just temporary, and both covered by PERMISSION_TRIGGER_ANIMATION, there are already plenty animations that have potential to be used for griefing.

Simply stopping the "deforming" animation should be enough to undo the deformation.

Perhaps the hacked animations would only still be kept working for a while till properly done anims are phased in, and every creator of hacked anims would get a 10L$ credit for each unique hacked anim to use to upload a correctly done anim, this way the creators that care for their customers would be able to provide fixed versions. After all, they knew this was an unsupported feature to start with, it's partially their fault when things stop working (it is also part LL's fault for not already doing the BVH interpreter right from the start)


Adeon Writer added a comment - 18/Feb/09 06:54 PM - edited
Good point. So long as "stop all animations" can stop these kinds of animations just as easy, (currently, it cannot) I would see no reason for it to not be fully implemented.

Would still be nice to know that an animation uses joint offsets somehow though, for example, before a purchase. Going by looks doesn't help, if it's subtle. I'm sure animators would "fudge" animations a little to get hand positions correct, etc, which would actually be undesirable for some people.


Stickman Ingmann added a comment - 12/May/09 05:45 PM
Hijacking the Jira for a more detailed one, with permission from Tigro. Bill Watterson believed that specifics are always funnier than generalities.

Uploading deformations will be patched out in a future client. Old deformations will be like megaprims – you can use the old ones, but you can't make new ones. When given the choice between throwing a fit about not having that happen, or throwing a fit for a fully supported option, I choose the better path.


TigroSpottystripes Katsu added a comment - 12/May/09 06:02 PM
yay, finally you got it here, looking good!

btw, what about the thing of having at least one of the default anims have the positions be the regular positions as means to have deforming animations be undone the same way that happens with rotation animations? (currently, for example, if you stop some animations the arms freeze in place, then if you don't play any animations and walk some steps or wait a bit one of the default animations will touch the arms and start movin them again), in my opinion it would be good to have deformation animations work the same way rotation animations do in everyway possible (but of course, in circunstances where it would benefit users and creators to have a different behavior, go for it )


Stickman Ingmann added a comment - 12/May/09 06:19 PM
Tigro, I covered that in the line "When the deformation animation is no longer being "played," the avatar returns to normal." Honestly, that'd probably be the easiest way to deal with it: replacing a priority 0 animation with one that has all the normal joint position information in it. But mixing backwards and forwards thinking, I kept getting confused.

I normally put deformations on priority 0, because the change in position data causes the rotation data to spark up as well – which I also have above requested that wouldn't happen. If both of those aspects don't get in, then a priority 1 deformation, which is the only surefire way to play over the default priority 0 deformation, would end up rotating limbs and all the default priority 0 animations wouldn't work. And you'd run into the problem of a deformation avatar requiring new animations all over again since the defaults wouldn't work.

I'm going to spread this Jira around to the other deformation avatar makers now to get their opinion on this latest version.


TigroSpottystripes Katsu added a comment - 12/May/09 06:47 PM
ah, I see, i didn't realized there was the risk deformations would get tied to rotations

I agree it would be an issue if they make it so you can only do both at once, but if they do it right, having the two types of data be independent, deformations won't get in the way of rotations and vice-versa and everyone'll be happy


Maya Remblai added a comment - 12/May/09 06:57 PM
As a content creator who has made some popular and unique products using deformations, full support of them would be wonderful. The only problem I ever have with them is that it's hard to ensure all nearby viewers see the avatar correctly when the deformers are turned off. Making sure everyone sees them running isn't that hard, resetting the joints is! We also need to be able to reset the joints correctly, as it is it's not really possible to get a perfect reset because the hierarchy values in the default animations are a little off. Having a "reset all joints" script function or something like that would be perfect.

BonBun Paperdoll added a comment - 13/May/09 07:43 AM
One of the draws to Second Life for alot of people is the ability to create with only your imagination being the only limit to what's possible. Unfortunatly, Second Life has not yet lived up to the claims of it's own creators. Fortunatly there are individual users that have found ways around the seemingly built-in limitations within Second Life. The basic human shape is sevearly limiting when it comes to creating unusual and unique avatars, and thus people have had to get unusual in how they work around this problem. One of the biggest limitations has always been the limited size that an AV could be stretched to, meaning that beyond the average human limit, an AV would require unmovieng prim limbs and attatchments to create the illusion of size. Thankfuly deformations, which from my understanding were first discovered as a glitch, have been researched by users to the point that we can now go beyond the limitations placed on us in a creative way, thus putting us one step closer to the goal that LL originaly set out for Second Life, but has fallen short of, that our imaginations are the only limit to what we can create. The rumor that they are planning on makeing it impossible to create new deformers in the future sounds as if they are embarassed that users have taken the game further than they thought they could. And in all honesty, I have seen almost no griefing useing deformers in the entire time I have been in SL (going on 4 years now). The one time I did see examples of griefing useing deformers was in a store that sold such items. Unfortunatly for those that claim deformer griefing is a problem, the store also gave out free of charge a set of animations and gestures to return your AV to normal, thus removeing any real threat of deformer griefing becomeing any real problem. Infact, the individual that made said items was quite excited when I told them my intentions of useing deformers to create new AVs, saying that they had originaly wanted to use them for AV enhancements, but could never get them to work how they wanted themselves.

The information for createing deformers and useing them in AV creation is public domain, meaning that anyone with the interest and will can find the information and make use of it. So it's not as if removeing deformers will only effect a small group of builders. It would basicly be preventing others from putting this information to use in their attempts to make new content for the game, which seems strange in itself, seeing as Linden Labs often plays up the fact that their game's content is made by it's users.

But to the topic that deformers need better support within Second Life, it honestly makes sense. As I've said before, a game that boasts that it's content is created by it's users should be interested in supporting and giving those users every tool they need inorder to expand that content, and supporting deformers in an official way would be a big step towards doing just that. I have been useing deformers in my creations for quite a while now (infact, till I foundout that Seawolf and Stickman were useing them at about the same time as me, I thought I was the only one), and there are some frustrating limitations already with how they can be used that to me seem more like disregard than ignorence of them on the part of Linden Labs. For one, the way they have to be played over and over to ensure that they appear correctly to others in game sounds more like a problem with animations in general than something spacific to deformers. Not to mention that AOs useing animations created to animate deformed AVs have their own problems that go back to the root of how SL plays and handles animations. Anything short of priority 4 animations result in the AV dropping down into the floor between playing animations. Basicly, this is cause the game is too slow in detecting what an AV is doing between stopping one animations and playing the next. It seems as if this was something that LL just 'handwaved' off as not important, since with the basic AV, this problem is not noticable since the AV is already at ground level as far as the game recognizes. But as animations became more creative, this problem has cropped up in areas besides deformations. Anyone useing an AO to appear to be floating will also encounter this problem when not setting their animations to priority 4. Likewise will anyone building a mech useing the more traditional method. This means, among other things, that smooth transitions between animations can only be done by playing them in an exact order, where the last frame of the previous animation is the first frame in the next in the AO. Unfortunatly when playing any of the walking or moveing animations, there is no way to do this, resulting in the AV sinking into the floor for a few moments.

There's also the problem of returning the AV to normal once the deformations are not required, as already mentioned in this article. Building in a standard method to do this as part of the game itself would also remove any worries about someone useing deformations to grief others, as anyone would be able to instantly return to normal by a standard command. This is something that should of been built into the 'Stop All Animations' function.

In short I suppose there are many ways that Linden Labs could improve on in this respect, and doing so would not only reflect well upong Linden Labs, for supporting the content their users create, but also on the content itself, allowing users to push the limits of what is possible and encourage them to be more creative in their work.


TigroSpottystripes Katsu added a comment - 13/May/09 05:55 PM
I added the phrase "If possible provide even bigger range than what is currently avaiable, the biggest possible." (copy/pasting it here to make it easier to find if it is to be edited) inspired by somthing Stickman said over email, if that isn't how that detail was supposed to be included feel free to fix it or somthing

Stickman Ingmann added a comment - 15/May/09 05:29 AM
Thanks Tigro! But I was actually talking about the animation offset limit. Currently, animations can only be created that move the avatar somewhere with in a 5m square around the avatar's hips. That means, if the hip height isn't automatically updated to be somewhere higher, the most a scaled up avatar can stand is about 12m tall without additional help. And I know there's already products on the market to make them stand higher. Better to ease/extend the animation limits than require additional scripting, especially considering the per-parcel/sim scripting limits that are in-process.

Youri Ashton added a comment - 16/May/09 06:18 PM
A long discussed issue. Since deforming of a avi is created by exploiting bugs trough using scripts (correct me if i'm wrong in this), there is now a real discussion going on either to ban it or not.

Disadvantages:

  • Griefers seem to love this, they send someone a blue windowed message that looks like nothing is wrong. But in fact there is often just 1 single button that also activates a deformer for the person that gets the message. This person either needs to deform inword by a un-deformer, or relog SL. And I can tell you from my own experience, a slow pc usually gets hit aswell making it even more laggy and even could crash the viewer wich may need you to wait 5 minutes untill you finnally get back. And that only because a griefer wants to have his/her fun.

Advantages

  • Great avitars can be made thanks to this feature, from the mega avi's (like dragons and transformers) to mini/micro avi's. Also 'pet' avi's may need this feature if they wont use to many invisible prims!

Conclusion
I think it is a good thing to keep until there is something better that could replace this without messing up avi's that so far already been made. It would be really dumb to get rid of this now and mega prims will be allowed to keep on. Isn't it stupid to keep the real problem makers instead of those things that actually may solve problems better? My suggestion is then to keep it in as long as it is needed, create a feature in the viewer that actually does this for anyone that wants to without using scripts or any other things that may be needed for this right now. If not, then why keep the megaprims? I have to tell that LL will never be able to get everything on this subject deleted since people put in alot of money to get their avitars, unlike the mega prims (which are 100% free), the avitars made with this are payed for, and some times even big money of 1000L$ up to 5000L$ or more. Unless LL wants problems with their residents, which I hope they wont, they really can not think about trying to delete everything that is made with this. Same counts for mega prims, They decided to allow it simply because there was so many things already build with these.
About the future of allowing people to create new things is a different story, although LL will get alot of problems getting this away and alot of really unhappy residents after them (and simply putting this really nicely still).

@LL: I just say it as it is in my own words, my apolagies if you don't understand what i mean. I just try to give my opinion and try to stop a disaster from happening. Please think really good about this subject before doing anything!


Maya Remblai added a comment - 16/May/09 06:22 PM
@Youri Scripts aren't involved in the deformation itself, it's an animation. Your arguments are good, but the disadvantages are already addressed in the proposal: making deformers a supported feature would mean that they can be easily stopped and started just like any other animation.

TigroSpottystripes Katsu added a comment - 16/May/09 06:24 PM - edited
from a non-technical point of view, the only difference between the hacked deforming animations and the animations that deform the av by rotating joints to extreme or awkward angles is that there isn't a default anim that will put things back to normal after the deforming animation is gone

Daryth Kennedy added a comment - 17/May/09 01:09 AM - edited

Six reasons to support Deformations

  • Improves the overall appearance of SL, much like sculpties have, by increasing the potential for more realistic and artistic creations.
  • They would help SL look less out-of-date. While LL is celebrating that SL is six years old, it also means the technology is at least six yeas out of date ... something like deformations will help bring SL back up to the animation level that people see & expect in 2009. All LL has to do with something like deformations is properly support it and the content creators will take care of the rest ...
  • They allow for more out of the box thinking For many people, being something other than human in a virtual world is simply a given: why be human when you could be ANYTHING else. Deformations allow for much more impressively created & animated avatars.
  • They may even increase the appeal of SL to new players, or those that might have left, by allowing for a higher level of quality in animations and character design.
  • Disabling the ability to use deforms wont solve the problem. If LL's concern is griefing or misuse, there's already a slew of ugly deform anims in SL, pulling the plug on any new ones isn't going to make the griefing go away. Its just like any other tool in SL, there's always people who are going to abuse them, the root of the problem is the people themselves not the tool they use.
  • LL can claim its a feature and not just another bug. They won't have to do a lot of work for something that appears to add "new" functionality - just clean up the functionality of something that's already there.

Edit:
who knows, maybe if one or more of the avatar creators were able to get something using deforms added to the library & everyone in SL had access to an av that uses deforms they'd see why we're fighting to keep them I know I'd be willing to make something if LL would be willing to add it ...


Youri Ashton added a comment - 17/May/09 04:29 AM
@Maya Remblai: Thanks for clarifying, I was not sure about the script part. Sounded weird to me already since nobody can add any scrips directly to any body part to my knowlage.

BonBun Paperdoll added a comment - 17/May/09 06:50 AM
@Daryth Kennedy: I would be more than willing aswell to put together an AV demostrateing the use of deformers for unusual AVs and have it as part of the library. I agree that there's likely alot of relativly new users that have only heard of deformers being a form of griefing (though personaly I have never seen any deformer griefing, and have maybe heard of one incident second hand). This basicly sets users up to complaing about them, rather than actualy seeing that they can be used for something worth wild.

@Youri Ashton: Maya is correct, there is no more lag involved in the deformers themselves than there is with any other animation. But because if the way SL handles animations, to use deformers propperly as part of an AV, they require a refreshing script that replays them every few seconds, which is the primary source of lag, in addition to a normal AO being required to also play normal animations that are custom made for the new deformed AV. Granted I myself have hardly experienced much lag while useing deformers, but it seems the amount of lag someone experiences from them depends on their system, their connection, and the amount of lag from the sim and asset server at the time. Making them a supported feature of SL would greatly reduce the lag involved in useing them by either removeing the need for the scripts, or simplefying the scripts that are needed for them to work propperly.


Onix Harbinger added a comment - 17/May/09 10:06 AM
@Daryth Kennedy: While Tinies do not generally use deformation.... Look at the huge variety of avatars and vast communities that sprung up out of the simple ability to mold the av into a shape beyond what is provided for in the default shape controls. It has done nothing but benifit Second Life and enrich its content and culture. In my "second life" I want to come into the world in any shape my immagination (or imagination of content creators) can come up with. . I agree with Daryth. If there is a sudden swell in popularity for avatars that have deformations it may lend much to the argument for implimentation. It's hard to argue against something beloved by many. Donating something to the library would go far to accomplish this.

Simply adding a un-deform reset to the Stop All Animations, and adding it into script functionality will aleviate a vast majority of any griefing and problematic coding issues. Deformations are a great potential asset for content creators.


Atea Aeon added a comment - 17/May/09 10:27 AM
@Daryth Kennedy: "They allow for more out of the box thinking For many people, being something other than human in a virtual world is simply a given: why be human when you could be ANYTHING else. Deformations allow for much more impressively created & animated avatars."

@Onix Harbinger: "Look at the huge variety of avatars and vast communities that sprung up out of the simple ability to mold the av into a shape beyond what is provided for in the default shape controls. It has done nothing but benifit Second Life and enrich its content and culture."

The combination of wonderful content creators, extraordinary characters and vibrant community make Second Life what it is today. Let's give avatar makers and character creators the tools (and support) to create sophisticated non-human avatars.


Skylarian Isachenko added a comment - 17/May/09 10:34 AM
The extension of the creative process through support for such features by LL will have as much impact on the virtual world as did the original development of the prim system. Its quite time to think strongly on what tools you are giving the artists, creators and developers to build the rich content which is the primary draw into SL for new, and current residents. Well beyond the money issues of land and goods, is the soul behind the worlds, the artists and creators that have constantly stretched their own mediums, and from such struggle has all the great art of the world come, be it avatars, architecture, new community models, new educational processes or just plain joy. Restricting the tools, restricts the creations, and in the end, its not the hardware, fees, and infrastructure, but the users that make SL what it is.

spirits bless,
An artist in both worlds, and planning to continue to be so.
Sky


TigroSpottystripes Katsu added a comment - 17/May/09 01:04 PM
in my opinion, the way avs are folded to make semi-articulated tinnes is a type of deformation

Ryu Darragh added a comment - 17/May/09 04:44 PM
I agree with this being an important Feature (bug) in SL. Just as with the megaprim invisibility, blocking this seems like a proactive attempt to fix a problem before a solution is ready. Only in this case, I am not aware of any solutions. Just as with proper texture sorting and priorities will vastly improve SLs appearance (glass that looks like glass, invisible and shiny avatar mesh, etc..) that are slated to come out in a new viewer, we need better avatar mesh / skeleton control and some timetable for it. I'm aware that animations are more than just a client side fix like texture sorting algorithms, but the physics engine is now on a maturity cycle so this should be doable.

darling brody added a comment - 17/May/09 10:12 PM
I recently saw someone demonstrate a single animation that could deform or reform all the joints at once, as well as move the avatar up, down, left, right, to suit your needs.

Talk to Zwagoth Klaar who made it if you want more information.

I included the "single animation" reform animation in my QHUD so that people can instantly reform their shape by playing only one animation, so I know it's all possible now.

As far as I can tell it is all possible with a bit of work, but not supported in any automated animation makers, so you need to do it by hand.

As for the good and the bad arguments. I thought the avatar carrying their head in a jar in front of them was really cool. Reminded me of Futurama.

Darling Brody


Gordon Wendt added a comment - 17/May/09 10:22 PM - edited
Darling, not a great way for them to get a-head in life

/me ducks the incoming barrage of rotten fruit for that bad pun

on topic: I'm of the stance that we should pretty much never remove a feature because it can be used for griefing as long as it has good uses even if the bad outweighs the good so I'm in support of keeping the current system in place until a better system can be put in place and i echo the sentiment that I would love to see this rebuilt and done right to give more options as well as better measures for people to revert this type of change to their avatar instantly in cases where they are hit by a griefer deforming them..


TigroSpottystripes Katsu added a comment - 17/May/09 11:07 PM
Zwa rocks!

I foresee Zwagoth's IM queue will fill up before the next login....


tiamat bingyi added a comment - 18/May/09 06:03 AM
@ BonBun Paperdoll :"The basic human shape is sevearly limiting when it comes to creating unusual and unique avatars, and thus people have had to get unusual in how they work around this problem. One of the biggest limitations has always been the limited size that an AV could be stretched to, meaning that beyond the average human limit, an AV would require unmovieng prim limbs and attatchments to create the illusion of size. "

@Daryth Kennedy: "They allow for more out of the box thinking For many people, being something other than human in a virtual world is simply a given: why be human when you could be ANYTHING else. Deformations allow for much more impressively created & animated avatars."

@Skylarian Isachenko : "Its quite time to think strongly on what tools you are giving the artists, creators and developers to build the rich content which is the primary draw into SL for new, and current residents. "

It ´s amazing how the creators go beyond the SL limits to bring us something new and unique, something that break the basic shape - and its not just one or two, they´re many ... Isn´t time to offer support for those and others creators, giving tools like a non human shape, or deform/undeform tools?


Orlith Nightfire added a comment - 18/May/09 06:37 AM
Deformation needs to stay in SL. alot of avatars we buy these days use them. From Daryth Kennedys Dragons, To Seawolf and grendles avis.

Speaking for myself i am hardly ever a human inwold. all my avies are dragons, and i know alot of people would feel cheated of thier SL lives but the taking away of this useful tool. So many people have already lost faith in Linden labs. i fear this is the sound of them hammering another nail in their coffin.


Jaxx Marjeta added a comment - 18/May/09 07:15 AM
Simply put, I support Deformations. For me, Second Life is all about fantasy, discovery, and participating in role play, or a second life, if you will, not possible or wouldn't possibly be as much fun in the real life. It's one thing to pretend that there are dragons and firelizards and mystical creatures to interact with, it's a whole new world when your avatar can personally interact with them! And now there is the real chance that Linden Labs will disable the feature that makes these wonders possible. I, for one, would be incredibly saddened by the loss of this rich content that makes Second Life so appealing.

db Gigamon added a comment - 18/May/09 08:20 PM
Thanks Tigro:
P: After deforming an avatar playing animations, the legs will buckle when attempting to IK at the ground. By changing the avatar's shape the hip height will be recalculated - but not to the correct spot. Occasionally, different viewers will see the avatar's hip at different default heights while deformed.
-------------------------------------
( I had been wondering why my Rancor sometimes is almost knee deep in the ground or floats above it.)

@ BonBun Paperdoll : One of the draws to Second Life for alot of people is the ability to create with only your imagination being the only limit to what's possible. Unfortunatly, Second Life has not yet lived up to the claims of it's own creators. Fortunatly there are individual users that have found ways around the seemingly built-in limitations within Second Life. The basic human shape is sevearly limiting when it comes to creating unusual and unique avatars, and thus people have had to get unusual in how they work around this problem.

(Well said Bonbun!)

All good points and reasons TO KEEP THIS and make it work better. Creators NEED the right tools to make fantastic avatars.

db


TigroSpottystripes Katsu added a comment - 18/May/09 08:27 PM - edited
@db Gigamon: Stickman Ingmann (and some other people I don't know who are) did put quite a bit of work giving this proposal a makeover and leaving it with a much more professional feel, they deserve quite a big percentage of the thanx for this proposal

Darky Delacroix added a comment - 19/May/09 08:18 PM
I hope with all my might they keep Deformers in the game.

I have sunk at or more than 100 USD into avatars that use deformers (Horses, Donkeys, Dragons, etc) and if this passes I will be out that money and have avatars i will never be able to use. Its not fair to people who have been constructive with this "griefer" tool and made some amazing avatars in game.

Isnt there a way where we could make this work like a hug attachment? Where someone wears an avatar and the box pops up that says "_______ would like to deform your avatar, do you accept?" so then that way griefer tools wouldnt work, but you could still safely use your avatars.

I have gotten so used to having fun with horse and dragon avatars, and i will be heartsick if i cant use them anymore. Its been a huge part of the game to me, and what really drew me back into it... i really hope we dont lose it.


freyfaxi pfalz added a comment - 19/May/09 08:24 PM
I , for one, like the wierd and wonderful avatars we can have. It's a big part of the fantasy of SL. I'd hate to have us all go back to boring old human AVs

TigroSpottystripes Katsu added a comment - 19/May/09 08:30 PM
people are griefed with regular animations even with the blue dialog

also, unless I'm wrong, this proposal is more about adding proper means of using animations that contains positional data for the joints, if you want the hack to be supported as well, I think it might deserve it's own separated jira entry. Though since I'm not the only author in this proposal anymore, we should probably hear from all those pro and pro-like people that improved this proposal in many aspects, not to mention all the people promoting it


Maya Remblai added a comment - 19/May/09 08:36 PM
Just to make things clear, this JIRA is for adding support for "real" deformers, rather than the hacky method we have now. That said, the old method would probably still work. So even if you didn't get your old avatars updated, they'd probably still work anyway.

BonBun Paperdoll added a comment - 19/May/09 08:36 PM
The "hack" is basicly fooling SL's BVH conversion to read positional data for a joint that it normaly doesnt. There is positional data in the animations on SL, but normaly it's only reading it for the hip joint (which allows for animations that have you floating in the air). So basicly, what you're calling a 'hack' is at the core of this jira. From what I understand, BVH files can handle positional data for more than just one joint, but SL only supports the one. You have to fool it into reading positional data for the other joints. I guess you could say we want LL to 'educate' SL into reading positional data for more than just one joint at a time. So rather than having to be fooled into doing what people want, it'll know how to on it's own.

Maya Remblai added a comment - 19/May/09 08:41 PM
Thank you BonBun, you explained that much better than I could. BVH files do indeed carry positional data, but for whatever reason SL ignores everything but the hip. It probably wouldn't be all that complicated to get SL to read the positional data. From what I've been told, it's already possible to write a viewer that doesn't convert the .BVH to SL's stripped down variation, and does read all the positional data.

TigroSpottystripes Katsu added a comment - 19/May/09 08:45 PM - edited
from what I understand of the trick (which is probably less than many of the voters here), it involved editing the BVH file, and changing the name of the hip joint to the joint you intend to move, and then change it's offset, the hierarchy of joints from the client point of view doesn't really change, even though the left hand is the parent of the thighs in the modified BVH, in the client the thighs are still attached to the hips and move independently from the left hand, or somthing like that. I call it a "hack" because it involves tricking the software and using things for a purpose different than what the creators intended to (in this case, the data for the hip position being used for some other joint position)

Darky Delacroix added a comment - 19/May/09 09:11 PM
I need to read before i comment and react XD

Either way, if this gets enough signatures, deformers will definately hold a place in SL... and hopefully there will be more options and all that available to customize the avatars further.

Thanks Maya and BonBun for the clarification! =)


Arkam Lohner added a comment - 20/May/09 12:23 AM
I took time to read all of your comments.

As so many of you put it, deformation allows creators to give us amazing avatars, which are definitely a big asset to Second Life. Should LL decide not to keep this alive it will just be another blow to those who have been drawn to this virtual world where they can be whatever they want.

I am especially thankful to content creators who allow us to be fantasy creatures, or to meet those while exploring.

So please keep it alive, improve this if possible and let us live our second life as we like it to be.


Geerkil Ziskey added a comment - 20/May/09 07:27 AM
I for one feel that the deformers provide an eliment to SL that improves the overall enjoyability of the SL experience. As a proud owner of all of the Seawolf dragon creations, (They are Awsome), I would rather put up with any griffing then lose the creative talents of those such as Stickman and the others that put this claimed 'flaw' to good use. If the intent is to remove griefing, there is no way to eliminate it unless you remove the ability to script and create from the game. Just like conputer security, there is always someone out there that will find the chinck in the armour and cause trouble. How well do you thing SL would survive if you eliminated all scriping and creating. Not too long for sure. You provided the intent that it is a user created and user defined world but then you try to limit it. My sugestion to you is to enhance the use of deformers, make the a part of SL, support then and if you included in the client tools a 'restore form' command this grifing would not be a bid issue. All in all, I think the ability to deform is something to be supported by LL and not taken away.

For those that see this as a problem, I am sorry. The world is full of jerks, and we all have to tolerate them to some degree or another. If the deform was supported properly, those restarts would be un-necessary and life can go on like nothing happened. As for the slow computers, I am using a slow computer. I do not like how long it takes to do things such as restarts, but for me it is better then removing such a usefull tool for the creaters of AV's. If I have to restart every now and then, it is a small price to pay to keep the unusual content in SL rather then trying to remove the creative efforts of those that find work arounds to make SL what you supposidly envisioned it to be and advertised it to be. Our world created by the users for the users.

That is my two cents, for what it is worth.


Cliona Karu added a comment - 20/May/09 08:24 AM
I don't pretend to understand the technology behind this, but it seems to me that if you remove this from the game play we will be losing a lot of creativity that people have used to create some lovely avatars. It extends the game's appeal, and enriches the playing environment. Better to find a way to live with it rather than remove it I think.

Delu Elytis added a comment - 20/May/09 09:16 AM
So much "Linden Labs will remove this deformation hack/glitch".
The invisibility prim too is a hack/glitch, it make use of a texture to hide avatar bodies and alpha textures. But LL decided NOT to 'fix' it cause it is so useful for creating various stuff, a lot avatar based. I cannot really think LL would decide to remove the deformation as it's just as useful. Possible to even use deformation so one don't have to make use of invisibility prims

So why has this rumor come that LL will remove this? Can anyone tell me where LL have said they will or maybe will? I cannot find such info so I cannot understand this worry about it, and it's starting to get annoying to hear this everyday without finding an actual cause to spread the message that LL will remove it and we need to vote to keep it.

I do support deformations and would like to see it properly implemented into SL, so at least this gotten attention to implement it properly...


Stickman Ingmann added a comment - 20/May/09 09:39 AM
Allow me to set the word straight. First, no older content that uses deformations will be broken. It pays to say it first as people miss that part.

A Linden informed me that deformations would eventually be "patched out." That is, like megaprims, you won't be able to make new ones, but the old ones will continue to function. They are a bug, they do have griefing potential, but as a lot of people have said, they also have wonderful abilities linked with them. The context and language of the Linden implied that the patch may come across with in the next couple versions – but it's possible it was a more generic warning that since it's a bug, its future cannot indefinitely be supported.

Deformations are not currently patched out – new ones can still be made. And there is no date set when they will be removed. That remains a generic "future event."

When I contacted that Linden directly and suggested trying to get the decision reversed, he told me there were two ways to try doing that: Take a step backwards, and try to get the bugfix removed, or take a step forward and get the concept of deformations created as an official feature, instead of relying on a hack and a bug. Seeing as deformations have a few annoyances and bugs related with them, I jumped at the chance to get all the bad parts removed by having them officially supported.

Also, I've seen some things mentioning other content that's effected. Only future projects that uses deformations, specifically the bug involving uploading doctored BVH files, are effected.

This Jira is the coordinated effort of a dozen avatar creatures that either use this bug, plan to use this bug, or otherwise see it as a useful thing that needs official support. I've been amazed with the positive response everyone has given, and the speed at which the whole community has built up this Jira. I publicly thank the avatar developers and the community for their support on this issue. It's been thrilling to see everyone band together towards a common positive goal.


Findhorn McLaglen added a comment - 20/May/09 10:20 AM
One of the most facinating aspects I find within Second Life is how people have taken what the Lindens gave them and found innovative and imaginative ways of creating what they wish to be, or wish to do. Some of these methods have utilised the use of "bugs" in the system, but to wonderous effect. I thought one object of SL was to allow creativity. Removing the option to use deformations stiffles that creativity.

I use deformations, I play an animal character as I find it enjoyable and challenging. I try to modify my Avatars to be as realistic as I can get them. Many others do the same and others joining the SL community also wish to do so too. Those who wish to will no longer be able to if the ability to use deformations is removed. So much that adds reward and colour to Second Life will then be lost.

Deformations need to be allowed to stay and preferably be offically supported so that Avatar development can continue.


Boskar Yifu added a comment - 20/May/09 02:43 PM
Deformations need to be allowed to stay and preferably be offically supported so that Avatar development can continue.

Nemy Akina added a comment - 20/May/09 04:32 PM
Deformations need to be allowed to stay and preferably be offically supported so that Avatar development can continue.

Gary Foxclaw added a comment - 20/May/09 06:58 PM
I don't know why, or who is actively trying to get people to leave secondlife who works for them. but it would be nice to actually improve what is here, not figure out ways to limit and cause people to leave secondlife. i don't know who is doing there relations. but they are getting paid way to much. if it works don't fix it. fix what doesn't work!

Zwagoth Klaar added a comment - 20/May/09 11:04 PM
Since I have received a grand total of two IMs about this, thought I might comment on the issue and clarify both what I know and how it may effect the future development of this possible feature.

To create my little undeform and deform animations I bit the bullet and did about two days of hard reading through the core of the animation engine, mapped out the internal animation file format and wrote a tool to both create, modify, merge and otherwise manipulate the format. Using a modified bulk uploader I am able to upload these much the same as any other bulk upload item. By bypassing the BVH importer entirely you have a huge amount more freedom with how things are used and manipulated. Not only are there significant hidden features that are otherwise inaccessible, but it gives complete freedom with content creation.

The internal file format has support for a great number of things, including adding a default emotion animation to play along with your animation, hand poses, additional priority levels, rotations beyond -1 to 1 and positions that are beyond -5 to 5 m from the center of the avatar. There is also a constraints system that can be witnessed with the ground sit animation. If you play this animation while in the air, it snaps you back to the ground by using a constraint solver between your legs, pelvis and the ground. You can use this system to create custom constraints for any bone within the skeleton. Also, per joint priority levels. Yes, you CAN do this.

The biggest feature is that you are able to deform attachment points. I have been quietly sitting on this for a fair bit of time now, but it might as well become public know. This allows you to move and rotate the attachments themselves, without limiting you to moving the body parts they are attached to. Using this you can create fully working large or small avatars using the normal body shape, without folding. This opens up the possibility of having all current animations work with your custom sized or skeleton avatar. The biggest plus I see is the ability to define the attachment points where you want them to be, instead of being stuck without that very important knee attachment joint that everyone would give their spleen for. (I know every mech creator has wanted one of these since the dawn of time. If you try to build one, you very quickly figure out why.)

The normal caveats all apply to these powerful features. The constraints system is somewhat unstable and is not quite as flexible as it sounds. Moving joints or attachment points is permanent, there is no fixing them without relogging. (at least locally) and the additional priority levels will become as polluted at the current level 4 is right now. Everyone wants their anim to be max priority so it plays right.

Now that I have teased you all with these features and notes, I feel it is only fair to support the development and fixing of both the upsides and caveats of the current system.

To help explain why undeform animations do not work right now you have to understand that every joint is "modified" from their default position with any change in body shape. The default joint positions are seemingly impossible to obtain using the body shape tools as some of them require values outside of the "allowed" range given to us. When you play an underform animation it sets the positions of all of the joints, or one specificly, in an absolute spot. Without knowing these modifications made by the current shape, it BREAKS the avatars shape on a drastic level, the current modifiers are assumed to have been applied to the joint positions next time it goes to modify them for shape. Leaving them out of sync and further skewing things out of their correct alignment.

The REAL fix for this is to store a copy of all of the joint positions before any animations are applied, and when an animation is stopped, unless it has that joint marked for position modification, it is set back to the stored "default"(which is actually just what your shape used to be, not the actual default.) This should apply to all joints, including attachment points. The only reason that the pelvis position does not stay deformed forever is that a piece of c++ code is run EVERY FRAME that as priority 0, sets the pelvis position to its origin.

I welcome any questions or comments in my IMs (end up in my email if I am not online, no, I don't hide my online status, so you are free to check.)

Copies of the program I have written, my modified copy of qAvimator that has been modified to have a very primitive export to raw sl animation files(as well as custom body part mesh support), and the 6 line patch for the animation file upload are all available upon request, along with QUICK custom animation requests/uploads or ones that I have already created(customs/uploads providing I am reimbursed for upload fees and time permits, I currently have no in game income). I have no trouble giving any of this out. As of right now, the animation program has already been published for some time, most people simply do not know of its existence or cannot use it because they are unable to upload the animations it produces.

As a note, deforms beyond the -5m to 5m range are very likely to dissapear. I would not keep your hopes up for their continued existence. Why, is not up to me, but their removal from the client is the current rumor. May my 400m neck deform last in laughter and hearts if it comes to no longer work. Many a laugh was had with it.


Zwagoth Klaar added a comment - 20/May/09 11:11 PM
As a further comment, the bug with people appearing crushed, partially underground, or floating above the ground is as Tigro stated, a failure to correctly update the approximate center of the avatar. The viewer has a hidden variable that adjusts how much the visual representation should be moved up or down to try to make the feet align with the ground. This variable is currently only updated with body shape, and automatically calculated, and has no front end for modification.

Opening this variable up for user modification would be REALLY nice. I forget the official name for it at the time, but its a single floating point value that is server constrained to reasonable values. I see no harm in allowing users to play with it to perfect how far above or below the ground they are. Or if they are quirky, wish to walk with their knees at ground level(this is about the lowest realistic change you can make before the server constrains the value), may do so to their hearts content.


TigroSpottystripes Katsu added a comment - 20/May/09 11:45 PM
I'm adding a little note to try to reduce confusions regarding attributions of merit regarding the text and ideas of this proposal (though I dunno if putting it in a panel was too much, feel free to fix if you see necessity)

Bull Westland added a comment - 21/May/09 12:03 AM
Avatar Deformers need to remain in SL. They help users in creating the unique avatar that truly exemplifies who they are and embodies the spirit they feel. It is a necessary part of SL that each user be able to express themselves in their own unique and creative way possible. I know, I am one of those users...and there are countless more than just myself.

Please, please keep deformers in SL.

Thank you.


Brittany324 Burt added a comment - 21/May/09 01:45 AM
Yes please keep them in sl everyone who likes them would be lost with out them. I use them for different things in bondage and being other things in SL that you can not be in RL. Please Please Please
keep them

Thank you


Shakeno Tomsen added a comment - 21/May/09 04:52 AM
@Zwagoth: After reading what you said about the hip placement, I just started wondering something... do you think this could do with that awful hip height placement on taller/shorter avatars? (I mean, that annoying glitch which makes you float if you're taller than 180cm or sink in ground if you're shorter than that)

@Anybody who reads: I've read about the idea of positioning eyes, and I think that would be a REALLY useful thing. I'd like some avatars to use avatar eye rotation, but I can't do it because I can't position the eyes alright, I'd need to be able to deform them.


Whiteflame Khandr added a comment - 21/May/09 07:36 AM - edited
I uploaded a picutre of my av, and it wouldn't be possible without deformations. There are individuals who make avatars based on deformations, which are a key component to their appearance and function. Not allowing deformations would unfairly ruin any business they have and would also run the experience of many members on sl who only use avatars with deformations. We would most likely leave, if they were not available. I myself only use that particular avatar, and if I could not use any avatar with deformations, I would definitely not want to stay considering a lot of what I do on sl is related to that av (which I spent a lot of money, time and work editing and customizing along side an artist whose current business is designing custom textures for avatars with deformations such as the on in the image attached to this issue). I hope you keep the deformations and that enough people vote.

Wanders Nowhere added a comment - 21/May/09 05:15 PM - edited
If deformers are removed from Second Life, the entirety of my upcoming line of nonhumanoid avatars (Life-sized, fully articulated, photorealistic dinosaurs) will be ruined. Deformers, like megaprims, are a useful feature for content creators. It's being argued that they can be used by griefers to create a mild annoyance. Really?

I ask you what cannot? Regular prims are used by griefers; gestures, sounds, video, weapons and all kinds of scripting are all used by griefers. Griefers will simply use any method available to get their kicks; if they don't have deformers they'll just use something else.

Content creators, however, will be robbed forever of our ability to make realistic non-humanoid creatures, and entire communities of creature avatar enthusiasts will be left in the lurch.

I ask you how I am meant to make an animal with a thirty foot neck without deformers?

Deactivating this providential 'bug' would be as illogical as deactivating Second Life scripting as a whole because of its 'griefing potential'. Deformer 'attacks' require a person to accept the animation, just like every other kind of animation griefing, and are rarely used and easily fixed by relogging or simply using an undeform gesture or object. They pose an utterly negligible 'threat' when compared to scripts that crash sims, spam abusive text or steal a user's hard-earned lindens.

Deformer avatars, however, are becoming more and more common and more and more sophisticated. I'll attach a picture of my Tyrannosaurus as an example. In the case of Seawolf's dragon avatar, months of work have visibly been put into creating and scripting it - that thing is a marvel of Second Life's potential and its existence alone should be all the evidence needed to make Deformers an official feature.

Restricting deformers to already-existing uploads also creates numerous problems for content creators. In making my dinosaurs I've had to upload a great deal of deformers in order to perfect the placement of their limbs - 'Trial & Error' is the only way to get it right. Using 'generic' deformers would not give me the necessary freedom to create what needs to be created. I am sure other creature-makers feel the same way.

I would implore Linden Labs not to make the mistake of removing this fascinating ability, which has broken through so many limits on our community's creativity. The proposed integration of a new deformer system sounds ideal - I'd like to ask, however, if a specific program would be required to create the new multi-limb deformers, or would we still be able to simply make a BVH and edit it as a text file?

Fully-featured deformers integrated into SL's coding would be a wonderful addition to the game, but I entreat LL NOT to remove the existing deformer 'bug' or modify it in any way until such time as 'official' deformer support is ready to roll.

Thank you for your time.


Wanders Nowhere added a comment - 21/May/09 05:22 PM - edited
my Triceratops using deformers, with a 'noob friend' for scale

Wanders Nowhere added a comment - 21/May/09 05:26 PM
Seawolf's famous Ancient Dragon avatar. No more needs be said - this could not have been achieved without deformers.

Wanders Nowhere added a comment - 21/May/09 05:30 PM - edited
my Tyrannosaurus Rex - again, SPECIFIC deformers were essential in creating this avatar.

Azelle Mavendorf added a comment - 21/May/09 07:52 PM
Tinies need deformations too! Adding a screenshot.

Strife Onizuka added a comment - 22/May/09 11:01 AM
The limitation of one deformation per animation is an upload limitation if I remember correctly. The internal animation format is not BVH, the format has no hierarchy and you can provide deform values for all bones; the only issue is that you need a better encoder.

My memory is a little fuzzy at the moment and I don't have the time to refresh it...
*waves to Zwagoth*


Strife Onizuka added a comment - 22/May/09 11:03 AM
Changing how the BVH encoder works is pretty trivial btw.

Zwagoth Klaar added a comment - 22/May/09 11:39 AM
Strife is correct. The one deformation per animation limit is a part of the BVH uploader that all animations that are in the BVH format must be run through.

The internal animation format is a binary file. It has no idea what a hierarchy is, or what bones are connected to each other. It provides the capabilities I listed in my first comment.

@Shakeno: Yes. This is exactly the reason for that. Opening up access to the variable would allow you to fix it.


Zwagoth Klaar added a comment - 22/May/09 01:27 PM - edited
To clear up some confusion over the purpose and use of the tools I created, will list out the reasons and purpose of each one.

First thing to note is that I never intended to release any of these tools when I made them, leaving them in a state where it is often hard to understand how to use them. They were created as quick hacks to allow me to test things. I am offering them in the hopes that they can possibly be useful

Modified QAvimator:
• Now has the ability to save to the internal animation file format. This is a quick hack, needs some revisions, and not as useful as it sounds.
• Files saved to the internal animation file format are UNOPTIMIZED and contain a LARGE amount of data that is not required.
• I created it so that those with bvh files had some way to save to the internal animation format without having to learn how to dump the animation files from the virtual file system that SL uses.
• Currently does not expose any other functionality of the internal animation file format.
• Written in C++, requires the Qt4 library to compile and use.
• Fully aware that I was a complete failure at using file buffers in C++ at the time I wrote it. (Ewhh gross. They are a MESS)
• http://zwagoth.skaarj.com/qavimod.7z

AnimMaker:
• Allows you to create, open existing, merge two existing, and save to disk, files that are in the internal animation file format.
• Written in C#, requires .NET 1.1 or a copy of the mono runtime to use or compile.
• Not very user friendly.
• Not good for creating full animations.
• Requires some knowledge of the joint structure within SL to be fully useful.
• Unpolished.
• http://par.googlecode.com/files/AnimMaker.zip

There is also the following source code patch for the LL SL viewer that allows you to upload animation files that are in the internal animation format..
• DO NOT UPLOAD BVH FILES USING THIS! THEY WILL NOT WORK!
• Requires that you apply a source code patch and compile the viewer to use.
• Must use the bulk upload option to upload the animations.
• Provides no preview ability.
• http://zwagoth.skaarj.com/upload_raw_anims_patch.patch

A thank you to those involved in hosting these files.
waves to Strife


Lin Swashbuckler added a comment - 23/May/09 12:59 AM
This is just another example proving to all of us LL actually have no clue at all of what they are doing.

First they want to institute their "Adult Content Filtering" now this. What next are they going to do outlaw RLV????

If you really want to close down Second Life, well you are on the right path because at this rate that you are going Second Life will soon be HISTORY. Maybe that will be the only thing that LL can get right.


Puppy Forder added a comment - 23/May/09 11:17 AM
To be honest with you guys I think that this whole idea of banning things like this is plain out ridiculous you are already planing this stupid grid merger.. why do you feel the need to ban other things..

Onix Harbinger added a comment - 23/May/09 02:26 PM
I've heard no indication that they are going to remove existing content (though it is always possible that a future 'fix' disables deformation) but I've heard that there might be plans in the pipeline to dissallow new deformations from being uploaded/created.....

That said... this JIRA is to gain support for getting legitimate support for deformations in the system.

In other words adding in a system for creating, controling, stopping (via stop all animations), and overall making them more efficient and less of a hack and more of an actual supported feature in the system. I'd go so far as asking for them to give us some client side tooks even for creating and deforming the avatar, script based commands would be nice too "llstopdeform {}", something... anything... to make it a supported actual feature of the second life experience.

The main thing though even if it isn't made directly into a supported feature for now it'd be nice not to see it become locked out from new content creators. Deformations are opening up a whole new world of creative avatars and I'd really hate to see it go in the name of "fixing a bug" or "closing an exploit".


TigroSpottystripes Katsu added a comment - 23/May/09 02:48 PM
Onix Harbinger wrote:

...

...script based commands would be nice too "llstopdeform {}", something...

...

we already have llStopAnimation


Stickman Ingmann added a comment - 23/May/09 02:49 PM
I would like to thank everyone for their comments! I'd also like to remind you to keep things polite and positive.

We are currently attempting to work with the Lindens to figure out the best solution to officially supporting deformations. This is not an us versus them situation, this is everyone versus 24 hours in a day. The Lindens are very busy, so it's difficult to find time to communicate effectively with them.

There may be a few hiccups along the road, but I believe the outcome of this Jira is already on the road to being a good one. Keep things civil and respectful and we'll have a happy resolution in no time.


Maya Remblai added a comment - 23/May/09 08:16 PM
Adding a couple images of my own avatars that require deformers due to their large size. You can't make a full size equine avatar without deformers.

Naomi Babcock added a comment - 24/May/09 06:50 AM
Quote : Disabling the ability to use deforms wont solve the problem. If LL's concern is griefing or misuse, there's already a slew of ugly deform anims in SL, pulling the plug on any new ones isn't going to make the griefing go away. Its just like any other tool in SL, there's always people who are going to abuse them, the root of the problem is the people themselves not the tool they use.

On the issue of griefing, LL could simply hand out a UNdeformer in the library files, there's a hundred and one of them out there, most of them free or cheap. In fact, U-bar gives a free one,and it's got a button to give a U-bar to everyone around you, so i imagine the maker would be quite willing to give LL one they can pass out.

@maya I've also seen the deforming used for Macro furry avatars (at least once) and i realised just the other day that it would be useful for mecha.. and i think there's a mecha battle RP sim out there somewhere, if i recall right..


Shakeno Tomsen added a comment - 24/May/09 07:45 AM
@Naomi: I think I have seen it being used for mechs already. About macro furries, mine uses them at least (with a custom AO though), and many people are making their macros like that.

The bad thing is that I can't make him taller than 10 meters without having to use any sit spot to get them placed properly on ground because of the 5 meters height limit for hip offset.


TigroSpottystripes Katsu added a comment - 24/May/09 02:07 PM
somthing I realized the other day, animated deforming, not only length, but position in all axis, should allow for amazing transformers

Shakeno Tomsen added a comment - 24/May/09 03:37 PM
It would. I experimented a bit and it looks possible, but since I'm not into mechs, it was just left as an experiment. But yes, it is possible. Building it to fit when you transform is another story though.

TigroSpottystripes Katsu added a comment - 24/May/09 03:49 PM
we already got working transformers that use rotation animations, but due to having the joints in fixed position, there are limitations on how the transformation happens and such

Shakeno Tomsen added a comment - 24/May/09 05:43 PM
That's what I actually meant...

Florence Valeska added a comment - 25/May/09 09:16 AM
There are entire sims of Dragons, fantasy creatures and such who spend and have spent alot of real money over the years supporting SL, to remove them would be a slap in the face, this is another classic example of people trying to fix something that wasn't broke in the first place.

Kyrie Nelson added a comment - 02/Jun/09 09:51 AM
I dont really unsterstand the technacal talk but id just like to say please do not take away deformation i like playing as a tiny and also sometimes dragon or wolf on a diffent av if you take away the ability to create new dances and other stuff for it everyone would start being the same and it would become boreing. Secondlife is about imagination and being able to do what u want or cant do or be in rl please do not change this

Youri Ashton added a comment - 04/Jun/09 08:38 AM
aint the tiny robots that some Linden's use, being created by the same bug? Just thinking out loud tho, but if it is the case, then they don't even realize they will destroy their own avi's as well

slaine Martian added a comment - 04/Jun/09 12:42 PM
it would be a very sad thing not to see new deformers in sl. my self im a dragon in sl and love the way this designers use these tools to make av that other wise would be near on imposible to make any other way please leave them alone .=)

Anubiss Kharg added a comment - 04/Jun/09 01:26 PM
It would be a great shame to not alow deforming due its perpos opends many doors in creating and modifying avatars so not patching this would firstly maky many users unhappy and also take there ability to create new and well made avatars, so id prefer You (Lindens ) to leave us the defoming so we can enjoy the created avatars as they are.

signed,

Drace alias Anubiss


Stickman Ingmann added a comment - 04/Jun/09 01:54 PM
Daryth Kennedy of Isle of Wyrms and Seawolf Ingmann of Seawolf Monsters (me!) created a freebie quadruped hippo avatar to support deformations. Hooray for free stuff!

The navy blue version can be found at Aggro, just to your left after this slurl. http://slurl.com/secondlife/Aggro/163/94/80/

The grey version can be found at The Citadel, just go in the doors and look left. http://slurl.com/secondlife/Cathedral/110/149/102/


Daphne Skinstad added a comment - 05/Jun/09 07:53 AM
I spend most of my time as a mermaid and NEEEED deformations to make me be ...well... me. Keep em keep em keep em

BonBun Paperdoll added a comment - 07/Jun/09 06:25 AM
Added a screenshot of my free Loader Mech AV, which uses deformers.

Leone Seetan added a comment - 07/Jun/09 12:32 PM
Most of my avatars use deformations if they can be improved by Linden Labs they should be and not eliminated this is a useful and fun part of Second Life if i wanted to just be a normal person i would stay in real life here we can express ourselves in many ways. Please make this a permanent fix and improve it if you can LL.

BonBun Paperdoll added a comment - 23/Jun/09 09:55 PM
No official reply from LL after this long with this many people supporting deformers? Alright, LL must of gone off their rockers or something..

Chaoman Aeon added a comment - 23/Jun/09 10:29 PM
I think this would be a great idea. it would be a lot easier to make avitars that utilize deformers. maybe in the future have something that allows us to add or subtract bones from avitars. that would be very useful.

Stickman Ingmann added a comment - 10/Jul/09 03:42 PM
I talked with Qarl Linden in office hours earlier today. He had emailed the animation Linden earlier and explained the reply.

[2009/07/10 11:07] Qarl Linden: AH YES.
[2009/07/10 11:07] Qarl Linden: so - he's open to the idea of the "deformations"
[2009/07/10 11:08] Qarl Linden: he said that's why he added that stuff to our internal format.
[2009/07/10 11:08] Qarl Linden: but there's some issues right now that keep-us from simply "turning it on."
[2009/07/10 11:09] Qarl Linden: i didn't quite follow his logic - but it has to do with the fact that internally, we don't have a way to "return to default"
[2009/07/10 11:09] Qarl Linden: which i guess is why the animations stick until you play an animation that fixes it.
[2009/07/10 11:10] Qarl Linden: know what i mean?

Qarl went on to mention that all Lindens are already working on critical projects and can't spare any time at the moment. And recommended we find a developer in the open source community to put up some code and help push things forward, much like happened with Flexisculpts.

I'll be attending the Open Source meeting at http://slurl.com/secondlife/Hippotropolis/239/28/24/ on Thursday at 2pm to see what will become of it.

http://wiki.secondlife.com/wiki/Open_Source_Meeting


Garnet Huntress added a comment - 21/Jul/09 03:01 PM
There is a simple permission that could be added that many animation programs used when turning off skeletal limits on models and figures. A program can sense when a animation is being applied that goes beyond said limits and many animation programs will ask you if you with to "Turn off limits" to allow the animation to be applied. The basics of it are that many rigged 3D models have set joint limits that allow for natural movement, sl's rigged human avatar models are no exception. I honestly think that having to allow permissions to turn off limits would be a good idea to avoid 'deformations' from being used for griefing. Now as for the factor of returning the avatar to normal, a problem I've not yet had with my avatars but I am certain it does come up, maybe something along the lines of an undo feature, much like many programs have, but for animations. Though, this is of course merely me brainstorming while tired, but it is an idea.

TigroSpottystripes Katsu added a comment - 21/Jul/09 04:05 PM - edited
joint positions shouldn't be treated any differently from rotation is just about any situation, we already talked about this, if you wanna make proposals about how to prevent animations in general from being used to griefing, make a new pjira entry

though I must say I strongly disagree on using anthropocentric standards to define what is and isn't expected behavior by default, things are already bad enough from previous decisions based on such short-sighted viewpoint