Open mottosso opened 3 years ago
One thing that came to mind is that, well yes we are modifying the rig each frame. But so is regular old playback! Whenever the hip moves, so does all the children, and Maya is able to cope with this in parallel. Yes, we are modifying animation curves.. But does adding keys matter? What if we pre-create keys and only modify their values? Furthermore, what if we didn't do keys, but instead tried a setAttr
approach? Having the hip move via a curve node versus a setAttr
should not matter, right? If it does, then what if we make a node specifically for this purpose, that we can manipulate outside of calling setAttr
, because odds are the command itself forces a re-evaluation. If changes are coming from our node, then that would be treated like any other output from any other node.
Recording is currently a two-step process, each running through the full timeline, e.g. frame 1-100.
Step 1 is fast as the simulation is fast, and as far as Maya is concerned can run in parallel. No Maya data is modified during this step, so the Maya Evaluation Manager won't have to recreate its internal graph.
Step 2 is slow because we must once again evaluate the rig a second time, but this time cannot do it in parallel as we modify the rig each frame. As a result, evaluation happens in a single thread, and the evaluation graph is recreated each frame. It can be infinitely slower, depending on the complexity of such a rebuild. From taking 2x longer than simulating, to 100x longer. From taking 5 seconds, to taking far too long for comfort.
So, is there a way to avoid step 2?
rotatePivot
can be animated and change over time. Resulting in an unreliable recording unless the animator explicitly guarantees that this relationship holds true.I find this problem difficult to solve, but also difficult to explain. It's complicated. But important. It's the difference between taking 500 ms and 50,000 ms to record a simulation. Given that we can evaluate the entire rig, read-only, over the full timeline, in parallel there must be a way in which we can then turn around and use what we evaluated to generate appropriate local Translate/Rotate channels without re-evaluating the rig.
So I'm leaving this here as a record of where I'm at right now and hope to solve this in the future as my understanding of the problem grows. If this sounds familiar to you reading this, or if you have any further ideas, feel free to comment on this issue.
Example
Here's an example of an IK hierarchy, representing our markers, being animated and recorded in worldspace. And then re-applied to another hierarchy, that assumes a linear, FK relationship between each recorded marker.
https://user-images.githubusercontent.com/2152766/138073786-f2b62d28-ae7b-435b-9174-38f13615743d.mp4