Development Log 2 - Tom Forwood


Retargeting Animations 

The first thing that needed to be done when brining the new animations into unity was to set the rig for each file to humanoid. Unity has a built in solution for animation retargeting that allows animations to be shared across similar rigs as long as they fall within the constraints of the humanoid rig setting within Unity. This can be done by switching the rig type from Generic to Humanoid in the import settings of unity. The next issue that had to be fixed on some of the imported files were misaligned bones or missing transforms. Normally Unity can scan through the rig hierarchy and automatically determine where it should place the bone transforms to form the Humanoid rig type, however, this is not always the case. Sometimes it is necessary to manually select the correct bones for each slot in the rig hierarchy. Once all the bones have been placed in their correct slots animations can then be shared across Humanoid rigs. 

Humanoid Avatar representation animation within Unity (He looks funny!)

Mecanim Animator

This week I focused on updating the animations in the current Mecanim controller and switching them over to some of the newer ones that I completed last week. Once the player character model had been swapped out for the updated model, the animations in the actual Animation Controller had to be changed too. Since we are using the humanoid animation system, we can actually reuse some of the animations that we had previously to fill in the gaps. An example of this is the running animation. After swapping the rig type to humanoid we were then able to retarget the animation to the new model. The Mecanim Animator Controller was already partially set up from the previous iteration of the game, so it only needed a few modifications to make it work. The first was to re-implement the original animation layers/mask setup that we were going to use originally. Animation layers allow certain parts of a rig to operate independently from one another. An example of this is if a player wants to do a running attack, the top half of the running animation can be overridden by the attacking animation so that the legs continue to move, but the top body performs the attack animation, thus allowing for much better looking animations that are much easier to create. There was a bit of a struggle to implement the animations properly due to the nature of how the animator interacts with scripts. As such we had many problems getting it to behave correctly by setting up the correct transition timings and parameters.

The Mecanim Animator


Sidenote: The reason we didn’t end up using the masking system in the previous iteration was because UNET actually didn’t support animation layering. We can implement it now because we have switched over our network architecture to Photon, a much more stable and widely supported service that allows for layer syncing.

Attack animations (Will require more cleanup)

Personal Reflection

This week was a bit troublesome in terms of feature implementation. Since I wasn’t able to do much until our networking was switched over to Photon, I had to essentially help out in a support capacity wherever I could within the group. It wasn’t until quite late in the week that I actually got to switch over the animations in the controller since there was no way to tell of layer syncing would work until we actually tried it. On top of this, we had to be ready for a playtest on Tuesday, so that probably didn’t help with the organisational pressure.

List of completed tasks for this week:

  • Updated Mecanim controller with new animations

-Tom Forwood

Leave a comment

Log in with itch.io to leave a comment.