julienduroure
commented
5 days ago Hello,
where we want to support non-inherited scaling natively
As far as I understand what you are trying to do, this goes against the glTF Specification. Cf https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#transformations
The Blender glTF implementation try to strictly be aligned with the specification, and do not accept extensions not officially ratified by KhronosGroup.
So no PR will be accepted if this goes against the specification and/or ratified extensions
Implementation note : We bake data with bone world matrix, and then calculate local matrix to be stored in glTF based on parent node.
In our renderer we allow non-uniform scaling per bone but disallow scale inheritance on bones. We can implement an extension which can mark bones with their associated scale inheritance setting that we then use when loading in our engine. However, as of now when exporting a model with bones that have
Inherit Scale = None, that is automatically compensated by multiplying by the inverse of the parent transform so that, when the final values do get inherited in the client implementation, they end up correct.However, this is quite inconvenient for our use case where we want to support non-inherited scaling natively. It would great to have an option to disable the automatic compensation done currently so that such bones get their transforms output directly and the client implementation is in charge of handling the non-inheritance (for example when using an extension that labels which should inherit scaling and not).
I am happy to work on implementing this myself, but being unfamiliar with both blender and this plugin's conventions for transforms it's quite difficult to follow where and how compensations actually get applied (and for example as of now it must be happening "automatically" just based on which transforms are selected as there's no explicit branching based on scale compensation of bones like there was in earlier versions of the plugin, based on my searching for issues and PRs). So if you could point me in the right direction I can work on implementing this and PRing or if we don't think this is something that deserves to be a generic option then we could maintain a fork with the functionality for now.
Thanks!