[SDK 3.8.2-beta] Please provide changelog with technical words when it's hard to describe with normal words.
available in future release
anatawa12
Please provide changelog with technical words when it's hard to describe with normal words.
In SDK 3.8.2-beta.1, there's one fix described as "Added a validation error that prevents a humanoid avatar from being uploaded if it has a nested armature." and Nested Armature is described as "the root of the armature is not a direct child of the GameObject containing the avatar's animator."
However, this is misrepresented or partially incorrect depending on the interpretation of "armature". There's no "armature" in the unity world (as far as I know and searched) but a few similar or related concepts.
When I see the description, I came up with several hierarchy structures like:
1) Having independent FBX model with bone skinning inside an avatar. (If made with blender, typically contains GameObject named "Armature")
2) Having same FBX model as avatar root with removing no objects from root model hierarchy. (If the avatar is made with blender, typically contains GameObject named "Armature")
3) Moving the bone hierarchy (if the avatar is made with blender, typically contains GameObject named "Armature") to the child of new GameObject in the avatar.
And I tested them and only last one is detected as "Nested Armature"
This should means the error is shown if the avatar's root's Animator component's avatarRoot is not same as avatar's root.
However, the description of the changelog, it's hard to know 1 and 2 are not the case.
Therefore, could you add the technical description when it's hard to describe without them in addition to current description, for advanced avatar developers.
Log In
_
_tau_
available in future release
_
_tau_
We try our best to provide as much detail as possible, however sometimes it is not easy to formulate something in a way that is understandable to everyone. Point in case: It took me a really long time to understand what your 1), 2), 3) points actually mean, and knowing what the code actually checks for I find our description much clearer. I don't really see a boundary of "technical" or "normal" words at play here.
That said, I will bring the feedback back to the team and see if we are able to adjust the wording for the final changelog.