You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks again Daniel for sharing this excellent demo - one thing that jumped out while tuning sim/adjustment is how distorted trajectory futures become. I expect this is not avoidable if you want correction but wondered if you had any thoughts/guidance on it?
With rotation correction turning the root faster or slower than the animation your future position features become deflected (of course they are, because they are stored relative to the queried animation frame) - for our content this means my 180 idle-to-jog get tossed out in favor of visually worse 'turning jogs' because of this deflection. Intuitively it doesn't seem like a benefit to matching quality, the future positions are not actually deflected in the animation (the turn 180 stays along the axis).
I can iterate with animators to more closely match the sim of course to reduce the harm but I wondered if you've already put thought into this?
The text was updated successfully, but these errors were encountered:
Yes it's a really good point, and something I think could probably do with addressing.
Perhaps one way to think about it is this - right now we adjust the immediate root rotation so that the simulation and animation match, but instead we would be better off adjusting the rotation so that the future simulated trajectory, and future animation trajectory match. If we did this we would only adjust the root if it means getting a match closer to what we asked for - and never adjust the root in a way that should deflect away from out request. Does that make sense?
Thank you Dan, it might take me a while to understand your suggestion - one thing I have tried quick was to capture the world space rotation at the point of transition/pose transition and use that as a constant w/the actual query feature frame rotation for query_compute_trajectory* transform of sim trajectories (instead of the continuously updated/corrected root rotation). This works... until it explodes during other transitions. I'm a bit out of my depths here but I will continue to hammer on it in case it bears fruit.
Thanks again Daniel for sharing this excellent demo - one thing that jumped out while tuning sim/adjustment is how distorted trajectory futures become. I expect this is not avoidable if you want correction but wondered if you had any thoughts/guidance on it?
With rotation correction turning the root faster or slower than the animation your future position features become deflected (of course they are, because they are stored relative to the queried animation frame) - for our content this means my 180 idle-to-jog get tossed out in favor of visually worse 'turning jogs' because of this deflection. Intuitively it doesn't seem like a benefit to matching quality, the future positions are not actually deflected in the animation (the turn 180 stays along the axis).
I can iterate with animators to more closely match the sim of course to reduce the harm but I wondered if you've already put thought into this?
The text was updated successfully, but these errors were encountered: