Aha! I think I follow now, thanks for the explanation. So to be sure though, what you have created can actually affect the skeleton being rendered. If I update the skeleton which updates my BoneComponent, then move my BoneComponent, it will move vertices associated with that bone. What about other bones that are children of that bone, will they be affected too, or only if you have further BoneComponent created which point to those bones? I'm guessing if you force all bones to be built you would have ended up with a nice hierarchy of parent and child bones as parent and child GameObjects. What about now that you can specify some bones and not others? How will the hierarchy be organised, if at all (BoneComponents could now potentially sit happily outside of the skeleton GameObject, you could even do something seriously stoopid, like make the skeleton a child of one of its own bones).
Also, does all this require using Skinned Mesh Renderers in order to work, as this will break dynamic batching between multiple skeletons using the same atlas, which may be a consideration for some people who have managed to batch multiple enemies, etc on screen, by not using multiple materials. If so could there be a system to batch multiple skinned meshes that share the same material and still preserve all of their individual functionality/animations? I'm just wondering how you reference to the mesh vertices you wanted to alter or if you assigned bones with weights in order to do the movement.
Was actually thinking of writing an implementation of SkeletonComponent that uses Skinned Mesh Renderers and Unity bones in order to perform the animation. But then FFD is coming in (which would be compatible) but Skinning I believe would to be almost like an FFD override (meaning you would still have alter mesh vertices each frame) rendering it kinda pointless. Doubt there is much in the performance differences though?
Again looking forward to having a hands on play so I can make further evaluations/suggestions. Rob 😃
