Baking to FK rig via python api, produces bugged result

using the python API method unreal.ControlRigSequencerLibrary.bake_to_control_rig (from now on i will call this the API method) is bugged, in previous versions it used to perform exactly the same result a right clicking on a skeletal mesh component and performing Bake to control rig -> FK control rig (from now on i will call this the editor method).

the API method produces bugged state when the component that it was applied to was already controlled by any other control rig. It used to correctly bake to the FK rig, but now it creates two sections, one absolute one additive, the absolute is invisible but infinite, all of the keys are on the absolute track and when i try changing the blend mode of the additive sections it either crashes or complete erases the metahuman, either way a bugged state.

using the editor method in the same circumstances always produces a single absolute section.

I included a plain project demonstrating this bug. There are 7 sequences (All located in /Content) all of them use plain Ada metahuman.

Steps to Reproduce
I included a plain project demonstrating this bug. There are 7 sequences (All located in /Content) all of them use plain Ada metahuman.

  • VanilaAnim - this is minimal example using an animation track on the Body component
  • VanilaMH - this is minimal example using a metahuman control rig
  • ManualAnimtoFK - this was created from VanilaAnim by RMB on Ada's Body component -> Bake to control rig -> FK control rig -> create, it produces CORRECT state
  • ManualMHtoFK - this was created from VanilaMH by RMB on Ada's Body component -> Bake to control rig -> FK control rig -> create, it produces CORRECT state
  • ScriptAnimtoFK - this was created from VanilaAnim by selecting the Ada binding in the sequencer and running the script_bake.py script, it produces CORRECT state
  • ScriptMHtoFK - this was created from VanilaMH by selecting the Ada binding in the sequencer and running the script_bake.py script, it produces BROKEN state
  • TTT - this was created from the VanilaAnim by first using the editor method to bake it into Metahuman Control rig and then by selecting the Ada binding in the sequencer and running the script_bake.py script, it produces BROKEN state

The script does minimal steps to correctly call the unreal.ControlRigSequencerLibrary.bake_to_control_rig method, it takes currently selected binding and works with it’s “Body” skeletal mesh component.

The script is located in the Content/Python/script_bake.py

The included project was created using vanilla version of unreal engine (5.7.4) downloaded from the Epic Games Launcher. It has imported the metahuman “Ada” from Bridge.

Hi, I’ve been looking into this issue and it seems that there are a few bugs in this area. To help track things down, it’d be helpful to get more information:

  • You mentioned the script approach was working for you previously, what version was that on?
  • What was the behaviour that you were seeing previously - it sounds like the keys in the exisiting FKControlRig section were completely replaced?

I spent some time looking at the behaviour that you mentioned with the TTT sequence using the script you provided and I see how the transforms are effectively being added to the keys on the existing tracks. However, when I try to do the same via the UI, the editor is extremely slow at baking out the keys, to the point where I haven’t been able to complete the process. So that’s why I’m interested to know what the previous behaviour was that you were seeing before upgrading.

Hi, unfortunately i don’t know which version of engine it was working at previously. The behavior that was previously was identical to doing the process using the editor, so that means that all of the keys are replaced.

I have never encountered the extremely long bake times during testing.

Hi, sorry for the delay following up on this. I needed to clear some time to go back through the repro assets. I’ve tracked down the reason for the difference in behaviour. There are actually two separate codepaths for the editor implementation vs the python implementation of BakeToControlRig and these have slowly diverged over time. The editor functionality used to be the same in terms of existing control rig tracks as the python implementation, but that changed a while back so that the editor implementation will remove any pre-existing control rig tracks so you’re just left with the new FK Control Rig track. The python implementation however, leaves the existing tracks. And if one of the existing tracks happens to already be a FK Control Rig track, that track is re-used which is what makes it appear like the bake has been applied additively.

Are you able to make code changes? If so, the fix to get the behaviour to be the same is trivial. It’s just changing the following code (around line 1323) in UControlRigSequencerEditorLibrary::BakeToControlRig from this:

				MovieScene->Modify();
				TArray<UMovieSceneTrack*> Tracks = MovieScene->FindTracks(UMovieSceneControlRigParameterTrack::StaticClass(), Binding.BindingID, NAME_None);
				UMovieSceneControlRigParameterTrack* Track = nullptr;
				for (UMovieSceneTrack* AnyOleTrack : Tracks)
				{
					UMovieSceneControlRigParameterTrack* ValidTrack = Cast<UMovieSceneControlRigParameterTrack>(AnyOleTrack);
					if (ValidTrack)
					{
						Track->Modify();
						for (UMovieSceneSection* Section : Track->GetAllSections())
						{
							Section->SetIsActive(false);
						}
					}
				}

To this:

				MovieScene->Modify();
				TArray<UMovieSceneTrack*> Tracks = MovieScene->FindTracks(UMovieSceneControlRigParameterTrack::StaticClass(), Binding.BindingID, NAME_None);
				UMovieSceneControlRigParameterTrack* Track = nullptr;
				for (UMovieSceneTrack* AnyOleTrack : Tracks)
				{
					UMovieSceneControlRigParameterTrack* ValidTrack = Cast<UMovieSceneControlRigParameterTrack>(AnyOleTrack);
					if (ValidTrack)
					{
						MovieScene->RemoveTrack(*ValidTrack);
					}
				}

Let me know if you’re able to test this. Otherwise, I’ll talk with the dev team about getting this change committed.

Just to confirm that I’ve committed the change I mentioned into the 5.8 branch so you won’t see this issue if/when you’re able to upgrade to that release