Thanks for replying and the welcome.
The reason I am using parent-child may be illustrated by considering the spine. If vertebra N bends forward by 1 degree then verebra N+1 moves with vertebra N and is now in a different orientation with respect the the world, in addition it is very likely that vertebra N+1 is also bending forward itself by something like 1 degree since human beings tend to bend a region of spine rather than one vertebra. The parent child relationship is ideal for this because it takes care of this automatically, I can ask all vertebra to bend forward by 1 degree and what I get is a curve just like you would get with one of those wooden articulated toy snakes.
Regards performance overheads, that is fine, the way this will eventually work is that I will be able to pose the skeleton in various ways with my own keyframe system, all angles of all articulated joints will be recorded for each keyframe and then I will spline through those angles to get the “tweening” - performance does not matter, its not for real time (game) animation - video frame by frame and so on.
I am not actually ‘changing’ vertex data on each frame since I am applying transformations - there is no baking during movement, the complex mesh vertex data is not being written to, only the transform matrices that are associated with each mesh are being changed.
I do use the baking process once at the very start, this is because for some bizzare reason to do with the original skeleton data - the bone OBJ files are all centered around something like ( 0, 0,7, -1113 ) so to make life easier I first transform and bake the skeleton centred on ( 0 0 0 ) but after that there are no more bakes - it just means a reduction in coding complexity for me - do it once and then forget about it.
Thanks for answering the question ie that when a mesh moves into a local frame it is not automatically adjusted (either by means of slow and direct vertex modification or by means of a transform which is fast ) with the consequence that the mesh will appear to move as it becomes a child because its data is still relative to ( 0 0 0 ).
As I mentioned I am dealing with this issue by storing an accumulated offset vector for each successive vertebra in the spine, this is used to transform ( but not bake ) the vertebra so that it does not appear to move when it becomes a child of another and so stays in the same place relative to the rest of the skeleton. What is achieved is that although the vertebra does not appear to move, its centre of rotation is now relative to the previous vertebra and in addition it now gets “automatic updates” in the sense that a rotation on vertebra N results in all vertebra after it ( N+1, N+2, … ) changing position as you would expect. I just wanted to check that I was not doing this “the hard way” and that there was not some feature in Babylon which would say "change to this local co-ordinate system but alter the meshes transform so that the action of parenting does not move it relative to the global co-ordinate system.
At the moment I have all cervical and thoracic vertebrae “rigged*” - and that entire section of spine is moving in real time without any noticeable delays - so far Bablyon seems to be handling it with ease.
*by rigged I mean by means of my own bespoke code.
I am very impressed with Babylon - my project demands a lot of it and so far it is handling everything with ease, the only complexity I envisage so far is writing a constraints manager to deal with some of the more complex bone relationships which will not be fully handled by the parent-child relationship.