Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix some exporter inheritance mistakes and add more BVH export options #237

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

PierceLBrooks
Copy link

@PierceLBrooks PierceLBrooks commented Jan 14, 2024

This pull request will resolve some confusion surrounding the "Feet On Ground" export option for various asset file formats, as well as introduce extra options when exporting the animation/pose skeleton as BVH. This includes the exposure of "Dummy Joints" which before were always enabled by default, therefore unconditionally guaranteeing that the automated joint name retargeting procedure for whichever template was selected by the user will never yield discontiguous bones. Users should ideally be able to elect whether to exclude dummy joints, whose names feature a double under-score "__" prefix which can disrupt parity with certain skeleton templates such as the one for CMU motion capture data, and so it has been addressed here. Additionally, for the convenience of working within a project pipeline where animators must share motion data between different armatures in other tools outside the context of MakeHuman itself, a "Sort Joint Children By Name" option is also introduced so that the order of appearance for each child of a given joint node in the resultant BVH data is deterministic according to alphabetical sorting.

…nality with extra options for misc downstream project pipeline compliance
@joepal1976
Copy link
Contributor

Thanks. I've looked at this and it seems sensible. I've also done some cursory testing with exporting and opening a pose with and without your changes, and with and with the checkboxes in various states. I see no downsides of this.

I'll just ask someone else in the dev group take a look at it too before merging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants