I forgot I posted this last year.  Thanks for the replies!   :3

I agree with ending up not bothering with PMD. My experience is that it seems to sometimes act unexpectedly (predictably, but unexpectedly; one forgets it's about to generate a new pmd after certain actions) regarding where the morphs end up being stored. Embedding all the deltas in the project file wastes some space, but the storage behavior is entirely expected. I still wish there was a "central source of truth" type system for morph application where fixing/updating or adding a morph to a figure's LIbrary PMD could immediately apply to all existing projects with the figure, rather than having to manually re-inject and fixup morph keyframes for every existing project.

The opengl note had me looking into that. It seems opengl1/2 had a *minumum* guaranteed support for 8 lights in the spec, so any implementation had to support at least 8, but could do any number.. just if one wanted universal compatibility, the "Max" was then 8 light. Apparently opengl3+ programs generally implement lights as shader functions rather than using the built-in gl lights, so no hard limit at all (spec or implementation), just depends on a particular programs shader program how many lights are supported.. I think.  I guess Poser's opengl implementation just stops at 5 lights for the preview renderer, if the above is correct.  But I could be wrong about all the above....


For the slow down in the animation palette, it makes sense that every added keyframe requires some recalculation of all previous keys on the parameter, since the graph is a continuous function, so to speak.
   One caveat, however, is spline breaks. I'd think that adding a spline break to a parameter would then break that function calculation. In other words, there's no need to calculate the continuous function further back than the most recent spline break... This doesn't appear to happen. One can keyframe every parameter on a figure and spline break them, then the very next frame can become laggy when adjusting parameters. I think this *should* be the behavior, but maybe it just isn't, heh.
  Regardless, I noticed as mentioned that simply hiding the animation palette makes all the lag go away. The slow-down seem to be entirely caused by something the animation palette is trying to do when visible. One thing was calculating all those numbers on the frame boxes (which can be turned off as mentioned, but perhaps should be cached anyway to make it fast), but something else is still making it get really bogged down when a bunch of keyframes exist in a document.