Slip slidin away ...

Although I'm very new to animation for SL, I understand that bvh files are affected by compression on upload: interpolation or tweening between keyframes often means that detailed motion is too slight to register in the file when it is played in-world.

Bearing this in mind, I do my best to avoid small, fussy movements. Even still, it appears to be almost impossible to manipulate the hip joint without setting the entire animation adrift so that the av starts floating like a stoned pixie or doing the soft shoe shuffle when it was only meant to shift its weight from one hip to another.

Does anyone have a tip, trick or some shred of advice on how to deal with this when setting up keyframes?

What software are you using to create your animations?
What speed, frames per second, are you animating at?
Did you remember to break spline on Frame 2?

My apologies for being vague, Deira. Being quite new to animation, I assumed that this issue is common to all bvh files handled by SL, regardless of the application used.

I use Qavimator because it allows me to enter and check rotation and positioning coordinates manually. I also have Daz but the interface is far too complex for me at this point on the animation learning curve. Also, unless I have overlooked it somewhere, I feel uncomfortable not being able to enter specific coordinates on joints in that application.

I also use bvhacker to check files prior to upload and that returns no warnings. I stick to 20 FPS because that seems to be quite adequate visually and I understand that SL compresses bvh files to this rate anyway. (Correct me if I'm wrong).

As far as 'breaking the spline' goes, I'm not familiar with that expression but I assume you're referring to the necessity of making sure all joints required in the animation are moved in frame 2 so that they are recognised as movements when uploading to SL? If so, the answer is yes, I'm always careful to do that.

The problem occurs when I need to manipulate the hip joint, which is virtually always for any type of animation other than a simple stand. Although I try to make the difference between my keyframes as significant as I can without exaggerating the motion too much and also introduce movement to every joint between the vital points of the pose and the hip, it seems that nothing is ever enough to stop the feet from sliding around.

I guess it is just a question of competence and the method will eventually click (or rather I hope so), which is why I was wondering how more experienced animators manage the problem?

It seems to myself, SL made a change to how animations work or I forgot something important. Because, the last time I made a complete animation was before christmas. It worked fine before then. I did cut the spile at frame 2, and I double checked each frame for foot positions and to be positive they were correctly in place, And it seemed to work. Didn't slide at all. But now I am triing to get back to work.

Now here we are in January, and I can't keep my feet still even when I only move my upper body. Seems I hover just enough, to appear to float left and then right while standing.

For those wondering, I am using poser 6, because I heard seven has problems, been IN SL since 2005, now using a

Processor: AMD Phenom(tm) 9500 Quad-Core Processor (2210 MHz)
Operating System: Microsoft Windows Vista (Service Pack 1)
DirectX version: 10.0
GPU processor: GeForce 8500 GT
ForceWare version: 175.16
Total available graphics memory: 1535 MB
Dedicated video memory: 256 MB
System video memory: 0 MB
Shared system memory: 1279 MB
Video BIOS version: 60.86.48.00.21
IRQ: 16
Bus: PCI Express x16

Forgot to mention...

My latest attempt at a stand, placing my weight on my left foot and tipping my hip to the left, in order to raise my right foot. This way I could raise my foot slightly off the ground to move it back and away. Next I would then tip my hip back down and turn it to the right, to put the right foot on the ground again. This resulted in being mirrored somehow in SL.

In SL it turned into tipping my hip right, dragging my right foot on the ground with my left foot in the air, then moving the hip to the left. The appearance of moving the hip in the reverse of what was intended and lifting the wrong foot off the ground. But in th elast few frames it would correct itself to be in the position I intended.

SL never used to do that to me before.
It would be nice to know if that was something others have experienced.

Thanks for your time, InuYasha Meiji.

I have seen references to a number of issues in other forums in connection with the latest viewer, some of them old problems, some more recent, which would not be surprising in itself since feedback about issues with any software is to be expected. However my experience is that the current viewer is undoubtedly the most unstable release I have used since joining SL in July 2007. There are many problems ranging from appearance and clothing textures that fail to rez properly, through to crashes when using the edit dialog on more complex prims and especially sculpted objects.

Specifically regarding animation, I guess the crux of the matter is that I would like to understand how much of this is down to my own lack of experience and how much of it is clearly due to bugs and glitches with the client/grid interaction.

For instance, another problem I am having with animations is that I cannot partially loop them properly - regardless of how I specify ease-in/ease-out or what proportion of the animation I reserve for the loop, which I have set at anything between 5% and 50%. Even though the first and last frames of the looped section are exact cut and paste versions and despite the fact that I have even tried holding the loop pose stationary for as much as a second at either end, there is an obvious jolt as the loop finishes and begins again.

I saw a reference to this as an old issue known as torso drift, which was supposedly fixed in a previous viewer but has evidently returned. For the time being I am trying to avoid looping parts of animations although it is something of a setback since these little codas on animations are a very useful feature.

I have a sword that when taking aim, makes my character appear to breath. I know it is done with looping and was triing to fill my AO with a more realistic stand and breath lightly looped animation. The same problem hit me too. It seemed no matter what I attempted, it looked like I had the hiccups because of that jumping loop/ No matter where I placed it..


InuYasha Meiji

There seem to be a number of problems interacting here and I'm feeling very converned that some previously fixed bugs seem to be re-appearing.

@ InuYasha
I mostly use Poser 7 for SL animating - Poser 6 needs an add-on to enable it to export bvh files correctly for SL. Are you using the official add-on download from the vendor web site?

Your foot drift problem does sound like optimisation issues - have you tried animating at 15 or 12 fps to see if this helps at all?

@ Ephraim
You need to move every joint slightly on Frame 2 - and this includes the HIP joint - move one HIP parameter a few degrees and see if this solves your problem. There will always be a bit of movement at the start when your avatar moves from whatever default animation is running to the beginning of the new animation. The Ease-in and Ease out times can be used to smooth this change - but a high Ease-in time can also obscure the beginning of animation.

I believe SL animations run at 12 fps.

@ both
Looping other than 0-100% or 99.99 - 100% is always a bit hit and miss because you can't specify specific Frames, only percentages. So I would expect a lot of problems in this area. The only way to overcome them, in my experience, is by clever design of the animation which holds a pose static for at least 0.25 seconds at the two loop points. This enables you to hit those places with the percentage figures more easily - but it may also mean some compromise in what the animation looks like. A truly looped animation would not have any duplicated frames - they would sequence perfectly round the loop - so this technique of holding a pose static for a few frames at a loop point can only work for an animation where this pause in movement is appropriate. FWIW, I can always see the loop in an animation, no matter how smoothly it runs. You also have to be very exact in the poses - any slight difference between start and end of the loop will show a noticeable jump. I always check the animation graph and make sure there are no frames with abrupt changes on any keys - it's very easy to miss one.

Yes I do use the proper patch and always have. It all used to work for me just fine. It seems to have become nearly impossible to continue to animate the way I always have just recently.

hanks for your time.
InuYasha Meiji

Are you absolutely sure about this, Deira? If it is the case, I will certainly set my animations to 12FPS since the higher frame rate would seem to be totally unnecessary.


I can tell you that I have moved every limb on frame 2 with the exception of the neck and head because I am working on a neck-free stand animation. Also the degrees of rotation are quite significant, not slight changes.

Perhaps the issue is connected to the high frame rate I'm using? Anyway, I'll take a look at both and see what happens.



I'll follow your advice here but as I mentioned above, I have tried introducing lengthy pauses at the beginning and end of the animation where the pose is more or less stationary and it didn't help.

Perhaps the jolt is connected to the other problem where the avatar's limbs shift about?

Thanks for your advice, Deira. I'll post a report here if there is any improvement.

I feel pretty sure that SL runs at 12 fps - I think this has been mentioned in other threads on this board. I must admit to a preference for working at 24 fps though, but this is solely for ease of arithmetic since 0.25 secs = 6 frames. The Poser default of 30 fps I find a bit anoying because that makes a quarter of a second = 7.5 frames - which is useless!

I forgot to say that you don't have to worry about breaking spline with QAvimator - it only applies to Poser and other packages that default to splinal interpolation. QAvimator only provides Linear interpolation, so you don't have to deal with this.

Please post an update back guys - as it feels as if we could have some old bugs creeping back into the latest client release.

Sorry to necropost, but this thread isn't that old yet. I've been animating for almost four years here in SL, with creaky old Poser (now Poser 7), and I still have the problem of the sliding feet. Things look stable and pretty in Poser -- and then I slip-slide all over the place in SL. It's always been a problem for me here, in every version of Poser, in every release of SL, in 30FPS or 15FPS or 12FPS.

My question is: how do the mocap people get around the slip-sliding feet? I mean, they're generating BVHs with subtle changes too, aren't they? Why aren't their frames dropped? I think my most recent hand-drawn anims look as good as many mocapped ones, but danged if I can't get them into SL.

That's a damn good question: I was wondering about that myself.

I would dearly like to find a solution to this issue. Animation fascinates me and I suspect I would be very good at it but I cannot justify the time and expense while this issue persists.

I think it's a combnation of things - the avatar skeleton and mesh has limitations as well as the effects of optimisation. Animations are also a client side effect - so you never know if you are seeing exactly the same as everyone else. Add to this different animating techniques together with SL "features" and many other variables come into play.

I've done some work with mocap and it is not easy and suffers from all the same limitations. A real-life dancer may dance as well (or not so well) as their ability allows them to, but they still have many more joints and a much more flexible skin than the SL avatar has - fine aspects of motion capture movement are lost on upload. Mocap does give you a result that equates to stop-frame animation though - every frame is a specific key frame and this eliminates an amount of "sliding" movement which the interpoloation algorithms can introduce into key framing.

I have noticed that SL will tend to lose small movements - it just doesn't seem to recognise them. By small, I mean just a few degrees - a diference of 4 degrees may be lost, but 10 degrees will be noticed. It seems to be that sort of order of magnitude. I'm guessing that this could be limitations of the avatar mesh and skeleton.

What do others here think?

A good animator will work with any bones and mesh and create an expressive movement. I gain inspiration from the great animators and cartoonists who can get their message across and create humour with whatever tools they have - a pencil and paper are sufficient for the great ones!

I totally agree with you: it is very true of any skill that we should learn to work with the limitations of the tools whatever those may be.

The problem for me, as a more or less complete novice, is that it isn't clear how much I can do to minimise the flaws in an animation and how much I would just have to live with because it is down to the way SL works.

/me makes sympathetic noises.

It is very confusing and annoying - don't give up Ephraim. There is no shame in being a novice - everyone started at sometime.

Hello people, this is my first post although I've been reading the forums like crazy trying to get to the 'root' of these problems!

Though some of you are novices to animation, don't let the way things turn out for you in SL put you off!

I've been working with motion capture for a loooong time, more than 10 years in fact. While it is true that the SL skeleton is limited, it is still more than possible to make a nice convincing human-like animation work with it. HOWEVER, this is not where our problems lie (From what I can tell, at least)!

I am using Motionbuilder, although the principals remain the same regardless of which package you use to generate your animations (I have run the same animations through different packages with the same results).

I am generating lots of varied and unique animations with data captured specifically to go into SL (Break-dancing, ballet, lap dances etc.) and the root animation appears to be the one thing which really does not translate properly into SL. My animations look great in Motionbuilder with no foot-slide and good floor contacts. Interaction with props (Chairs/poles etc.) all look great.

True, there is an optimising process which SL applies to all of the joints which does have some effect on the more subtle movements, but the root animation is really badly affected in almost every case.
This is really noticeable on the parts of the movements where the avitar bends over, squats down, stand up on something or sits down. Basically any major change in position or rotation. As the root is the top of the hierarchy, this altered animation completely ruins the floor and prop contacts!! There is also a rotation offset which happens throughout the duration of the entire animation and seems to be directly related to the rotation of the first frame of animation.

Second life has to be the most difficult platform I've ever worked with in terms of what you see is NOT what you get! This is outlined in the SL wiki:

http://wiki.secondlife.com/wiki/How_to_create_animations

Points 9 & 10 specifically address this (In a rather strange way) and basically it tells you to do your animation, upload it and then make changes in your animation package accordingly.

So, this is the way I am doing it:

1. Generate my animation in Motionbuilder (I use 12FPS which is about the limit for a 30 second animation due to the file size limit). Loop it and paste a T-Stance at frame 0/1.
2. Upload to SL, noting the root problems.
3. Return to Motionbuilder and animate the root up/down throughout the whole animation, guessing the heights and using my judgment to get it as right as possible.
4. re-upload file and repeat steps 2-3 until it looks good.

If anyone can learn something from this, or even tell me something that I'm missing I would be most happy! For now, I intend to struggle on regardless

Thanks for that Sigue. (Mind if I call you Sigue Sigue?)

My apologies for being an ignoramus but could you just elaborate on what you mean by the 'root animation'? I'm assuming from your explanation that this has nothing to do with the first frame since you mention using the T-pose there.

I think he means the HIP joint in the SL avatar skeleton - this is the top of the hierarchy and can also be called the "root". Move the HIP and you move the whole avatar - but it involves a few SL "features" that can only be solved by trial and error. (Not considering inverse kinesmatics here.)

Hi there,

Yeah, by all means call me Sigue!

Yes, I do mean the Hips when I am talking about the 'Root', this meaning the top joint in the hierarchy. Sorry for the confusion.

I am constantly looking for any way I can improve on the whole situation, as the 'Back and forth' route I am using at the moment is certainly a time consuming process. Frankly I'm not expecting there to be a golden solution for this though!

I am pretty certain that when using hand animation over the mocap route, there will potentially be less problems as the hips can be kept more level and less exaggerated throughout the animation. This will of course be dependent on the type of animation, but a hand animation does have more control at the outset and a mocap move is solely reliant on the actors performance.

I would be interested to know if people have used skeletons or rigs different to the ones provided by Linden Labs, or if there are any real success stories out there I'd love to know how this has been achieved!

I'm quite fascinated by SL and the concept of people being able to apply themselves creatively in a publicly accessible environment, a little different to the gaming/film/tv one sided platforms I'm used to working with.

If anyone has any ideas of motion types they'd like to see available let me know so we can capture them and get them into our shop. Most animations can be generated by hand, but some things are so complex that mocap is the only sensible route.

Cheers guys,

Sigue

Thanks, Deira. I suspected that was the problem for some time now. The trouble is that hip motion is pretty much an essential feature of even the simplest actions. Animations that fail to move the hips look downright odd to me - even at a glance.


Well, as I'm sure you're aware, rumpy-pumpy is quite a popular passtime in SL. However there is no shortage of animation in this respect - to the point where I think someone with entrepreneurial skills should collect as many existing examples as possible and open a compare-and-contrast style sex-museum on the new 'Adult' continent. That would be a Hell of a tourist attraction (literally!).

What SL is lacking, in my opinion, are good quality hugs and cuddles, which really cannot get over-used. Craig Altman at Bits and Bobs has produced some famously excellent handmade work on this theme. Most of the other examples I have found are either far too static or merely twee.

Bathing, showering, washing and shaving animations constitute another theme somewhat related to intimacy that is not well served in terms of quality animations. The same could be said for dressing/undressing: while folk tend to emote a good deal of those actions, I have always thought that it would be good to have a series of animations that reflect taking off/putting on clothes - either stripper style or in an everyday manner, which would be my personal preference.

Of course animation overrides are always in demand. Subtle, non-annoying stands and walks are virtually impossible to find however. I think this is partly to do with the need to exaggerate movement in order to avoid losing motion information when files are optimised at upload and also partly to do with marketing since eye-catching animations are more likely to get the attention of customers. The trouble is that overly-distinctive movements become very annoying visual ticks when you watch an av for any length of time.

Important A gentle lead-in/lead-out is essential for most types of animations I can think of but it appears to be problematical for animators working in motion capture. I say 'appears to be' because most of the examples in my inventory stop and start without any smooth transition to or from other animations. I'd like to think that is an oversight on the part of the animators, in which case I thoroughly recommend you try and include ease-in/ease-out of roughly 0.7 where possible.

@Sigue

Unortunately the SL avatar skeleton is the only rig you can use. You cannot upload a different one.

I would say mocap could score the best when providing natural, everyday movements that anyone can do. It's the simple things, like opening a door, washing your hands, greeting people, shaking hands, giving a hug etc that are hard to achieve in SL - and this includes more intimate interactions.

@Ephraim
Craig's my hero - he is so very creative and skilled in doing natural movements - which IMO, are much harder to do than are cartoon-type character ones. If you are skilled in using IK, then this can be helpful -but it's not available with QAvimator and not applicable to mocap work so it won't help everyone.

Through my experience with SL animation what is happening is that SL corrects the hip position to an upright position so when you animate the hips and change the angle of the legs to keep the feet in the position you intended they slide all over the place because SL
corrected the hip position. Nothing you can do about it that I know of. Same thing happens with mocap.
I animate at 15 frames per second. I believe that SL runs at 30 or tries to, and that any degree of movement that is set to 1 degree will be ignored by SL. Correct me if I am wrong.

I'm sure that Deira's recommendation of 12 FPS is correct. Xenon Linden made the same recommendation elsewhere and I have pretty much solved the happy feet problem in my OP by taking their advice and sticking to 12 FPS. Not only do the lengthiest animations load almost instantly and without any apparent loss of quality but it is also easier to find and correct movement falling below the optimization threshold at the editing stage.

Apparently the client tweens extra frames on animations when overall FPS is higher and the extra information in animations with more FPS is just so much unnecessary load on the system. Hence we get avatars stranded in mid-air with unnaturally twisted limbs or frozen like showroom dummies while the next file downloads.