Hi,
Gltf doesn’t support skeletons without skinned meshes which is a part of the spec.
In my project we still need a way to export skinless skeletons with gltf. That’s why I added an extra step where I add bones info (skeleton name and the base matrix) to the nodes which I know are a part of the skeleton. This lets me to restore the skeletons on the client.
Here is a playground I created to demonstrate the issue I currently have with such manually created skeletons. PG
As animation is playing you clearly notice that the bones update the transforms with a delay.
To point out that it is actually an issue I added a commented-out line to switch to a completely similar animation but on a skeleton with an attached mesh.
[UPDATE] If you comment out the displayMode switch, the skeleton doesn’t move at all and stays in bind pose which seems just like a bug. Moving this to bugs.
I presume some update is not being done in time or it could be something with SkeletonViewer.
Would appreciate if someone could point me in the right direction.
it looks like there is something up with the original line view method.
Not sure why its not working, might have something to do with the _effectiveMesh maybe?
Just kind of find it odd that the new methods work but the original does not, when in the past the was the opposite XD.
I did notice something that could be changed with the displayMode changing that could cause issues on a unrelated topic, so maybe ill fix that and see if we can toggle back to line mode and have it work.
Hi Andy!
Yeah, If I comment out the line: skeletonViewer.displayMode = BABYLON.Debug.SkeletonViewer.DISPLAY_SPHERE_AND_SPURS;
the skeleton is displayed with lines and it just faces down without movement.
The flicker is kinda subtle. Not actually a flicker but more like a delay in the update for bones which are lower in the hierarchy. It is most noticeable when animation restarts.
You can compare it by un-commenting a line with a completely similar but skinned glb. (just under the original LoadAssetContainer call)
Yeah got to look out for my friends at Pixcap ^_^.
I kind of see the flicker you are talking about now, hmm this is interesting. Ill get with you in the slack chat sometime here soon. I gotta finish up other work this week before I turn my focus.
So I looked over this a few times, and really am drawing blanks on why the line render one is having trouble.
The blip at the end also is odd and the only thing I can think of is there is something up with the timing of the animation in the data itself or for some reason when the animation is restarting there is a odd update per bone happening that for some reason we are seeing. The mesh parts themselves are just weighted to the bones, so it’s gotta.be something up with the bikes matrix updating.
What really kinda stumps me is that we don’t see that same hangup on regular animations or other animations using the skeleton viewer. So I’m kind of leaning toward there is an error in the animation data or some reason the bone matrices update is getting jacked up?
I see. Thanks for the investigation.
The issue is really super weird. In Blender I export the exact same animation but with a mesh skinned with this skeleton and it is displayed just fine which confuses me a lot. And when I remove the skinned mesh and export the same file, it is displayed with that blip and with a delay on bones which are lower in the hierarchy.
You can check it by uncommenting the //BABYLON.SceneLoader.LoadAssetContainer("https://dl.dropbox.com/s/s95jwj471v8wchr/", "skinned.glb", scene, function (container) {
line in the original PG.
I still feel that some update doesn’t pass through correctly.
I’ll dive a bit deeper into the sources to find out what’s the problem some time soon.
its got to be the matrices then are being calculated at a different time for some reason because the only different factor in all of that would be what mesh it was attached to. Which then I think we can deduct that it has to be some sort of inverse matrix calculation error.
For the lines render issue, I think that’s what is happening is this: _displayLinesUpdate calls _getLinesForBonesNoLength, which in turn calls childBone.getAbsolutePositionToRef(mesh, points[0]) and parentBone.getAbsolutePositionToRef(mesh, points[1]), to get the positions of the bones and draw a line between them. Checking the execution on the debugger, I noticed these values weren’t changing at all, even through the animation is playing.
I think this happens because the mesh in question the same mesh argument that was passed to the SkeletonViewer, which is skeleton.overrideMesh in the example code, and this mesh isn’t being updated along with the skeleton’s animation.
Figured out the cause of the flickering.
I had to sort bones in the newly created skeleton by their hierarchy. I was not aware of how bones matrices are updated with their linked tnodes. I guess that is expected behavior but would be good if someone can clarify that.
Here is the working PG
Thanks a lot