When trying to use physics with scene nodes that have parents with non identity transforms, things get pretty wonky 
Here is example in lite: Babylon Lite Playground
Similar in BJS: https://playground.babylonjs.com/#YXFQG4#6
FWIW: I made an initial draft PR, with a first simple attempt of a fix
cc @Cedric
Try setParent(cube3, root); instead of cube3.parent = root;
Thanks, but the point here is: that is not how the glTF loader will do.
As I understand it, setParent will update the cube’s local transform, while the loader will keep the local transform and “just” add the top root node to handle the diff between RH and LH coordinates.
They have a whole section in the physics documentation about that very topic!
This is a problem indeed. Let me check your PR !
@Pryme8 The issue here is that the synchronization between SceneNodes and Havok’s transforms doesn’t take the node’s parent (if any) into account. setParent isn’t really a fix for this. Hope this explains better 
I’ve added comments on the PR. definitely an issue to fix 
@Cedric Thanks for the PR comments, I’ll try addressing them - though I think I may need help with at least some of them 
FYI: I’m in EU TZ (Copenhagen). I’ll post updates in the PR, but feel free to DM me if closer collaboration would help.
I’ve been following along on the CL. However, I’ve been trying to understand when I might take advantage of this. In what cases would you not want to attach the collider directly to the root of the transform tree? If a collider does have a transforming parent, what does that mean conceptually? I’m just curious and not intending to be critical. 
I’m sure this is just a failure of imagination on my part.
For me the goal is something like this:
Author a level with physics colliders in Blender, e.g. prefix object names with something like UBX. Then after loading the exported glTF, convert those to physics bodies. That allow me to easily do iterative level editing even with physics just using Blender. But for this to work fully I do need to use a scene graph hierarchy with parenting, especially if you think something like moving or rotating platforms, or a modular setup where colliders are children of the module root node.
Hope this makes sense
And of course there is the issue with RH vs. LH which causes glTF loader to always add a __root__ node with transform to handle this (in lite it scales x by -1, different from BJS).
Would also imagine this would impact ragdolls, though TBH. haven’t really played with those in Babylon (yet), so not sure how the details would work out there.
Can the gl* file describe the physics geometry, and does loadGltf respect that and wire them up? Or are you traversing the returned tree and hooking up the colliders yourself? If it’s the latter case, would it be sufficient to do a one-time bake of a nested model’s ancestor transforms, detaching the model subtree, and attaching the collider to the now unparented model?
Or are there use cases where you’d want a collider that is parented to a transform where that transform actually changes during the collider’s lifetime? If so, what does that represent? That’s where I’m getting confused.
There is a glTF extension for rigid body physics in the works, but AFAIK it’s still a draft.
Yeah, for static colliders you can “bake” them to world space (with a bit of vector/matrix math). But for animated colliders this becomes more tricky as animation curves are usually done in local space - and trying to “bake” those to world space often breaks interpolation.
Think e.g. moving platforms, swinging pendulum obstacles or similar, something like this:
Ah, I finally understand! This is primarily useful for animated colliders, where the ancestor transforms are part of what’s being animated. That makes so much sense! Thanks for the great example and taking the time to explain it!
