Afternoon,
Following the excellent responses from a previous question regarding how to get the attachment node from a model, I’ve come to ask for help with accross an annoying problem: The Attachment Nodes are in the wrong place, by which I mean the world translation & rotation do not match the rendered model.
Setup
Making things more complicated is the tool chain I’m using, Blender 2.62 → OgreXml → JME SDK to export the JME3 binary, where that model is loaded and a Bullet Physics control is added in code.
Symptom
To diagnose the behaviour I’ve attached rectanglular boxes to the Attachment Nodes for each of the model’s bones, within the model space they appear to be rotated by 180 degrees on the x axis., however they correctly follow the model when the parent is translated and rotated, suggesting the issue lay from the model node down
The orange boxes extend in the y axis, although when rendered they look to extend in the z axis (local rotation perhaps)
Model
Below is the model as wireframe with bones in Blender3d (with z-axis up)
Physics
The physics control is a custom one that extends PhysicsRigidBody, set on the model node and moves and rotates correctly, mentioned for completness (or in case of unintended side effects).
My Take
Okay, I’m currently thinking there’s a link between the model in blender (extending in the y axis, same as the boxes added to the attachment nodes) and the rotation needed applying to the blender model when it gets into OgreXml format …but, that’s just a thought.
Seen this before?
So, has anyone encountered this before? Solved this maybe?
Narrowing it down
After spending a few hours trying to diagnose this at a high level, I’ve gone as far without going delving into how the location and translation of these attachment nodes are calculated within the JME3 animation codebase.
If you’ve not seen this before, any insights into an efficient diagnosis when looking through the JME3 codebase would be appreciated, or if I’m overlooking something
Thanks!
– Update –
After a few hours more investigation, it turns out that the problem was somewhere in the exporting of model from blender, something to do with the version of the blender2ogre and ogre (io_export_ogreDotScene.py) and Ogre Command Line tools.
Unfortunately I’m unsure which version I had that produced the original output, however after updating with the latest available (which were of different sizes, probably different versions) the following was achieved:
That’s the attachment nodes in the correct places!
Strangely the world rotation of the bones is still setup for a y-axis up coordinate system, however for the time being it workable.
Versions of the ogre exporters
OgreCommandLineTools 1.72
blender2ogre 0.5.5
Believe I’ve just relearnt and old lesson about being able to easily identify versions of libraries you’re using 
The SDK contains the ogre command line tools, you can import .mesh files and generate LOD levels in the SDK directly (and thus be sure about the version being used). The SDK also contains the blender exporter (though it best works with 2.62 or 2.63 w/o using bmeshes).