|
|
|
I am also having the same problem. When my av is going through his poses, whether using an AO or the game default, his hands will frequently clench to a fist OR his fingers will spread out wide. This is NOT what my AO is supposed to do as I've watched it many times before. It's frustrating to look F-ed up and it seems others are having the same problem, even with only the game default running. Please help him to look normal again !!!!!!
I am having this problem also, although instead of the hands forming other poses, they are simply not changing. This happens every time I attempt to upload them as fists, whether it's both hands or one at a time. Any assistance with this would be very helpful!
Having just started playing with animations, I was perplexed by this behavior – it continues as of this date and version 1.8.3.5. Specify a hand position of Fist, or Fist Left or Fist Right upon animation upload – run the animation, and generally the hands do not fist, at least not right away. Sometimes, rarely, they do. Often the fingers will stay splayed initially, and then fist, and after a while, splay again. It seems random.
This is an on again, off again issue. It used to be (over 2 years ago) that if I uploaded with a hand morph as a fist, it'd actually stay. But it's always been that if you choose "relaxed" the hand postions of the default stances would show through: 1 hand fist -> both hands fist -> spread -> relaxed -> rinse and repeat.
It's been "fixed" a couple of times where the hand morphs would trigger but only for a few seconds until the default stance changed. But at the current time, they don't even do that much. We talked about this one in the Nov 26, '07 triage:
Would somebody attach a sample animation to this issue, as well as specific repro steps? I have IMd several residents listed in this jira asking for a sample animation to repro this issue. Awaiting response.
I saw the call for repro from Soft L., and also got the request from Jill L. regarding VWR-1793. I went back and checked some of the animations that had been showing this problem with the hand positions in October. While it was perfectly reproducible in October – NOW I cannot repro, either with the existing animations or with newly-uploaded copies of same. This is using the current WindLight viewer. I have a few more animations to try, but I am starting to wonder whether something was fixed in either the viewer or the server code since then – or if it's a transient based on grid loading? I will continue to attempt to repro, however.
I've just finished some testing on the most recent windlight viewer. Attached is hand poses.bvh a simple anim for testing purposes. Below are my test results. 4 different tests, twice each/.
In all of the below tests, the animation was uploaded at priority 4 with the "fist" hand pose selection. relaxed means the hand did not clench into a fist. Selectiing the hand pose had no effect For reference, by working perfectly, I mean that the hand pose starts when the animation starts, persists throughout the length of the animation, then stops when the animation does. This is the most logical way for it to work. In all of the below cases, this SHOULD have been the result. In the below results, it worked perfectly only once, and retrying the exact same configuration, it did not work again the second time. With a loop starting from 50% to 100%, it seems to consistently half-work, in that the animation starts as expected, but does not persist, and ends prematurely, a few seconds after the anim starts. 1a. Selected: Fist, no loop 1b. Selected: Fist, no loop 2b. Selected: Fist, loop from 50% 3b. Selected: Fist, no loop, No fade in 4b. Selected: Fist, loop from 50%, no fade in I have encountered this issue each time I download an animation (1/20/08). The hands are set to spread or relaxed, but cycle from open to closed. I had a friend download an animation with a static hand pose that was previously downloaded in Sept or oct of 2007 and now that animation opens and closes its hands. I really hope this issue recieves attention soon....
It does seem that the hand-pose problem has more to do with some problem in playback than it does in the upload-and-storage process itself.
i have it happen as well and also my older animations can no longer be uploaded to game did they lower the size allowances of an animation?
This happens to me every single time I try to upload an animation I've made for my quadrupedal cat avatars. I upload the anim with the hand fisted (so as to hide it within the cats-paw prim attachment of the avatar), but what happens is that when the anim is played, the hand position is fisted (as I instructed) maybe 1/3 of the time, and the rest of the time the fingers are spread, sticking out of the top of the cat's paw in an annoying fashion. I would really appreciate it if this bug were fixed.
What happens is that the hand settings of the standard standing animations of sl, override the hand settings of the animation you play. There are several positions for standing that are alternating and I think only in case of one of them the hand settings aren't overriding other animations.
(So this is not an uploading problem, but a priorities problem for the hand settings.) It looks like this issue is caused by looping and fading skipping the hand pose entry.
It seems to me that this glitch is caused by hand morphs not respecting animation priorities during playback. An underlying low-priority animation (like a system anim supressed by your AO) would then interrupt whatever pose you're trying to play, in respect to hand morphs.
For example, when you're playing an animation that supresses the typing animation, your avatar's hands may still play the typing hand morph, when you chat (but the rest of the typing anim is supressed as expected). I agree this needs some fixing. I spent a great deal of time trying to fix this issue, even delving into the viewer source code. It became apparent to me the actual problem is caused by an animation the viewer plays in the background, called (not suprisingly) hand_motion. It's only supposed to be Priority 1, however it has the unique ability to override even a priority 4 animation, with respect to hand postions anyway. I suspect this is due to some parts of llhandmotion.cpp which seem to favor HAND_POSE_RELAXED over other postions.
Using the Stop All Animations from the World Menu will kill this hand_motion animation, and after doing so, the issues seem to go away. But that also kills many other useful background animations, and sadly hand_motion can not be stopped by script! (if only it could). As I look at the first comment on this issue it seems to have been open for 1 year you allow users to disable the typing animation in the debug menu why is it so difficult to allow all default animations to be disabled in this manner. What ever or how ever this animation was created it is another example of your lack of attention to detail. This animation wrecks many other much better creations and is actually not required except for a silly motion that no one uses.
Updated to indicate still an issue under 1.20 RC and added more clarification to the title.
I've noticed this problem over and over, again and again, and it's really getting to me. It's a really annoying issue, especially when you have some hand attachment that requires your hands to be in fists, only to see your fingers magically popping in and out of the attachment 2-8 times a second.
I am working to synchronize the internal tracking with the Public Issue Tracker. internally this issue has been closed as needing more information to Reproduce.
Not much was updated on this public issue since January, but I see that recently residents have noted a modified bug behavior in the latest 1.20 viewer. In order to continue to investigate this issue, can the reporters of the (new) problem please Reopen AND update the Description with clear steps to reliably reproduce the behavior. (Please describe xactly how the bug behavior is manifested for that animation.) Be sure to mention any animations by name, and (if possible) attach the bvh files. If it's not possible to attach these them, please mention what animations I could contact you to utilize to observe the same behavior. I have to disagree that no major update has been made since January. If you read my comment Dated May 6th, 2008, I pretty much outline the full issue and point to the solution. However I will here attempt one last time to outline the issue.
Whe you upload an animation to Second Life, you are given the option to select a 'Hand Pose' , from one of 13 possible choices. These are presets defined by the viewer, and not part of the BVH. Looking at or supplying a BVH is not helpful. It is not an issue with the BVH. It is an issue with the specification of the Hand Pose in a given Animation after upload. How it should work: 1) I upload a priority 4 animation with a hand pose of 'Fist'. Anytime I play this Priority 4 animation, my hands should be fists, for the duration of this animation. If a Priority 3 animation with a hand post of 'Relaxed' were to play, the 'Relaxed' hand should be ignored, as it's a lower priority. How it currently works: 1) I upload a priority 4 animation with a hand pose of 'Fist'. Anytime I play this Priority 4 animation, my Hands may or may not end up fists, depending on what part of the long cycled "hand_motion" animation that plays in the background is currently playing. In addtion, if a lower priority animation plays (3,2 or even 1), the Fist hand pose I am trying to maintain inexplicibly will go to relaxed. The Animation priority is being ignored for hand poses. Providing a BHV is not helpful, it is how the animation is uploaded that is the key. In short, if I want my hand to remain holding something, in a fist, it should be possible. Incidental background animations of priority 1should not be overriding animations of Priority 4. Ways to fix: A) make hand poses respect animation priorites. B) allow the backgroud animation "hand_motion" to be stopped via script. My commend from May included again: " Darien Caldwell - 06/May/08 05:50 PM I spent a great deal of time trying to fix this issue, even delving into the viewer source code. It became apparent to me the actual problem is caused by an animation the viewer plays in the background, called (not suprisingly) hand_motion. It's only supposed to be Priority 1, however it has the unique ability to override even a priority 4 animation, with respect to hand postions anyway. I suspect this is due to some parts of llhandmotion.cpp which seem to favor HAND_POSE_RELAXED over other postions. Using the Stop All Animations from the World Menu will kill this hand_motion animation, and after doing so, the issues seem to go away. But that also kills many other useful background animations, and sadly hand_motion can not be stopped by script! (if only it could). " ReOpening and hoping Ramzi Linden can come to the rescue of ham handed avatars everywhere.
Darien, thanks for these clear explanations in the Description, as well as a clearer repro. I've reopened the internal ID and we can now track this issue again.
Thanks! Hi cracker hax, Darien-
we are having trouble reproducing this on the new 1.21 Release Candidate-- although of course we can reproduce it on an older viewer ,such as 1.19.1. It does now appear to be working correctly, to a point.
There seems to be one issue when two animations are of the same priority. Logically you would expect whichever animation was played last, would have it's hand position asserted. But under 1.21 this isn't so. Trying animations uploaded at Priority 4 as described above, but differing hand gestures, I see the following: Play the animation with 'Fist', then the animation with 'Spread' on top of it, fingers are spread . Expected Play the animation with 'Fist', then the animation with 'Point Both' on top of it, fingers are pointing. Expected I'm not sure what the viewer is basing it's decision on what hand animation to play, but it certainly doesn't seem to be 'last animation played'. Good progress however! Using the latest release candidate the defaults still over ride a p3 or p4 hand animation but they do not seem to be doing it as much. I also do not know if it is just a viewer side observation. Many times in the past I have seen my prim fingernails floating in space but my associates have not which leads me to believe that it is more of a viewer side problem. But, there are also times when we all see the nails in space ))
The fingernails have nothing to do with this issue per se.
The fingernails are a simple attachment at the hand attachment points. This attachment point is centered on the palm. When the fingers move, the palm does not change, hence the nails staying where they are. This could only be fixed through attachment points for each literal fingertip. or by allowing the hand posiion set by a p4 anim started by a script on one of the nails to remain unless overridden by another p4 anim
Darien wrote:
There seems to be one issue when two animations are of the same priority. Logically you would expect whichever animation was played last, would have it's hand position asserted. But under 1.21 this isn't so. Trying animations uploaded at Priority 4 as described above, but differing hand gestures, I see the following: Hmm I tried repro-ing this in my 1.21 but haven't had any success. When I did some experiments, the last hand position played would always be active. I uploaded the animation provided in this report's attachment (i.e. hand poses.bvh), set one to fist and the other to spread, and played both in world following different sequences. Let me know if I am doing something incorrectly: 1. Upload two identical animations per the original test plan instructions, but one with "fist" and the other with "spread" for hand poses. Well we use an animation regeneration script in the nails to try and overcome the default hand poses.
This controls the defaults most of the time but they still seem to break through. I have created multi frame relaxed hand animations in both p3 and p4 levels and the defaults of spread and fist still over write them. We have a switch in debug to disable the typing animation why not just add another for the default hand ani's. This would give users the option to control them. The new release candidate works better than the other viewers but is far from acceptable. The other solution for my problem is to add attachment points for the fingers I am sure the jewelry people would also like this )). It does not seem quite fair that the game can control fingers and we can not. Oh and Chalice no they are not directly related to this problem but do give a very visible indicator when the low priority default animations take control of the hand positions.
Actually Seraph, you are correct. I did as you outlined, and there appeared to be no issue. Where we differed originally was, I was using a 'fist' animation I had uploaded some time ago. It still does not work correctly, even though it is P4. However it does work by itself, and with other animations of lower priority.
This animation seems to have some odd issue. Could it have been formed or saved incorrectly? I can send you a copy of this animation if it would help. It does seem the issue is 100% fixed for newly uploaded animations. But perhaps not for older. :\ Edit: it actually seems to be something unique to that animation. (i'm attempting to only change the hand pose by barely moving anything else from the T-Pose. Maybe something about that the viewer doesn't like. I suspect many do this to change hand poses without disturbing the rest of playing animations. I'm attaching my raw BVH, hand_change.bvh. How long is this actually going to continue? It's been going on for a year and a half approx. and it's down right stupid that it hasn't been sorted.
Again, there seems to be a disconnect and confusion between the many reporters of this issue and Linden Lab's understanding and tracking of it.
According to the discussion by Seraph Linden above, this was fixed in the 1.21 viewer (original bug does NOT repro anymore). Paul, Coventina, TigroSpottystripes - what is the remaining bug that you are experiencing? Please provided detailed repro steps. I would like to track this in a new jira issue, as this issue is currently be tracked internally as "Can No Longer reproduce" as of 1.21. Well, really it is in regard to that 'fist' animation. The copy i gave you is old, but I uploaded it fresh that day as well, with no change.
It comes down to the goal of many creators in Second Life, Which is 'continuity' of the visual experience. I don't know your background Ramzi, so bear with me as I assume you're not an animation guru. The animation priority system allows animations to be 'layered', by allowing parts of an avatar's body to be animated, while other parts are left untouched, and continue to animate according the the lower priority animation underneath. This can be used to produce some very convincing and realistic effects in terms of avatar interaction. The huge problem with the hand animations is, as shown by the 'fist' animation I provided, small animations that change only the hand animation are being more or less ignored. Why would one want to only animate the hands? There are many reasons. For the appearance of holding things is probably the biggest. Holding weapons, sports equipment, maybe a cup of coffee, or even a glass of Kool-Aid (flavor your choice). While you could make a full fledged animation that animates the whole body while holding this Kool-Aid, it reduces it's utility. Say it was a standing animation, well fine, you could stand holding the Kool-Aid. What if you wanted to walk with it? Do you need to make a special walking while holding animation too? you could, but chances are Susan Avatar who justs spent 2000L on her favorite AO won't like your walk. What you could do is, simply animate the hand, holding the Kool-Aid, and allow her spiffy AO to handle the rest. Standing, Walking, everything. Of course this is just one example, I'm sure there are many others. Don't think we aren't grateful for all that's been done, but we are so very close to a 100% resolution. If short animations that for the most part only change the hand gesture were possible (like that 'fist' animation) Our dream would be realized. Conversely, if you could help us to understand why the 'fist' animation doesn't work, what rule or requirement it's not fulfilling, perhaps we could devise another form that would work. I'm still not clear why it doesn't. Is there a minimum length or some other criteria which must be met for an animation (and more specifically the hand setting) to be recognized? Thanks. Thanks for the additional comment Darien. To clarify, you are saying that we should use the newly uploaded file, hand_change.bvh (4 kb), to attempt to reproduce and isolate the bug.
I have reopened the internal issue for more investigation. Yes sir. That should be a good example of the lingering issue. I will verify again with the latest viewer that it's still an issue once I get home, and update if there's any change. Thank you.
 I'm also still experiencing this issue. One hand will be closed and the other spread open while playing animations. Quite a major annoyance for those who do a great deal of photography within Second Life.
What appeared to almost fixed is no longer in viewer 1.21.6 the hands still run the default animations over posed animations. Just on questions why do we have a series of useless automatic hand animations that cycle endlessly. There is nothing wrong with calling a specific hand ani but the auto cycling is worthless. Just remove the call for automatic cycling from the code or at the very least give us a switch in the debug to turn them off as with the typing animation
The first time this happened in July 2007, I wasted $3000L just uploading different anims, screwing with all the upload tools, loops, eases, in/out, fist right/left/both. Not too long after that, a fix was issued, and just before it was broken again, I uploaded a successful closed fist-only animation, which I have put in a wearable attachment, and I am glad to share it in-world with anyone who asks. I am having a hard time seeing why it takes over a year to fix keeping a fist closed, it's affecting business.
Is this issue ever going to be fixed is there any reason why the default hand animations require anything except relaxed during the default poses.
The spread hand default pose looks dumb on an avatar who walks around with their hands spread. These hand animations can be called during a pose but I see absolutely no use for them in the default. Please remove all the default hand anis except relaxed as they over ride a priority 4 called hand animation on toys. If you dont fix the small things there is no way you will ever fix the large issues. It's been almost another 6 months since the last resident comment and almost 9 months since the last Linden comment ~ and this is still an issue. Priority 4 hand animations are still being overridden randomly by periodic hand animation changes in both the 1.23 Live & RC viewers.
The same process outlined before will still reproduce this glitch. Additionally: Upload the hand_change.bvh with Relaxed Left Hand, and then again with Relaxed Right Hand. Worse: I though I had figured out something roughtly predictable last night. I could at least get the hands to cooperate some of the time when I wore the attachments I was working on (which are granted permissions to animate, using a looping relaxed animation). However, this afternoon, I couldn't get them too cooperate at all (they are just STUCK with the hands spread, regardless the animations applied either to the hands or via my AO being on or off). That said, upon relogging the viewer, I once again have semi-predictable behavior. I'd like to add my support to what Coventina said 6 months ago: "Please remove all the default hand anis except relaxed as they over ride a priority 4 called hand animation on toys." Well at least I am not the only one who thinks this is a major problem. I suppose we get tired to preaching to the abyss as to the lack of concern.
Simple question I suppose that default hand animations are called in the code like everything else in this game how hard is it to give us a switch in the debug menu to turn them off. After all the debug menu has more things in it than any sane person would ever consider touching. On another unrelated note there is an item some of you might be interested in. Open the debug menu and paste RenderVolumeLODFactor I noticed recently the default has been reduced to 1.250 put a 4 in the parameter box. Oh look sculptys now stay rezzed Duh I suppose with all the crap they are adding to the base viewer they needed to reduce it from the old default of 2. If you grow tired of watching skuls decompose as you walk away this will help. In closing we know that most of your customers never notice the silly default hand animations but this is just another situation of not paying attention to the details. Unassigning to bump back to triage.
I also want to see this issue resolved. I am trying to make an animation override for carrying a spear, and it requires that the right hand remain closed in a fist continuously so that the avatar grips the spear at all times. Every one of the animations in my AO is set to priority 4. Even at that, the right hand unclenches at intervals, usually when walking. The problem seems to be worse on laggier sims. If the issue cannot be fixed in short order, is there at least a workaround?
I support this cause.
My thing in Second Life is movies and photo's. I in particular like them with avatars. You can imagine how frustrating it is when a shoot or photo just won't work because an pose or animation just doesn't work right. In addtion: this is second life. We want our second selfs to be as good as it gets. Two words: STARFISH HANDS. I just bought a fancy new motion capture ao, and it would be nice if the fingers on my av's hands weren't, more often than not, spread out like a starfish. Thank you for listening. Workarounds encouraged.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Reopened
Major
Animations with incldued hand poses randomly overridden by other animations with hand poses and or 'hand_motion' (background anim)
I turned off my AO and SL's default animation poses do it also...This is totally unacceptable and should be critical. I cant believe that the most basic part of sl doesnt work correctly.