User talk:Coaldust Numbers
BVH Frame Rate
You wrote on BVH Frame Rate that "In practice, you should never use a frame rate above 45 FPS. Nothing else in the simulator can move at above 45 FPS." Simulator FPS has no effect on animations. The act of actually playing animations is up to the client. However I do think it's good advice, the human eye does not benefit from higher frame rates, especially since it gets resampled to match the client frame rate. -- Strife (talk|contribs) 19:09, 18 October 2011 (PDT)
I did indeed write that. You also pasted the explanation that immediately follows. If nothing else in the simulator is moving at above 45 FPS, why should your animation do so? It can't possibly be to stay aligned with something (challenging at best, given the bone length variation and potential for lag).
As for the human eye, my rationale has nothing to do with that.
Tests on top pilots done by the US Air Force have shown the recognition limit to be somewhere around 220 FPS. The test involved displaying a picture of one of several aircraft they'd been trained to recognize for smaller and smaller units of time. Some pilots were able to have accuracy above random chance until the time was reduced below 1/220th of a second. Pilots would report 'not seeing anything' at frame rates well below that, but were asked to guess anyway, and again, some remained above random chance until the pictures were shown for less than 1/220th of a second. I don't have references handy, but if you really care to look I'm sure Google will turn up something. Coaldust Numbers 07:42, 19 October 2011 (PDT)
Did I? ^_^' oh dear. Smoother dancing maybe? The animation could be synced to a high speed llTargetOmega (which is also client side). It's pretty unlikely. The high speed aircraft recognition research is fascinating. -- Strife (talk|contribs) 09:43, 19 October 2011 (PDT)
If the dancing isn't adequately smooth at 45 FPS the problem likely lies with the animator or the animation program (or bugs in the viewer...), not the FPS.
Further, given the 16-bit precision rotations and positions are stored in, having more than 45 key frames per second won't be visibly different unless there is very rapid, and significant, movement (think 22.5 jumping jacks per second; i.e. unrealistic movement rates), because otherwise neighboring rotations and positions will quantize to the same values.
The llTargetOmega thing is possible, but it's pretty nonsensical. There would be no way to reliably sync it with the animation. If you wanted to rotate the avatar while playing an animation rotating the hip works perfectly well, and would be viewable in the animation program. Coaldust Numbers 15:29, 19 October 2011 (PDT)