Egon,
I will do.

I'll try to post the code tonight, but I personally don't think you need to expose anything additional.  I was working on some refactoring/code-clean-up last night, as I wanted to clean it up before posting, and now it really needs to reside in the namespace.

Originally to test the functionality, I was using a separate shader for each 3D model instance and updating the uniforms manually on every frame.  Obviously this is not a good approach, but it was for quick testing of the shader and the passing of the data into shader.

Last night I tied it into the JPCT render pipeline, but in a sort of hacky-approach as I was attempting to add it without changing the JPCT library, which I'll describe below that requires the namespace.  The way the code works is as such:

• com.threed.jpct.GPUAnimated3D extends Animated3D (which extends Object3D).  In this class, I am overriding the void getInternalShader() call.  It needs to be in the JPCT namespace to override the call.  The getInternalShader() gets called once in the JPCT render pipeline on the render visList before it renders the object.  This method shouldn't really be exposed as its meant to be internal (as the name describes  ).  Inside this overwritten method, it fetches the shader and checks the instance name of the shader attached to the object and if it extends the GPUAnimated3DShader class, it will cast it and call a new shader method passing the GPUAnimated3D.  The class constructor fetches the attached mesh and appends skin vertex attributes if they don't already exist (cloning using same mesh)
• com.threed.jpct.GPUAnimated3DShader extends GLSLShader.  Kept in the namespace for uniformity.  This class constructor sets up handlers for the skin vertex attributes.  It also contains a method for setting the skeleton pose matrices as a couple of uniforms from a passed in GPUAnimated3D (called by the GPUAnimated3D).

This ties it into the render pipeline, where if the object added to the world is a GPUAnimated3D, it will update/override the shader uniforms, per Object, of its SkeletalPose before its rendered.  Now you can use 1 shader for all GPUAnimated3D objects and different meshes.

I just have a little refactoring to do tonight of moving the setAnimation() into the GPUAnimated3D (which excludes the code for applying the SkeletalPose to the vertices on the software-side), so that it only updates/creates the bone matrices.

It will be easier to see when I post the code.  Hopefully I will get some time tonight.

NOTE: I only checked the regular render pipeline.  It may not animate in wireframe rendering.

My model is about 500 polys and there are about 20 bones in the model.  If I add 20 animated models, the framerate drops to about 8-9 fps using a Droid Turbo 2.  Without the animation, the rendering stays at the 60fps cap.

Thank you for the note on the software / hardware, as that obviously would be affected.  Bounding box calculations, etc...  Thankfully I don't need to worry about any of that for what I'm working on.

I started working on moving the processing to the GPU, but it's going to take me a little time as I only get about 1 hour to myself at night and I'm not familiar with direct OpenGL commands.  But I will publish what I create with a "use at your own risk" stipulation.

It looks like I'm going to need to alter the JPCT core code itself for what I want to do.  I'm going to let the bones software handle the skeleton bone matrix transformations, and then pass in transform Matricies to the shader on every frame (what Bones calls the currentPosePalette).  Should just be 1 per every bone used.  The data for the weights and jointIndicies is going to be more troublesome for me as I would like to just have the shader use the weight and jointIndices as an attribute float[4] & int[4] based off the index of the vertex being processed.  I need to read up and do a little research.  Please feel free to drop me suggestions.

As a side-note, I have separated out the processing of the bone matrix transformations on every frame for the 20 models, and it keeps the framerate at 60.

More to follow...

No, I scaled the positions of all other bones by the factor.  In the skeleton, the bones all contain relative position and rotation offsets of their parent.  The scale needs to be multipled down the tree.

I discovered what the issue is.  It doesn't appear that scaling for bones is working.  My root node skeleton pose in the XML has a scale of 19.47.  This is not being applied and so the skeleton is 5% of its normal size in the mesh.

The reason why you see the nucleus is because the size of the bones and how small the skeleton is scaled.

I did another test scaling a bone in an animation.  The scaling did not transform when imported in jPCT, but it transforms in Ogre3d.

More to follow tomorrow when I verify either manually scaling the XML positions or finding a good way to normalize the skeleton scaling.

Sorry, I was playing with the export options in OgreMax and set a skeleton name.  Looks like it changes the export filename.  It should be the same XML file, but I could send it to you later on tonight of you'd like when I get a chance to get back on my computer.

I should explain a little what you're looking at in the screenshot.  It's an animation test since my full animations were not being properly transformed.  The knee should be straight out and bent down.  It appears that the shin bone is not properly inheriting the parent bone's transformed position.