We are attempting to create a BP which is attached to a SKM controlled by a CRIG.
It would be convenient for us to be able to create this BP as a child of CameraActor, however when we do this (as opposed to creating a BP inheriting from Actor and adding a CineCamera component to it) we get very unpredictable behaviour when trying to manipulate the CRIG controls in the viewport. You can take a look to the video CameraUnreal\BP_Camera_CameraActorChild\Demo_InheritFromCameraActor.mp4 and compare with CameraUnreal\BP_InheritFromCameraActor\Demo_InheritFromActor.mp4 (which is the expected behaviour).
Notice we can manipulate the control rig via the attribute channels but not by selecting controls in the viewport.
For this set up we are referring to set us such as those outlined in your dev community forum:
We have stripped this to the essential to make sure to isolate the issue.
There is no logic in the BP construction script, just the On Pre-Initialize control rig logic.
See attached CameraUnreal\BP_Camera_ActorChild\BP_Camera_Actor.jpg and CameraUnreal\BP_Camera_CameraActorChild\BP_Camera_CameraActor.jp
The BP set up between the two version (Actor child vs CinemaActor child) is otherwise identical.
We are using the same SKM and the same CRIG. We assume it has something to do with the CameraActor class.
Steps to Reproduce
We are attempting to create a BP which is attached to a SKM controlled by a CRIG.
It would be convenient for us to be able to create this BP as a child of CameraActor, however when we do this (as opposed to creating a BP inheriting from Actor and adding a CineCamera component to it) we get very unpredictable behaviour when trying to manipulate the CRIG controls in the viewport. You can take a look to the video CameraUnreal\BP_Camera_CameraActorChild\Demo_InheritFromCameraActor.mp4 and compare with CameraUnreal\BP_InheritFromCameraActor\Demo_InheritFromActor.mp4 (which is the expected behaviour).
Notice we can manipulate the control rig via the attribute channels but not by selecting controls in the viewport.
For this set up we are referring to set us such as those outlined in your dev community forum:
We have stripped this to the essential to make sure to isolate the issue.
There is no logic in the BP construction script, just the On Pre-Initialize control rig logic.
See attached CameraUnreal\BP_Camera_ActorChild\BP_Camera_Actor.jpg and CameraUnreal\BP_Camera_CameraActorChild\BP_Camera_CameraActor.jp
The BP set up between the two version (Actor child vs CinemaActor child) is otherwise identical.
We are using the same SKM and the same CRIG. We assume it has something to do with the CameraActor class.
Hi, sorry it’s taken a couple of days to follow up on this. We have a bug with the control rig component functionality in UE5-Main which I had to fix before I could investigate what was going on with your setup.
The problem is that the Camera Actor overrides GetDefaultAttachComponent and has that function return the camera component and not the root component, which is the default behaviour for most scene components. That becomes a problem because, when you’re in animation mode with sequencer open, the gizmos for manipulating the control rig controls are actually actors which are supposed to be parented to the root component of whatever actor owns the mesh. But in the case of the Camera Actor, the gizmo has been parented to the camera component, which you’ve also parented to the mesh. So now we have a circular dependency where we have mesh -> camera -> gizmo -> mesh which causes the odd translation issues you’re seeing.
I have a small fix for this, if you’re able to integrated code changes. Currently in FControlRigEditMode::CreateShapeActors we have this code:
// setup shape actors
if(ensure(ShapeActors))
{
const USceneComponent* Component = GetHostingSceneComponent(InControlRig);
if (AActor* PreviewActor = Component ? Component->GetOwner() : nullptr)
{
for (int32 Index = 0; Index < ShapeActors->Num(); Index++)
{
if (AControlRigShapeActor* ShapeActor = ShapeActors->operator[](Index))
{
// attach to preview actor, so that we can communicate via relative transform from the preview actor
ShapeActor->AttachToActor(PreviewActor, FAttachmentTransformRules::KeepWorldTransform);
That should change to:
// setup shape actors
if(ensure(ShapeActors))
{
const USceneComponent* Component = GetHostingSceneComponent(InControlRig);
if (AActor* PreviewActor = Component ? Component->GetOwner() : nullptr)
{
for (int32 Index = 0; Index < ShapeActors->Num(); Index++)
{
if (AControlRigShapeActor* ShapeActor = ShapeActors->operator[](Index))
{
// attach to preview actor, so that we can communicate via relative transform from the preview actor
// use the root component explicitly to avoid cyclic dependencies for actors where the default
// attachment component isn't the root
USceneComponent* ParentComponent = PreviewActor->GetRootComponent();
ShapeActor->AttachToComponent(ParentComponent, FAttachmentTransformRules::KeepWorldTransform);
With that, we no longer have the circular dependency so the gizmo should be able to move the bone on the mesh, which in turn will move the camera, without then affecting the gizmo again
Thank you very much for looking into it. Unfortunately we do not do engine changes. Is there any other way of working around this that you can think of? Or is this something that could potentially make it into the engine in the future? Thank you
Hi, no sadly there’s not a lot that can be done to fix this at the bluerprint level since you can’t override GetDefaultAttachComponent from blueprint. I did look at whether you could manually reparent the gizmo actor from being under the camera component, to instead be under the root component, as it would be with a standard actor. But it turns out that the control rig code actually forces the re-attachment each frame, so that blocks you from reparenting. So at the moment, the only workaround is the one you already had - use an actor and recreate the same component setup as with the camera actor.
The dev team are happy for the changes I mentioned previously to go into the next release, so I’m going to do some further testing on those. Assuming everything works as expected, I’ll get them included in the 5.8 release.