—
As things stand it's been pretty difficult to get them optimized, and this has been delaying their release. The way they're implemented currently in three.js is less than ideal for some purposes and it's not trivial to change it. They're not useless, just the number being used at once should be limited, the number of bones kept to a minimum, etc. I leave this up to the developer but it makes skeletal animation more difficult to apply than morph animations, the game programmer has to control when and where to use them carefully, and when to initialize/deinitialize models. The reason they're expensive is that one "skeleton" is actually made of many hierarchic objects, say 30 bones, so it's as if you have 30 extra objects per skeleton. On top of that animation incurs an overhead and search structure to find how and where to tween, and to calculate the quaternion interpolations. Right now i have it so that it also creates construct object "bones" so that you can manipulate those with events/pick them/test for collisions etc. again this makes using the system easy, but also makes it slower. Morph animations are just static frames shoved into the gpu. It can render them incredibly fast so they're a bit more appropriate for a Javascript game where CPU use should be kept for doing game logic.
I really do try to optimize things as much as possible but sometimes it's a very difficult trade off between doing that and making the system easy to use. I do my best to try and optimize things.
The exporter is really dumb, I didn't write it. Eventually i hope to make some pull requests and add useful functionality. For now you'll have to manually rename. These things tend to change with time since three.js is an open source project, and I try to stay within a version or two of the releases.
smebor
obj format dont support anything like that, they're pretty much model data only.