-
-
Notifications
You must be signed in to change notification settings - Fork 178
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
AutoBone bone contribution fix & cleanup #1249
base: main
Are you sure you want to change the base?
Conversation
So my current conclusions based on my tests are:
DataExperiments performed using 11 of my decent quality recordings on the latest commit (0baeb32), values are in centimeters. Results from 0.13.2 were either very obviously bad (hips too wide, head shift too short, etc) or produced an error value so bad that it triggered the max error limit, these were tested but not recorded in this section. Experimental results (very long)DefaultheadShift: 10.6 (SD 0.86) Initialized equalheadShift: 11.27 (SD 0.85) Shortened (50)headShift: 10.52 (SD 0.86) Shortened (50) lower starting rate (1.0) initialized equalheadShift: 11.82 (SD 0.6) Shortened (50) initialized equalheadShift: 11.32 (SD 0.84) Extended (400)headShift: 10.74 (SD 0.86) More pairsheadShift: 10.96 (SD 0.88) No lengthheadShift: 11.01 (SD 0.93) No length extended (400)headShift: 11 (SD 0.89) |
good paper, thanks for the full explanation |
The bone contribution part of the AutoBone algorithm (
getDotProductDiff()
) seems to have been broken for a long time... Whoops! For this PR, I fixed contribution and ended up changing it to a metric that makes more sense. This is a fairly major change in the algorithm.To explain bone contribution works, how this occured, and how this PR changes it:
slideL
/slideR
= The difference in the global position of the ankle trackers between frames 1 and 2.boneOffL
/boneOffR
= The difference in the local tail positon of the bone (with rotation applied, this isolates the bone's effect on the skeleton) between frames 1 and 2.slide
andboneOff
as unit vectors, then apply that as a multiplier for the adjustment value. By computing the dot product between these values, we should get a vague estimate of exactly how much each bone is affecting the overall sliding and whether it needs to be shorter or longer. This sets a very clear target for the algorithm and guides it in its descent to the optimal proportions.So far from my limited testing, this seems to make the algorithm perform significantly better. I also plan on working on a bit more cleanup of legacy code, but this is already pretty decent. Legacy code clean-up will be performed in a future PR in order to speed up code reviews.