I think the last commit on com.jme3.scene.plugins.blender.objects.ObjectHelper broke the parenting handling.
*10867 02.11.13 16:14 1 Kaelthas_Spellsinger@o2.pl Refactoring: simplified method that loads the object's transformation.I use parenting in Blender pretty extensively, mainly for animations. Now the objects are distributed all over the scene
Okay, reverting that change didnāt solve it all. The object are then initially correctly placed but as an animation starts the object jumps to another location.
There must be another related change which also introduced a bug.
Iād be glad if you could have a look at that too 
@arpagaus could you send me a link to a test file where the problem occurs ?
This is a test file which shows the bug:
https://dl.dropboxusercontent.com/u/14799295/test-parenting.blend
There is a perenting chain over 3 object and the last one has a rotation animation on it. If the animation is not started the two object are in completely different places. Once the animation start, the child object jumps to another location which still is not correct.
This still worked with SVN revision 10826. But I didnāt check which revision exactly introduced the bug.
@Kaelthas
Did you have a chance looking at this?
@arpagaus
Sorry, not yet 
I found one serious bug in bone animations loading and I focused on fixing that one first. But I will check out your problem soon.
@arpagaus
I just commited the fix. Update and tell me if it works
It turned out that blender does not always store the parent inverse matrix in the objectās structure āparentinvā field.
So instead of reading this field I read the parentās global matrix value and invert it myself.
And sorry it took me so long.
@Kaelthas
Thanks for your efforts! Here is what Iāve found:
Since SVN Revision 10914 there seems to be something wrong with the mesh and its getIndicesAsList() & getTriangleCount(). When calling MeshCollisionShape.createCollisionMesh(ā¦) I get the following stacktrace:
[java]
Caused by: java.lang.IndexOutOfBoundsException
at java.nio.Buffer.checkIndex(Buffer.java:532)
at java.nio.DirectShortBufferU.get(DirectShortBufferU.java:253)
at com.jme3.scene.mesh.IndexShortBuffer.get(IndexShortBuffer.java:53)
at com.jme3.bullet.collision.shapes.MeshCollisionShape.createCollisionMesh(MeshCollisionShape.java:148)
at com.jme3.bullet.collision.shapes.MeshCollisionShape.<init>(MeshCollisionShape.java:102)
at com.jme3.bullet.collision.shapes.MeshCollisionShape.<init>(MeshCollisionShape.java:81)
at com.jme3.bullet.util.CollisionShapeFactory.createSingleMeshShape(CollisionShapeFactory.java:214)
at com.jme3.bullet.util.CollisionShapeFactory.createCompoundShape(CollisionShapeFactory.java:112)
at com.jme3.bullet.util.CollisionShapeFactory.createCompoundShape(CollisionShapeFactory.java:134)
at com.jme3.bullet.util.CollisionShapeFactory.createMeshCompoundShape(CollisionShapeFactory.java:143)
at com.jme3.bullet.util.CollisionShapeFactory.createMeshShape(CollisionShapeFactory.java:173)
at app.scene.DesertScene.addRigidBodyControlMesh(DesertScene.java:374)
at app.scene.DesertScene.initTemple(DesertScene.java:108)
ā¦ 11 more
[/java]
Iām using native JME bullet, I havenāt tried it with JME JBullet yet. But there must be something wrong in the Blender import, because before that SVN commit, it was all fine.
Then back to the original issue: Since Revision 10922 some of the object in my scene are positioned correctly, but most of them are upside down (rotated 90Ā° along x-axis). So, it got kinda worse. Sorry for the bad news.
If you canāt reproduce the issue, Iāll send you the scene.
@arpagaus
OK, send me the scene then because I never actually used collisions. And send me the blend file you use.
The fix I made did not do anything with the mesh so I am 100% sure it did not break it.
But several days ago I made changes to mesh loading and added line and point meshes loading support.
Maybe that is what caused problems.
Thank you for your help. I saw your fix for the parenting and orientation, that looks good now 
As for the Mesh-Buffers: I have uploaded the mesh I have trouble with to: https://dl.dropboxusercontent.com/u/14799295/void.jme.blend
If you call CollisionShapeFactory.createMeshShape(ā¦) on the one Geometry, you should get the above Exception.
The problem with the CollisionShapeFactory is that it treats the Line meshes as if they were triangles.
Not so long ago I added line and point loading to the blender importer and this is what causes troubles.
The question is simple: should the CollisionShapeFactory take Lines and Points into account ??
@normen it looks like you took part in creating the class. What do you think about it ?
@Kaelthas said: @arpagausThe problem with the CollisionShapeFactory is that it treats the Line meshes as if they were triangles.
Not so long ago I added line and point loading to the blender importer and this is what causes troubles.The question is simple: should the CollisionShapeFactory take Lines and Points into account ??
@normen it looks like you took part in creating the class. What do you think about it ?
As arpagaus indocated the issue is not why you cannot create a collision mesh from lines or points, the question is why does it get this data to work on.
When I load an object from blender it often happens that I need to split the mesh into several jme geometries and put them in a single node.
I split the mesh in two cases:
The lines and points are being loaded because they will be used to properly compute the constraint target if a user sets it to be a vertex group instead of the whole object. So I need to have all vertices computed and stored in a single node.
That is why the line and point data get into the CollisionShapeFactory.
So I guess there are two solutions. Either we tell developers to be careful what they put inside the CollisionShapeFactory (but that would not be very nice because they would need to iterate through all the meshes and check their mode). Or we could simply ignore meshes of non triangle type in CollisionShapeFactory and log a warning or an info.
@Kaelthas
Thank you for analysing and clarifying. So itās pretty nice lines and unconnected vertices are supported now
But when modelling the mesh I wasnāt intentionally creating a line without a face and looking at the model now, Iām not able to actually find it. For example the first two vertices in the list are (4.700002, 7.2000003, -4.7000003) & (4.700002, 7.2000003, -5.0). Wherase the second is really a vertex there is none at the first location in my mesh. And there is definitly no edge between those. Is this something invisible which originates from my āstrangeā model or do you know whatās going on there? 
@normen
Could you add a filter in the MeshCollisionShape.createCollisionMesh(ā¦) methods which only treats the Meshes with the right Mesh.Mode? Or is there something I could help with? Thanks!
Okay, Iāve found workarounds for most issues. Iām using setUserData(UserData.JME_PHYSICSIGNORE, true) for non-triangle meshes for now.
@Kaelthas
Most of it looks fine now, the only issue that remains are Ipo animations and parenting. This used to work fine before SVN revision 10867
I guess the fixes you did on the ObjectHelper would need to be applied to IpoHelper as well?
Iāve uploaded a new blender model which shows the issue here: https://dl.dropboxusercontent.com/u/14799295/test-parenting.blend
If you create an animation channel and start a cycle animation on it, you can clearly see the difference to the version in Blender.
By the way, this feature makes using the blender importer really great keep up the good work!
@Kaelthas
A bit off topic, but I had an exception on MeshHelper:206 because Iāve used a Lighting material as default material in the BlenderKey. So Iāve added an additional in my local git repository:
[java]
if(geometry.getMesh().getBuffer(Type.Color) != null && defaultMaterial.getMaterialDef().getName().equals(āUnshadedā)) {
defaultMaterial = defaultMaterial.clone();
defaultMaterial.setBoolean(āVertexColorā, true);
}
[/java]
There are definitely more elegant solutions, but thatās all I need for now.
Would you mind adding it?
Seems like in the case of Lighting youād want to us āUseVertexColorā or your vertex colors will be ignored.
Why we have two separately named uniforms for the same thing in this case will just have to go down in history.
@pspeed
Yes, thatās right. But I omitted that because the case covered by that piece of code is rather rare. Itās only entered if the object has no material assigned but uses vertex colors. Very convenient for beginners or simple cases. But if someone actually changes the default material, theyāve got to know what theyāre doing anyway.
Thatās why I suggest that simple solution.
@Kaelthas
Okay, it took me a while but Iāve found the bug. As Iāve suspected it was the Ipo class. On commit 10585 youāve implemented a bugfix, but forgot to negate the Y-axis values on fixUpAxis. Iāve simply compared it with the previous version. Now my animations look fine again!
Could you please include the following patch:
[java]
diff --git a/engine/src/blender/com/jme3/scene/plugins/blender/animations/Ipo.java b/engine/src/blender/com/jme3/scene/plugins/blender/animations/Ipo.java
index 9922a14ā¦8e07684 100644
ā a/engine/src/blender/com/jme3/scene/plugins/blender/animations/Ipo.java
+++ b/engine/src/blender/com/jme3/scene/plugins/blender/animations/Ipo.java
@@ -168,7 +168,12 @@ public class Ipo {
translation[0] = (float) value;
break;
case AC_LOC_Y:
translation[yIndex] = (float) value;
if (fixUpAxis) {
translation[yIndex] = value == 0.0f ? 0 : (float) -value;
}
else {
translation[yIndex] = (float) value;
}
break;
case AC_LOC_Z:
translation[zIndex] = (float) value;
@@ -208,7 +213,12 @@ public class Ipo {
quaternionRotation[0] = (float) value;
break;
case AC_QUAT_Y:
quaternionRotation[fixUpAxis ? 1 : 2] = (float) value;
if (fixUpAxis) {
quaternionRotation[1] = value == 0.0f ? 0 : (float) -value;
}
else {
quaternionRotation[2] = (float) value;
}
break;
case AC_QUAT_Z:
quaternionRotation[fixUpAxis ? 2 : 1] = (float) value;
[/java]
Thank you!
Thank for finding it.
The fix is now in the svn