|
|
|
[
Permlink
| « Hide
]
Lex Neva added a comment - 19/Feb/07 09:22 AM
While we're at it, the priority handling for hand positions is completely broken. If you upload a pose at priority 4 with a hand position set to fist, the hand position will usually be entirely ignored.
The walking animation is run at two priorities. Priority 3 for the legs & pelvis and Priority 0 for everything else.
Hand positions can be overriden with script, but you're right, we shouldn't have to do that.
I have noticed this same problem. I upload my animations at priority 4, yet the system default walk attempts to override it.
Even when I create my own (very simple test) walk animation, the legs and arms wobble like they're made of rubber. At times, the entire avatar will bump along like it's walking on a very rocky road. The animation system is borked. Needs fixed badly; it's preventing uploads of new walk animations. In addition, the flopping of the arms and legs messes up basic "hold" animations while the avatar is walking. 1/25/2008
Still wondering when this is going to be fixed, as I have several animations sitting on my hard drive waiting to be uploaded to make certain that this is only a priority issue, or a rendering issue, and that it is not actually corrupting the files being downloaded. It takes time to make these animations and that is time wasted if the platform is unable to handle the animation or the setting in the animation file, or if it is simply going to over write or corrupt the settings? Any updates on this, Because no news is not good news.... This is an urgent fix. For those of us doing serious animations, not being able to work the system as advertized, (i.e. not being able to layer animations because the priority scheme is broken) is a huge impediment to decent animations. I use layering all the time to create special effects in my products and now it will not work and severely limits what we can do to make SL a better place
Please set this as a priorty - PLEASE PLEASE!!! yes the priority 3 anims are not responding like they should, it is impossible to make good ao's if the priority is not right. Please LL this is a huge issue and has many votes. Why did it get broken without noticing anyway. I would gladly volunteer to check all animation related issues on all further viewers for free, if some1 would listen. Oh, i would like to point out the old anims with priortiy 3 setting still work fine, just any new animation uploaded with 3 has a problem now. There is also a new problem with animation related to blend times or some kind of delay in reading the next anim. Basically the avatar wants to spring back to some default pose inbetween 2 anims with long blend time. Now using blend times in any kind of creative way has rendered those anims junk now.
It's still broken, it still does not work.... LL please help us - WE WONT TO PERFORM ANIMATIONS WITH PRIORITY 4
I have linked to another bug report that sounds the same at this, however, this time it has actually been commented on by a Linden Lab Employee. The bug is now sitting as resolved because they are waiting for further information. So if anyone can reproduce the bug, please get in contact with the linden who has asked for further information.
hey guys - sorry for the loonnnnggg delay. i'm looking into this bug.
but i have an intial question: will fixing this break existing content?? ok - i've done a bit of investigating.
what Strife says is correct - our walking animation has two different priorities (either 0 or 3) depending on the body part. now i'm wondering - do we really want to fix this? does it keep you from doing anything you want to do? it seems that if you want to override the basic animation, you set your anim to priority 4, which works. if you want to just override the top of the body, set the priority to 3. right? help me understand here so we can finally fix this. Priority 3 anims are not responding at all the way they are supposed to. Now its been so long since this has been broken, its hard to remember how it used to work. B4 priority 3's did not lock the head position, the head and also i think the waist still moved with the mouse. Now you might as well just use a priority 4, cause there is not much difference currently. I would also like to say that i think waiting this long to fix or address this is plain crazy. This is an animated world! There is also a major glitch in blend times, seems like some default anim is overiding for a second, in between anim transitions. This is most obvious when switching between anims that are in a seated position. Could this have something to do with choosing how to play the anims in the Upload window, ie- standing, walking, sitting? Why was this option added in the first place, what is the purpose?
No i dont think fixing it will mess up any of my products, dont think it has any affect on existing anims. I have priority 3 anims from b4 this problem that still work perfect. I'm sure alot of us will be going back and replacing those bad anims or correcting our work arounds, so we can give a better product. In my case, i just haven't uploaded any priority 3, or atleast not many, in almost a year. Had to point that out again, lol. @Qarl,
With show "Animation Info" does it show walking as a priority 3? I will have to look at this tonight when I get home. I locked every joint in the animation attached. From what I remembered all the linden animations where 2 and below. Of course it has been a while since I tested this and things have changed. This may fix alot of content out there as to why somethings don't work as expected 100% of the time. As for the Staning walking sitting option in the upload window this is for prewiew of content to see how it will work before it uploads. But it does not show correctly. This does not effect the actual uploaded animation. or at least from what I can remember. Geesh been a while. I had this on the old bug system before the Jira. Medhue -
yes, i know this problem has gone on far too long. i don't know how/why it fell through the cracks. all i know is that it's now being fixed. can you explain why the current behavior is bad? Gearsawe - i just checked: our bvh importer allows for per-joint priority. each joint may have a different priority - and i assume what's happening is that the walk animation has different priorities for the top and bottom half of the avatar. (that number shown by "Animation Info" only shows the default priority.) but again, i ask - is this a "problem" (aside from the fact that it's not documented anywhere?) Just another one of those things which does not work like you would think. If you set the animation to priority 3, set loop and set the preview while: walking the animation at priority 3 will overide the walking in the preview upload. but not when when walking in world. so I guess it is not using the same walk inworld as used in preview.
I can't remember the project I was working on a while back. was something like I wanted the rest position to be 3 and the actual animation to be 4. So the avatar would not do that weird pop into the default walk at the start. The intended effect was the 3 should have kept the AV from popping to the default walk till the 4 kicked in allowing for a slower Timer. The 3 would be left playing at all times so when the walk stopped it would revert back. But since the 3 does not completely overide the default walk it was rather annoying. Very interesting that LL gets to import their animations with different priorities per joint. Would seem to get rather complex to track what was doing what. Knowing that little tid-bit of info would have saved alot of people complaining about the animation system not working or is broken. What you see is not what you get Qarl Linden "can you explain why the current behavior is bad?"
This gives the impression that joint's priorities are changed at the whim of Lindens. Please tell me this is not the case. The simple fact that is was changed makes it bad. Seems that all the joints priorities are saved in the file when uploaded cause my old anims still play the way i intended, But now there is no way to get a new anim to react the same way. Why not allow us all the same right to choose the priorities of each joint. Then you'll see a wide range of configurations. I can think of 100's of things i would make if I could do that. This could change the whole way AO's are controlled and anims are played. For instance, for standing just using a few base standing anims and then playing different higher priority head, arm, and leg movements over top on the base stands. This can also make anims from different creators look smoother together as you may only be overiding a few joints. This may even fix the problem of height when it comes to sitting on the ground, hell i dont know. My heading is spinning now, lol. Gearsawe - well, perhaps i have good news for you. i'm looking at the bvh importer - and it seems to allow for PER JOINT priorities. or maybe i'm reading this wrong. if you're interested, look at llcharacter/llbvhloader.cpp.
Medhue - again, perhaps per-joint priorities have been there all along. about your concern that priorities change at the whim of Lindens - sadly, i can't explain what caused this initial change. maybe it was for good reason, maybe not. but right now, my concern is changing things back - because that's just as bad as the original change - it'll break lots on content. guys - i need more feedback here - i'm inclined to not make make any changes (things have stayed the same for at least two years now) for fear of breaking content. if anyone feels strongly otherwise, now is the time to speak up.
If no changes are to be made. Make the Preview window match what we will get inworld the since it does not at this time. And if possible have a list of animation joint prorites listed out for each LL default animation.
Reasons why you don't see this as a problem very much is people most of the time upload priority 4 aniamtions. being able to use 3 and even 2 for some things would allow us to be more creative. Heck even having the ability for a script to overide the default level for an animation for what an animation was uploaded as would be awesome. Gearsawe - good point - that's exactly what i'll do.
It seems to me that we need higher priorities. The built-in sit animations have priority 4, so any poseball-type animations need to have a priority at least this high, but there is nothing higher. So if I want to have my avatar use different sit animations from an AO, these should have a higher priority than the built-in sit animation. But it would be real nice if, when using a poseball, it wasn't necessary to turn off my AO in order to play those animations.
If I could have priorities of 5 and 6, I would make my personal sit overrides priority 5, and poseball animations priority 6. Instead we need to do "clever" things with scripts in order to get something that may or may not work. It just seems silly to have any of the built-in animations using the highest priority. i think that's a find idea - higher priorities.
does that have a jira yet? per request here is VWR-11975 for higher animation priorities
I'm seeing the default walk/run attempting to override even priority 4 animations I have uploaded this week so not sure what is going on. I see no reason making the WHOLE walk/run priority 2 could break content as what content uses parts of the default walk?? Actually on the animations page is says the walk is priority zero, which is what it should be. It's an ugly animation that EVERYONE overrides after the first day they are in SL. A walk override shouldn't have to be the highest priority to work. An example: I wanted to make a bridesmaid walk and instead of being able to upload a "regular" walk as priority 3 and then animate the arm holding flowers as 4, I had to make a custom walk holding flowers and then switch to a regular walk when not holding flowers. Insane amount of work for something that should be simple and this is done to make SURE the duck walk overrides something?? I don't get it.
Qarl, "i think that's a find idea - higher priorities."
Would that be necessary if we could alter priorities after they were uploaded? (BTW, the jira for that is http://jira.secondlife.com/browse/SVC-268 This would also help with lag, as right now to not have priority 4 anims show, scripts have to have fast timers to override them... :/ Crystal - sadly, making the priority mutable is more work than i think the lab wishes to do at this moment... (there are some tricky details with the per-joint priorities i mentioned earlier.) whereas raising the max priority is quite easy, and can be done immediately.
so yes, i do understand that the mutability is a superior solution... it's just too expensive ATM. Thank you for the feedback/insight Qarl!
 I hope you don't mind I CC'd your info on that Jira page so it would be seen where it applies?
On this topic, I'm worried that raising the max priority might cause more issues than we have now? Okies, so if the max priority is raised, all the current animations that would look atrocious if others played over instead (fingernails, drinks, bags, handcuffs, bondage, tiny or other avatar poses) will suddenly find their content broken by new animations uploaded at new higher priorities!? Creators still in game would have to re-upload all their animations and send out replacements, if possible, to their customers. While any items without replacements would simply make SL appear silly and preposterous as bodies would do things implausible... Right now we have a lovely system where stands/poses can be 2, dances 3, accessories (holding purses, drinks, cuffs) 4... If suddenly there's a 5, or up through 9, the standard will really fall apart disastrously it seems to me? Wasn't there a Jira for having a more integrated solution to everyone wearing AO's? Would this resolve this issue since then the default walk would be supplanted more directly rather than stopped and subsequently replaced via script? /me found it: http://jira.secondlife.com/browse/VWR-386 Eeps, with 339 votes! (LOL, and apparently I already voted for it...) Maybe something like that would render much of this moot? (Albeit also a bigger change, but at least one that wouldn't affect existing content, yet would reduce script load/lag.) Linden Lab has been doing a lot of this recently, incorporating the BijoRewind HUD into the viewer, features of radar HUDs into the minimap--wouldn't it seem the basic functionality of animations would be one of the key items? heh... again, yes, i hear exactly what you're saying. all this IS a better solution. but it's also "hard"... it's a much bigger project than i have permission to do in my current role.
so what i'm trying to do is find an "easy" fix - one which i can do now. otherwise, i think you'll be waiting around for a LONG time... I can't see any problems that would arise from adding a higher priority. Lots of AO makers will probably start making all their animations priority 5, but even if they never figure out the point of animation priorities, being able to make Priority 5 animations will at least allow other attachments to override current AO's reliably.
On thing that might help would be to change the box for setting the priority when you upload to a dropdown, giving examples for each, like 4 - Weapons, Handbags, etc something of that sort to encourage people to follow certain conventions rather than just selecting the highest one because they don't know any better. Adding higher priorities would create other problems and like someone else pointed out, most established creators would actually have to re-upload all their animations to suit the new system. So this might sound like a good solution to someone who is starting with the system but it would be catastrophic for all the existing creators, and it would complicate things for no reason. In the long run it won't do good to anybody. What would be much more easy and efficient would be simply to give priority 0 to all built-in animations without any exception. This is pretty much common sense as those animations are there only to be overriden, it's just a mystery why some of them have higher priorities.
Zoey: People are not selecting the highest priority because they don't know any better. Sometimes max priority is the only way. For example, anything other than the highest priority in something like a walk animation will be struggling to override the duck walk or won't override it at all (if it's lower than 3). Like some people mentioned, some of the built-in animation have very high priorities for no reason. Putting priority 0 for all built-in animations would fix all problems without any side effects. This may warrant a new JIRA entry, but I'll comment here first, since quite a few people are watching it.
I've been experimenting using the Advanced > Character > Animation Info. This displays active animations and their priority above each avatar. Also, the order seems important, because the most recently triggered animations appear at the top of the list, and when priorities are equal, the most recent seems to take precedence. My problem is that I can sit on a chair or dance ball and watch the animations that get triggered, together with others that are triggered by an AO I am wearing. However, if another avatar looks at me, the animations are all there, but they are in a different order, and this can affect the overall animation that is observed. In short, the animation that I see of myself is not the same as what somebody else sees. Further, if I stand up and then sit again with the 2nd avatar present, the 2nd avatar sees the same as what I see. My conclusion is that avatars see different animation effects according to whether they are present in the sim when another avatar triggers an animation (as opposed to already running it when the 2nd avatar arrives). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Fix Pending
Major
Animation Priority not working correctly
Then instead of nearly everything being priority 4, we could bring those down to play well with others. If there are higher priorities, then everything will be uploaded at 9 instead and it won't help anything?
Sadly so many don't understand and upload at max priority regardless of their animation's usage. So instead of anims complimenting each other, it's as if there's no priority system at all. So what is the solution? To make a script with a very fast timer that replays the priority 4 animation the customer wants to see in place of the (sadly) priority 4 animation that they are seeing. (An example would be a wedding bouquet, the bride wanted that bouquet, with the walk contained within, but not the arm positions.)