I have a problem where I can’t seem to get the same rotation applied on my widget component as the actor parent.
First, I just did this:
WidgetComponent->SetRelativeRotation(GetActorRotation());
And that looks like this… works alright, but is 90 degrees of on the Z axis:
(The red thing is the parent actor, and the grey thing is the widget component. I want their rotations to match completely)
So, I tried adding 90 degrees to take care of the offset. Now, the Z axis works perfectly, but when I touch any of the other axes, they behave all weird and wrong.
WidgetComponent->SetRelativeRotation(GetActorRotation() + FRotator(0,90,0));
I’m not a math guy, so I think I need a push in the right direction. Thanks!
Hey christoffersch,
try to do this:
WidgetComponent->SetRelativeRotation(FRotator(0,90,0));
you just need to offset the component 90 degrees, but you are moving the component based on the entire actor rotation
Anyway I don’t know if you have attached the component, otherwise you need to call WidgetComponent->SetupAttachment or WidgetComponent->AttachTo
Hi! When I do that, the rotation just always stays the same and doesn’t update according to the parent actor.
I did try setting it up so that it was a direct attachment (WidgetComponent->SetupAttachment()), but that doesn’t make any difference.
My rotation logic is placed in the parent actor’s PostEditMove(), so that it updates in the editor when I change the parent actors transform
You are mixing up relative with absolute rotations. Use absolute. Only offset that result if absolutely required.
WidgetComponent->SetWorldRotation(Actor->GetActorRotation());
Thanks for reply. Hmm, I’m getting the exact same results using SetRelativeRotation() and SetWorldRotation(), offset or not.
If it’s any help, here’s what the hierarchy looks like:
ALgWidgetPopupActor::ALgWidgetPopupActor(const FObjectInitializer& ObjectInitializer) : Super(ObjectInitializer)
{
MeshComponent = CreateDefaultSubobject<UStaticMeshComponent>(FName("StaticMeshComponent"));
WidgetComponent = CreateDefaultSubobject<UWidgetComponent>(FName("WidgetComponent"));
WidgetComponent->SetupAttachment(MeshComponent);
}
And the rotation part, now with your changes (and with the offset, because apparently I do need that):
Even though I set it up as a child component of MeshComponent, it doesn’t automatically follow the parent transform (is it supposed to do that?), hence why I’m doing it manually in PostEditMove.
void ALgWidgetPopupActor::PostEditMove(bool bFinished)
{
WidgetComponent->SetWorldRotation(GetActorRotation() + FRotator(0,90,0));
WidgetComponent->SetDrawSize(DesiredWidgetComponentSize);
ShowDebugging();
Super::PostEditMove(bFinished);
}
This is the behavior you get if you add a scene component but don’t attach it to anything. Yet you attach it in the constructor. The only oddity I see is that you act in response to a change in the editor (PostEditMove) which might or might not work.
No settings on the widget component itself are interfering with rotation / location?
I guess it’s a possibility that widget components have trouble attaching to their parent? If it did that by itself, my problem would be solved…
I tried attaching a cube component (the white one) as well, and that follows the parent perfectly.
When I look at the cube’s rotation, it’s always (0, 0, 0) - because that’s its rotation relative to its parent, I suppose - but when I look at the widget component rotation, it’s something different.
Maybe there’s a setting in the widget component I’m missing, but I can’t really find anything related to rotation…
PostEditMove does get called, so the code is running.
What about the widget component’s space setting? I am assuming it is already in world space, not in screen space?
Yes, it is set to world space.
Worth noting that the location also doesn’t follow the parent by itself. And there’s no difference between picking “absolute rotation” or “relative rotation” in the editor in the transform section, the numbers stay the same
So most likely you saw this post too:
Making widget component stay above rotating actor? - #8 by Everynone
I’m a bit lost myself now, can’t think of any reason why the component would not follow a component it is attached to. You should comment the PostEditMove override to at least not modify things during an editor event, then put breakpoints within
WidgetComponent->SetupAttachment(MeshComponent);
to see if attachment is done properly.
If you don’t see anything obvious temporarily replace the widget component with a mesh in the constructor and see if that behaves properly. If so, the problem lies within the widget component.
Indeed it is strange, but thanks for sticking around.
I commented all the stuff I did with PostEditMove out, put a breakpoint at SetupAttachment(), which was hit. Went in and checked, same problem (as in it doesn’t follow the parent). I replaced the widget component with a regular static mesh component, and that worked just fine!
Perhaps it’s a bug with the widget component?
Yep, that seems to be the case then. You should still recreate a blueprint asset deriving from that c++ class and see if the widget component issue persists. if it doesn’t your blueprint had a bad or corrupt configuration. Otherwise debug the widget component.