calculating hight offset

is there a rule of thumb to figure out the hight offset of the animation in qavimator, I know standing the default works for all hight but how much needs the hight raised for sitting on the ground and kneeling compared to the difference between standard hight and the hight of the avatar?

I do all sitting poses as literally sitting on the floor of QAvimator. For most poseballs this would be fine as you can adjust your offset via the config notecard - however it is always a good idea to plan for MLP systems where there is no offset ability.

This thread explain how to get your starting hip height higher while still keeping the avatar position where it naturally should be.

/52/1f/290370/1.html

It depends on what the animation is for.

If it's a sit animation for an AO, the offset should match the ones in the SL default sit anims that you can download from the SL Wiki.

If it's for poseballs, it's generally best to set the height significantly lower than the default, so that the poseball can sit well above the spot upon which the av would be sitting.

If it's for furniture without poseballs (e.g., using sit target positioner or "prim-sitter" scripts) the offset doesn't matter unless you'll be using a set of them, in which case they all need to be compatible so that they all look good with the same sit target. (This is also tru for use with MLP-like menu systems, since they use poseballs and you want the poseballs to be above the furniture, not buried inside it.)

It is for ground sits played from a hud, if I use the normal floor hight in qavimator I end up sinkin the floor for short avs and floating for tall avs so for a sitting and laying down pose the offset difference for a small av needs to be smaller then that for a default av but the question remains what is the relation between the offset number in qavimator and the avatar hight?

Aha, that's a trickier case. I think the answer is, there is no single correct answer.

If it were for an AO, where you sit on the ground and the AO plays the sit; SL moves your av down near the ground. In that case, the default height is probably the correct one.

In your case, SL doesn't move your av because it doesn't know you're sitting. However, the height of your av's hips from the floor depends on your leg length. If you set the offset so that it looks right in Qavimator, it will work right for avatars whose leg lenth matches the Qavimator/Poser default model (which is on the small side compared to SL avatars, I believe). Shorter avs will sink into the ground, and taller ones will float above it.

My guess is the HUD script has to do the compensation. I don't believe there's any way to get an av's leg length. If you were walking on the ground, I believe you could get the ground height, but you'd want this to work on any floor, not just the true ground.

One option would be to stick with the default offset, and have the script move the avatar down by half the avatar's height. IIRC, there's a tricky way for a script to get an estimate of the avatar's height, though I don't remember it. Might find it searching the scripting tips forum.

Interested in what others who've done this have to say.

OH, that's the question you asked in the OP. Sorry, kinda slow. I don't know the answer; I'd have to work it out by experimentation.

I did some testing to on this a few days ago. I suggest reading the thread Isablan Neva pointed to, specifically post #5 (/52/1f/290370/1.html#post2203738). Just to summarize what's mentioned there, the position of the avatar is determined by the hip location, and the hip location is determined by its translation from its original position in the default T pose.

That said, I've found that multiplying all translation values by 0.65 yields good results for average sized avatars.

I've never used QAvimator before, so I'm not sure how you would go about doing this in it. But let's say you have your character posed to be sitting on the ground. If you're able to look at the Y translation value of the hip joint, which should be some negative number, and then change that value by multiplying by 0.65, you should be off to a good start.

In my own case I have this automated through script that does the multiplication at export time. And it seems to work well.

HTH