i just wanted to post some thoughts on the new animation package… overall am happy with it… but there are things that causes some hassle , which are :
1) Source targets and hints Objects: current scripts lacks methods to set an IK goal/position through scripts… this makes our scripted solutions need to reference the source transforms to update their location in runtime which cause additional hassles>> A) character prefabs… the source target and hint must have them all as child gameobjects… otherwise the prefab system can’t serialize them… so i must i must add them in prefabs as childs… which this also leads to another hassle >> B) updating source hassle… sources will have local positions that don’t correspond to world location, i have to make my scripts manually and constantly update them every frame… this means the scripts will have to do extra job on something already been decided in one frame in which the location in the world should be!
a perfect example is a walking cycle for a large robot, if a robot walks slowly i can easily set the position / rotation of the desired location, and let the ik scripts handle the rest using the input data i given… no need to update the location… only when i need to move the feet for example into new location… currently i have manually edit it otherwise it will drag it self due to it’s parent movement. i thought maybe by unparenting it in runtime…but ik went all wrong… it’s too much hassle already
2) Multiple Generated Animation outputs???: I noticed in the Visual Graph, the current ik scripts generate multiple animation outputs… is there any reason for this or is it a bug??
it looks kind of cluttered in the playable system with multiple animation outputs… each character might have 3 or 4 easily ((if i would add my own output animation for my playable manager… ))
i wonder if possibly stacking all these animation script nodes to one animation output?
here is it why it’s weird… my current playable mixer solution adds one animation output… (2 from ik scripts, 1 from my script) but the animation went all jittery on me!!
so i figured that maybe i need to make the mixer flows through the ik scripts… so i dug up though connected nodes just to find the first one… then connecting my mixer to the first node… then i got rid of jittery animations! great!
but have you seen the oddness in the current implementation?? (if it is not a bug)… the ik scripts is allowed to generate multiple OutputAnimations and they have no issues working together… but it is an issue when i add my own animation output… it should be one way or another… either allowing any script adding new outputs to work in harmony without jittery, or constraining ik scripts to stack under one animation output…
If you wish to set the Transform component that defines the goal on the constraint, you can set the TwoBoneIKConstraint.data.target parameter to a new Transform. However, be aware that changing the transform dynamically at runtime after the animation rigging playable graph has been built will not update the goal as you would need to rebuild it for the changes to take effect.
Losing transform bindings in the scene when creating a prefab is unavoidable considering how prefab works. However, you could just hook the scene transforms to your constraint like explained before after instantiating the prefab in the scene. You could keep the RigBuilder component disabled by default so that you can do your own initialization before enabling it and creating the PlayableGraph.
Yes, the PlayableGraph created for Animation Rigging has several outputs, this is no bug. The first output handles the SyncSceneToStream playable chain which synchronizes scene values to make them available to the Animation Rigging jobs. Afterwards, the other outputs handle the multiple Rigs set on your RigBuilder. The Animation Rigging outputs are set to use the previous input evaluation values so that they behave as a post process step to what was evaluated before (see Unity - Scripting API: Experimental.Animations.AnimationPlayableOutputExtensions.SetAnimationStreamSource)
We created a separate PlayableGraph in order for Animation Rigging to play nice with other animation systems. This way, we can use Animation Rigging with the Animator state machine or Timeline or your custom PlayableGraph.
However, in 2019.2, we are missing a proper sorting order to better control when a PlayableGraph is evaluated in the Animator. While the Animator state machine always has priority on all other animation systems, we’re not guaranteed that the Timeline PlayableGraph will be built before the AnimationRigging graph and thus in the right evaluation order.
In the meantime, to ensure your PlayableGraph are evaluated in the right order, make sure to also create them in the same order. By controlling when RigBuilder becomes enabled, you will also control when its PlayableGraph will be built, and thus change the evaluation order.
thanks for help, i figured something similar to this while posting the thread, but that’s why i posted this thread…
to improve and make working with this new tool more intuitive!
i figured that i would have to resort into some extra management on these new transforms (creation/referencing/deletion/etc) … but rebuilding and such i never thought of… this adds even more reason why i think having goals to be set by simple position or rotation can be better in some cases. there will be no need to rebuild anything.
i tried calling my manager class which creates a playableGraph…
then after it i called rigBuilder.Build() also tried rigBuilder.enabled=true
this doesn’t work directly from script… the ik scripts seems not running.
i still have to disable/re-enable rigbuilder in scene during playmode in order for it to work… but then it works fine! it seems i need to enable it later after animator plays or something?
@simonbz I’m hitting the same issue, first try with the AnimationRigging package.
I can’t regenerate the avatar as it’s greyed out:
Any ideas?
Edit: turns out removing the avatar makes that option not greyed out and then Animation Rigging “works” but of course I lose my actual animation. Not very useful. What am I doing wrong?
Note: I’m on 2019.3.0b3 with Animation Rigging 0.2.3
After trying this for a while I decided to take a look at the Ninja project. Turns out, that guy is cheating - he’s using a Generic rig, not a Humanoid one! Switching over to a humanoid rig breaks the whole Animation Rigging system, in that example project and in my project. What’s going on? Isn’t this supposed to be working on Humanoids?
Quick forum search reveals:
a) people having the same issue with no reply for a month now
b) an answer from Unity that it “should work” on Humanoids
The SIGGRAPH workshop ninja character was not advertised as a humanoid rig. There are indeed issues when converting the character to humanoid. The humanoid avatar in this instance seems to be creating issues with the rig constraints. A new avatar is normally generated under the hood whenever there are new rig references so that they are added to the avatar, but there seem to be issues in this case. We’ll have a look.
Animation Rigging is still in preview. We are working on bringing in new functionalities and addressing issues as they come in. As always, the best way to make sure we address your workflow issues is to submit a bug through the bug reporter in Unity.
We’re doing the best we can to go through the Animation Rigging questions in the forum while this technology is still in development, but we’re bound to miss some questions.
Oh, sorry if it did get over as that, but I wasn’t complaining, really just trying to figure out whether I’m supposed to be able to use it to layer on top of Humanoids already or not (answer could be “no, that will take a couple months” or “yes, if it doesn’t work report a bug”). This was just a follow-up to my question right above
Regenerating the avatar will not help you with a humanoid rig. While it’s a workaround that might solve some issues for generic characters, you want your original humanoid avatar in this instance.
I spent some more time looking at the ninja character in the SIGGRAPH workshop project. The main issue I’m finding in this rig is the name given to some game objects in the ControlRig sub-hierarchy. Humanoid rigs must have unique names on all of their game objects, so in the case, there were the game objects “Spine” and “Neck” that were conflicting in the humanoid avatar (I was looking at the NinjaRig_Ramen character). If I rename these game objects to something else, the runtime errors disappear and animation rigging evaluates properly.
Not sure we’re talking about the same thing; as I posted I am in fact trying to use the Humanoid avatar (that’s what my animations are for) but hitting the same issue as a previous poster of
“could not resolve ‘Rig/Arm’ because it is not a child Transform in the Animator hierarchy”
I haven’t got this to work at all on a Humanoid even when very carefully following the sample structure.
It’s difficult for me to say without looking at your project. I can’t reproduce this issue when using the same Unity version (2019.3b3) and package version (0.2.3) you are. What constraints are you using on your character?
Can you submit a bug report with the Unity bug reporter?
Can we expect some performance improvements in the future? Right now the spikes produced in the OnEnable method of the RigBuilder script are unbearable (over 18 ms for the advanced ninja sample). Will there be at least some caching involved to help with this issue?
I’ve had a look at the project you provided in your bug report and I think I found the issue in your humanoid rig setup. It looks like there are mismatching transforms in your two bone IK bone setup on your humanoid hierarchies. The ‘Root’ bone in the TwoBoneIK component is set to ‘mixamorig:LeftArm’ in the ‘xbot@Treading Water_Generic_TargetChild’ game object hierarchy.
Updating the humanoid hierarchies with the proper bone transform seems to fix the issue:
I’ll close the bug report unless you think of something else.
Good find. But what about the actual thing I was trying here - the top right two guys - applying a Twist correction after a Two Bone IK? (this was my starting point, everything else is just trying to break it down). As you can see they are not doing that arm motion. The goal is to have a typical setup with 2 bone IK (arm / forearm / hand) where the rotation of the hand is properly applied onto forearm and arm with specific percentages to prevent strong distortions. Same as a human arm. There’s no need for inbetween bones as in the Ninja with good skinning.
The twist correction constraint provided with the rigging package was specifically built to address skinning issues considering a set of procedural twist bones for a given mesh. For performance reasons, the constraint also caches the default bind rotation of the twist bones at constraint creation. Hence this is the reason why you see the arm snapping back to the original t-pose. We should definitely update docs on our side to reflect this.
In anycase, since all this code lives in the package, you can augment on the implementation to consider your specific use case (the file to inspect is com.unity.animation.rigging/Runtime/AnimationJobs/TwistCorrectionJob.cs).
