Bbones (Bendy bones) to normal bones converter

Actually, if you really want to use BBones for export in mass production (not a single case, I mean), there is some setup to achieve that. But you need to bind mesh skinning not to BBone itself but to ordinar bones (let's call em OB). As you know, BB interpolates its weight all across segments smoothly. We can use it in mechanic way: you should create as much OBs as there are segments of BB, and place each OB about where the corresponding BB segment is located. Next - constraint each OB to a whole BB with Armature Constraint (don't parent OBs! They already inherit all the transforms via Constraint) And the last step - skin mesh gradiently to each OB. In the end you'll have a bunch of OBs that take their transforms in a spline-BB way. All the BB functionality is preserved. pasteall.org/pic/6477ca262cac4f808ca1d07fe9df41a0

Yes please. Would be useful to be able to use BB in game ready assets.

If this Automation for Bendy Bones Conversion is made, please ensure that the Bendy Bone Splines/Sets (Bendy Bone + its Start & End Handle Bones) ALSO work for curved states already from the Skeleton/Armature Object's Rest Position.

Note that the few tutorials (e.g., from Dikko and CGDive) which currently exist on this subject (I call it: 'Conversion of Bendy Bones to Regular Bones'), do not cover the case scenario I've mentioned.

Here is a concrete example of use, that I timestamped this video, on the mentioned challenge (Curved, so not Straight, Bendy Bone Spline from the Rest Position)(use Shift+> and Shift+< to control Youtube's video speed because this was recorded Live, and not as a tutorial): youtube.com/watch

To be fair, I do not know technically how this kind of particular, extra Automation for B-Bone Conversion, in the original Request, would work for this kind of 'Curved' case; but it should include it, right? It might be much more difficult implementation? But no one is saying that a Bendy Bone must always start Straight, in all cases. This would be a misconception by default; so I'm providing this piece of information so that this doesn't become a developmental mistake.

PS: But there is even another technical question for the main Request: it is that there are actually DIFFERENT ways the ending state of the Converted Setup (for example, in terms of the Bone Constraints which are employed) will be. So, if we get this Automation, can't we choose between a preset of solutions? Naturally, would have to map which would be those solutions to start with... this is not trivial. I think there is the Armature Bone Constraints solution, but there is also a solution with Copy Transforms Bone Constraints, and there is also the 'famous' splitting solution of the latter one, into Copy Location + Copy Rotation Bone Constraints combo. And there might be other ways and some info I'm missing right now on detailment of all the solutions mentioned.

Actually, the best way to avoid issues where you make assets that use features unavailable in your target is to not use those features in the first place.

In this case, whenever your target is a video game, it's common knowledge that nothing besides simple bones/joints and blendshapes can be trusted on export. If you build a rig whose target is a game engine, it shoul avoid stuff like bbones and use other stuff that only influence simple bones, like ik chains, ik splines, stretches, ... All that stuff can be baked as simple XYZ Location Rotation Scale data. If you really want bbones, you could maybe at least have a bbone as a controler, but the bbone actually influences simple bones used for deformation.

To me it seems that converting bbones deformations to bones once animated is a waste of time. Because for each frame of your animation, you would need to:

for each frame:
    for each bbone:
        for each bbone subdiv:
            somehow get transform coordinates
            create a new bone using said coordinates
            orient & scale newly created bone

And all that at risk of failure at each frame, inconsistency of asset, and so on. You're better off just creating a rig suited to your needs.