I don't think you'll find a faster lang.Math library implementation. I've even read that Android's lang.Math library, which uses floats instead of doubles, is slower. And the JDK implementation is written in C++ last time I checked.

A completely (un) educated guess of mine would be to see if you have GPU to spare. If you have, do the skinning on the GPU, if you don't, profile (VisualVM, free profiler for Java for example) and see if you can optimize the slowest parts of the skinning process.

- I use doubles for almost all my location and rotation values in the engine.

- I am doing the vertex calculations on the CPU with my own Math classes and what not.

- I am currently only using a single thread for the model updates.

- In java I am using the built in Math.sin, Math.cos, Math.tan for a lot of calculations.

This are all more or less all reasons for a slow down. Use the GPU for skinning, though bone calculations can be left on the CPU for now.

Multithreading should be a really big win for you assuming you're targeting machines with multiple cores. If it were C++, I'd say you should always use floats instead of doubles, I don't know about Java. Hardware skinning (using the GPU) is a trade-off - it will speed things up on the CPU and slow things down on the GPU, so it depends on your game's balance.

Another thing to consider is lodding. Can you switch to lower detailed models for distant skins? Can you reduce the number of weights per vertex for lower lod models? Can you get away with calculating the normal based on only the largest bone weight instead of all of them?

Put the skinning on the GPU. Todays gamer GPUs have such an incredible amount of computing power specialized for exactly this kind of calculations that you wouldn't be able to measure a difference even when your GPU is fully loaded.

Yeah, definitely go with GPU.

• As you add more functionality elsewhere the CPU load is also going to increase.
• Even if you thread it you've still got a max of 8 or so threads on current hardware; Even low-end GPUs have hundreds. And the threading is free, with no messy code required on your part.
• Even if you use SSE instructions, GPUs are still better optimized for this kind of calculation. Also free, with no messy code required on your part.
• Even if none of the above matter to you, you've still got a heavy upload of the transformed positions to do; using the GPU you only need a much lighter upload of bone matrices.
• As you add more animated models to the scene that heavy upload is only going to get worse; using the GPU the upload will remain considerably lighter.
• A GPU method allows for cool things such as different models sharing the same skeleton with much less overhead.

What keeps you from doing exactly the same in the shader? And don't tell me you're using the fixed function pipeline, I'm out then.

To stay in your terms: you usually combine the bone's bind transformation (the original position and rotation) in relation to the mesh, plus the current rotation offset and position offset, all into one transformation matrix. You end up with an array of matrices which you upload to the shader. You enhance your vertex structure to contain a number of bone indices (normally 4, because the fit nicely into an input register) and an equal count of weights that specify how much the vertex is influenced by that bone. So every vertex in your mesh says: I'm affected by bone 13, 25 and 5, with a weight of 0.3, 0.25 and 0.45, respectively. The shader now simply transforms the vertex by each bone matrix, accumulating the result weighted by the corresponding vertex weight, and you're done.