Could I get some details on the specifics here and possibly the FBX you are using?
You exported to and animated the mannequin in Maya, reimported that animation, and want to adjust the attachment bone’s animation further?
And just to double-check, for the gif you posted above, that is in the animation viewer, not sequencer. Is there a primary reason to adjusting the bone there?
Using the code example, character source, and animation, I still couldn’t reproduce your issue. Is this something that you can build a little test project around in vanilla unreal to see if you can recreate it? Is there any other code you have added around bone adjustment in your hitbox setup?
In terms of your other question, you can’t access the current animation time directly. But you can get the current anim notify’s that are available and check if they are playing.
`void UMyAnimNotifyState::DrawInEditor(FPrimitiveDrawInterface* PDI, USkeletalMeshComponent* MeshComp, const UAnimSequenceBase* Animation,
const FAnimNotifyEvent& NotifyEvent) const
{
const float NotifyStartTime = NotifyEvent.GetTriggerTime();
const float NotifyEndTime = NotifyEvent.GetEndTriggerTime();
TArray NotifyEventReferences = MeshComp->GetAnimInstance()->NotifyQueue.AnimNotifies; //Get the current notify event references playing.
for (FAnimNotifyEventReference NotifyEventReference : NotifyEventReferences)
{
if (NotifyEvent == *NotifyEventReference.GetNotify()) // Test that the notify definition and the reference are the same.
{
if (NotifyEventReference.GetCurrentAnimationTime() < NotifyEndTime && NotifyEventReference.GetCurrentAnimationTime() > NotifyStartTime) //Test the accumulated time
{
FTransform Transform = MeshComp->GetSocketTransform(“HitBox1”);
FVector BoxExtent(5.0f, 5.0f, 5.0f);
FBox Box = FBox::BuildAABB( FVector :: Zero(), BoxExtent) ;
DrawWireBox(PDI, Transform. ToMatrixWithScale(), Box, FColor::Green, SDPG_World);
}
}
}
Super::DrawInEditor(PDI, MeshComp, Animation, NotifyEvent);
}`Here’s some modified code to show the example.
For the past few days, I’ve been looking for a fix, and will continue to do so. If you’d like to take a look yourself, you’ll want to start at FSkeletonSelectionEditMode::InputDelta and follow the code through to FAnimPreviewInstanceProxy::ApplyBoneControllers. Right now, the interplay between moving the widget to the updated location of the bone and the additive scalar data is creating the issue. Unfortunately, though, I don’t have a solution yet, which I was trying to do before I offered a suggested workaround.
The workaround I would suggest at the moment, is not to have additive scalar curves transform the bone, but instead add new named curves to animate the extent of the box. Then your hitbox code can look at those curves and animate those extents. The unfortunate bit here is that it means you are animating 2 set of curve data when you may only need one. The benefit is that scalar data may not work as well in the engine right now as just plain curve data, and if you end up blending during hitbox adjustments, this could serve you better overall.
The new TRS gizmos were just released in 5.5 and they are being built for animation in engine purposes, but are intended to be something we invest in for the future. I’ll look into why that might be solving your issue, because there might be other issues lurking there.
In terms of setting up a new gizmo, it’s not an easy process. You would need to setup a new edit mode and register it with persona. You can see how we do this with the SkeletonSelectionEditMode in PersonaModul.cpp
FEditorModeRegistry::Get().RegisterMode<FSkeletonSelectionEditMode>(FPersonaEditModes::SkeletonSelection, LOCTEXT("SkeletonSelectionEditMode", "Skeleton Selection"), FSlateIcon(), false);Then you would need to follow a lot of what we do with the SkeletonSelectionEditMode, overriding similar functions and then hooking it into whatever you decide to handle “selection”.
We took the skinned mesh from UE and rigged it for maya using mgear and made the animation from scratch in Maya.
The skinned mesh in the preview is an export from our Maya version but it’s using the same skeleton.
I attached the fbx from the animation, do you need to fbx of the skinned mesh as well ?
We want to edit it here becauseI’m trying to recreate a tool that we made for Unity where everything was centralized. So you could edit animation markers (Notifies) and animate the hitbox in the same place (among other things). The sequencer didn’t felt like the right place to do that
Thanks for the file. I was able to load it onto the UEFN Mannequin without any issues. That said, I couldn’t reproduce the problem with just the animation, which is where I initially thought the issue might be, so there may be some more back-and-forth here. My thought is there might be something unique about the newly skinned mesh or the approach you’re using to attach the hitboxes.
Having the skinned mesh as well could help.
Could I get an overview or file explaining how you set up your hit boxes?
When you’re editing your attach bone, just to verify you are:
For now my hitbox setup is a bit “dirty” but I have a NotifyRange “Hit” that has a drawer that looks for a socket “HitBox1” which is attached to the bone “attach”
(That being said I sidetrack a bit, but I wanted to change the color of the gizmo if the preview is in the range of the NotifyState. If you have an idea on how to achieve this)
[Image Removed]Then in runtime I spawn an hitbox blueprint and attach it to this socket
Yes when animating I’m doing what you said (but using the “S” key as a shortcut to add a key)
However it’s not very user friendly and I was wondering about switching everything to custom curves and having a custom Gizmo Handle to edit it. Without animating the “attach” bone directly. To avoid potential “user issues” and improve QoL
But I’m still quite new to UE and unsure about what’s possible/how to do it properly. By looking around I found this “UInteractiveGizmoManager::Create3AxisTransformGizmo” but couldn’t figure how to use it in my context
If you have some time to spare I would be very glad if you could give me some entry points on this
It was too good to be true, it seems that with non uniform scale when trying to move only on one local axis it wont follow the proper direction indicated by the gizmo
[Image Removed]
I guess I’ll need to find the time to look into setting up a new gizmo as you said
