Rigging & nCloth implementation

 nCloth Implementation:

I had tested the use of nCloth during my experimentation session #1, but to recap: Creating cloth in Maya is done via the nCloth system. To make a mesh become an nCloth, one needs to simply go to the Rigging tab, and add the layer as an nCloth. Once this is done, when the playback of the timeline is active, the physics of the engine will take over and Maya will start to simulate the cloth falling in a pretty realistic manner. 

However, two things need to be done to make this work properly. Without any further additions, the cloth will simply fall through the armour forever. The first step is to set passive colliders, which are essentially things the cloth can collide with. For the chainmail at the back of the neck, I set the Chestplate, Back Scabbard and Shoulder plates to Passive colliders so that the cloth simulation would rest on these surfaces. 

The second step is to get the cloth to stick to a desired target. In the case of the chainmail at the back of the neck, I wanted it to 'attach' to the bottom of the helmet. To do this, I first needed to select all of the verticies which will be 'connecting' to the helmet base, so all of the verticies at the top of the chainmail shape. Once this is selected, I can create a Dynamic Constraint, which holds these verticies in place. You can see this is done in the above screenshot, with the dark blue dots near the bottom of the helmet. This is then parented to the helmet so the cloth follows it in place. You can see how the cloth looks when deformed in the above image. 

In order to get a better look to the cloth, I was able to play around with the presets and settings of the cloth. Fortunately, there is a preset for Chainmail, which is exactly what I wanted for my cloth objects. I prompty set this preset to the chainmail in my model, for the back of the neck and the chainmail below the tassets. 

Rigging:

Before starting the rigging, I wanted to reiterate my Outliner in Maya for my character. I think it is important to highlight that I have stayed very organised and have a mini structure going on for the naming conventions to help me navigate my very large amount of layers in the model. This will be extremely helpful when weight painting, as I will have a lot of areas of the model which dont deform and will require a flooded weight of 1, so being able to select all the individual parts of the model will make this task very easy and fast by comparison. 

I started by creating the base humanoid skeleton. I created this by using the new Joint tool, starting at the Pelvis and working outwards, using the orthographic views to plot the joints in so they were positioned more accurately. I have the X-Ray joints function enabled in the viewport to help view the skeleton better.

The skeleton contains all the typical joins except for the spine, which only has a singular joint connecting the pelvis to the upper body, which then joins to the left and right clavicle joint. The reason for this is that my characters body is a solid metal chestplate which will not deform, so the spine will not require more than a singular joint to move it properly. I have also included multiple joints in the feet to offer individual movements of all the links in the Sabaton, the protective metal footwear with multiple plates which move in unison. It is worth noting that, due to the default pose of my character, the IK handles should implement well since there is a natural bend in the joints, for both arms and legs. This should help the IK handles to figure out their pole vectors easier due to this bend in the joints of my character. 

Here is a screenshot showcasing my very organised structure of my character, using very good naming conventions to keep organised. After I created the left side of the joints, I then used the Mirror Joints option to mirror these across to the over side, seeing as the character is symmetrical across the arms and legs. In order to do this efficiently, I used naming conventions for the left side by appending the name of the joint with '_L', standing for left. Afterwards, in the extra options of the Mirror Joints tool, you can select a custom string for the function to locate and replace with a new custom string. In this case I simply asked the tool to replace 'L' to 'R'. However, this didn't exactly work as intended, as - in the above image - you can clearly some names are incorrect, such as 'RowerArm_R', which was mirrored from 'LowerArm_L'. The function had replaced any 'L' in the joint name with 'R', which was not what I had intended. I simply had to delete these and ask the function to replace '_L' instead, which would not result in this minor error. 

After some more added joints, here is my completed skeleton. I have added some complexity to the rig, which should allow for all individual components of the character to move independantly where appropriate. 

Here is an example of how I have achieved the knees and elbows of my rig. To clarify, the geometry of the knee consists of four parts, the knee cap, one upper plate and two lower plates. This is the same for the elbows. All of these pieces should move individually for more control and precise movement. By comparison, using just a simple leg joint structure would require complex weight painting, finding a value which correctly bends with the joint without clipping across the rest of the other components. This is a much easier solution in my opinion, since I will be able to weight paint each component to each corresponding joint in a 1:1 ratio of weight to component. The knee also requires its own joint, since it allows it to bend more naturally and evenly across the upper and lower leg without deforming. 

Here is probably the most complex part of the rig, done for the tassets. To recap, the tassets part of the model includes four circular plates, connected to the bottom of the chestplate. On top of this, four extra plates (two large at the front, two small at the back) hang from the final circular plate of the tasset. This was a bit complex to figure out, since the tassets are not strictly part of the chestplate per say, they hang from the bottom and can bend to offer more flexibility in the pelvis region. 

Ultimately, I created a child joint from the spine joint, which connects to the left and right clavicle. This connects to the joints highlighted in green in the above image, which consists of a joint for all four pieces of the circular tasset pieces, followed by four separate joints for all four tasset plates. Although a bit complex and messy to look at, this seemed to be the best way to approach this part of the character rig in order to achieve a more natural and realistic look when the tassets of the armour bend and move, since the plates intend to slide across one-another. 

I did consider attaching the bottom circular tasset plate to the pelvis joint, using the upper joints as part of the spine joints and the large tasset places connecting as child joints to the pelvis joint. However, I ultimately dismissed this since I felt this may look odd when moving the character, since the armour should move independantly from the legs and pelvis of the character. 

After finishing the skeleton, I started to work on the weight painting. Usually I would work on adding controls first, but this time I thought I would start with weight painting, since I figure it will be pretty easy to do. The above image shows my current progress, setting the entire geometry of the chestplate and tasset chainmail to 1 since the pelvis should control all of that movement with no deformation. I used the colour ramp in the weight painting tool to help identify and prevent any coloured areas appearing, since all of the plates should not deform for the purpose of realistic movement. I went ahead and did this for any plates which would not deform, which was a realtively easy task thanks to keeping all of the layers separate. All I had to do was select the joint to weight paint, select the geometry to attack to this joint, then flick the Flood button in the Weight Painting options box, which was set to a max weight of 1. 

However, some areas such as the leg would deform, so this would require some more thorough weight painting. I started with these areas first. Unfortunately a mistake of mine has caused a negative reprocussion in the weight painting. You will note that the legs are extremely high poly in the above image, this was because - since the displacement mapping earlier had not worked - I had substituted some geometry for the much higher poly variants to try preserve some of that work that would otherwise have been wasted. In the case of the legs, it was the creasing of the clothing. 

Unfortunately, I had overlooked the difficulties this may cause when rigging. Typically, you may use a much lower version of the model to rig and then substitute this for the higher poly version, transferring the skin weights and making the process earlier. This is something I was not very aware of before working on the knee, to which I came aware of this better workflow, though too late to act on it. Luckily the legs were not too difficult to topologise, since they did not need too much work on the weight painting as the deforming was relatively simple and also mostly obscurred by other parts of the model. You can see the weight paint fades out towards the knee, which I was able to do by using the smoothing brush in the weight painting tool set to help smooth out the deformation and catch any issues. 

Here is an example of the knee being deformed, just by moving the skeleton temporarily to demonstrate. You can see that the knee deforms by clipping into itself. This is decent, as the alternative is that the knee will bend and the geometry will collapse into itself, looking very bad by comparison. This is something I had looked into in another assignment, so I was prepared for this task. 

The deformation of the front side of the upper leg was also fairly good, deforming quite smoothly. It could have been improved some, but I found this difficult to achieve and the weight painting would not operate how I would have liked or expected it to operate. I decided this was suitable, especially since the majority - if not all - of this bend would be hidden from view due to the armour covering this part of the model. 

The only main flaw in the leg weight painting I could solve was this area of the back of the, leg, where the topology is very bumpy and a bit deformed when the rig is moved. Despite smoothing and refining the area many times, I could not figure out what was causing this bending. I had initially thought that another part of the joint heirarchy was affecting this area, causing it to stay put whereas the rest weighted to the leg would move, causing this bumpy topology to arise. Though this wasn't the cause, and I could not find where this was ocurring. Ultimately I dismissed this to potentially being part of the original detail of the model, the creasing in the cloth, that just looked unusual since this sort of look can ocurr with dodgy weight painting. 

Unfortunately, I had missed a major component of the rigging process. After creating the skeleton, I moved straight on to the weight painting. However, I had completely forgotten to complete an important task of orienting the joints. This task is important to help the joints orient and move correctly, though any other benefits are not known to me, just that it is an important stage of rigging. Unfortunately, I had to revert the work I had done on the weight painting since this was a task that - to my knowledge - could only be completed before the character had been skinned. 

I was able to achieve this easily through the use of a script called CometJointOrient, a script which can be downloaded here for free. You are able to select all of the joints in the skeleton and use the script to automatically orient all of the joints with pretty good precision. The idea is to have the X axis pointing in the direction of the joint structure, and the Y axis of the joint facing up. This is mostly successful, but in my experience the script fails to modify the joint of the pelvis correctly, which was the case here. This simply required me to orient the joint manually using the built in tool of Maya, which was easy to solve. Above is the resulting skeleton with its orientation of the joints visible. 

From here, I quickly re-did the work for the weight painting. Fortunately I had only done a couple areas which were easy to repaint. 

When weight painting the foot, I had to allocate some of the weight painting to the lower leg so the ankle would deform when the foot joint bends. Otherwise the ankle would protrude outside the lower leg which was not ideal. Above is the weight painting setup used for the lower leg. 

When weight painting, I tried to deform the skeleton a lot to help spot weight painting errors. Here is the elbow of one of the character's arms. Upon bending the joints the geometry begins to collapse in on itself, unlike how it should be bending (refer to the weight painting done on the legs earlier). Admittedly this would have been easier to do if I had done the controllers of the rig before the weight painting. 

I had the most difficulty with weight painting the fingers. There was a lot of overlap to fix with fingers having weight for the other finger joints, and required a lot of fine tuning to get it right. This was something which could have been mitigated had I used a default pose in the hand in which the fingers were spread apart, something I did not do. I will keep this in mind for future projects. I fixed the majority of the fingers, then moved on to other areas as this took quite substantial time to solve completely, and I still hadn't started weight painting the finger plating. 

Upon testing other areas of the character, I noticed a glaring flaw in the heels of the feet. The image above shows that - when the joint is bent backwards - the heel sticks out very badly. This was clearly a weight painting issue stemmed by the fact that the foot has the upper half weighted to the lower leg so the ankle stays inside the lower leg piece. 

In addition, one of the verticies was unpainted. You can see this in the above image. This seems to have happened due to the smoothing operation I had been using, as upon some research people had been suggesting that the use of the smooth tool can cause issues like this. I had to revise the weight painting of the foot. 

I fixed the issue of the vertex not being weight painted, which was simple to fix. The protruding of the heel was a bit tricky to fix, and required some significant refinement of the weight painting. This was the best I could get the foot to be, with a very slight protruding ocurring on the heel when contracted. This would get worse as the foot bends further, but the foot wouldn't be able to bend much further than this since the armour would restrict the movement. Overall the result was decent and fixed the majority of the glaring flaws, so I felt that this was suitable for use in my project. 

Next, I went back to fixing the hands. After some refining of the hands, I moved on to the finger plates, which are the smaller metal plates which rest on top of the fingers. Unfortunately, despite being designed as a solid object, using a weight paint of 1 for these plates would not work, as they would clip across one-another and would move away from the glove model they were supposed to be attached to. As a result, I had to allow these plates to deform and bend, which can be see in the above screenshot. This wasn't ideal sine it does detract from the realism a bit, since these plates should in theory be solid and unable to bend. However, this was the best I could achieve considering the way they had been modelled. I thought I had given good consideration as to how they may move when the fingers bend, but clearly I had not given this enough thought. If I had looked at real reference of how these plates on the fingers are contrusted and moved, perhaps this would have allowed me to create something more suitable. Sadly, this part of the design is too locked in, so this was the best solution at this stage of production. Despite all this, it looks pretty good when deformed, and since these plates are pretty small I'm hoping this minor discrepency will be easily missed. 

For the hand, I was looking to allow it to clench into a fist, and extend outwards. However, after testing the hand extending outwards I spotted some noticable clipping where the glove was coming through the plates. This can be seen better when rendered, which I have provided a screenshot of above. In the viewport you can see the plates don't really bend when the hand extends outwards, so this was something I could address by refining the weight painting more. 

Unfortunately due to the nature of the model, it was really difficult to get a solution which supported both expanding and contracting the hand. Considering that the character will more often contract his hand than expand it, I prioristised the weight painting to better suit the contracting of the hand. However, I was able to refine the deformation of the hand expanding quite a bit since the last screenshot posted. Above is the refined result. Hopefully this will be good enough for my project, but after many hours this was the best I could get, and I simply couldn't justify any more time spent here.

Whilst weight painting, I wanted to test how the cloth would work in relation to the rigged character. I decided to keyframe the moving of the joints in the timeline to test. Sure enough, the nCloth would deform when the appropriate Passive Colliders would come into contact with the nCloth. However, in the above screenshot the nCloth on the left is intersecting with the upper leg plating below. This is because the upper leg plates are not set as a Passive Collider, as I had difficulty setting this as a Passive Collider without causing all of the child layers to also be set as one (The latch, bolts, straps, etc.). Fortunately, there was a solution to solve this. Within the nCloth attributes there is a Thickness value, which can be increased to determine the invisible thickness of the nCloth, more specifically the collision box of the layer. This can also be done for the Passive Colliders, namely the legs. Since the legs had a slight increase of thickness with the upper leg plating added, I thought adding thickness to this specific part would be most appropriate. After increasing this value, the issue was fixed. 

I had mentioned earlier that the nCloth needed to be parented to the character in order for it to follow correctly. This didn't seem to work for parenting it to the mesh, so I tried this to the relevant joint instead. This did work, so I parented the cloth to the appropriate joints. I attached the chainmail at the back of the neck to the Helmet joint (the head), and the tasset chainmail to the Pelvis joint (or the chestplate). 

At this point, I felt the weight painting was suitable and it was time to move on to adding IK handles to my rig. This was easy enough to do, starting the IK handle at the hip and ending it at the ankle. From the bend, you can see that the natural bend of the knee in my model and the bend in the skeleton has helped the IK handle to bend in the correct direction. 

In order to control this IK handle, I setup a controller (a NURBs Circle) to control it. I created a NURBs Circle and centered it at the joint at the ankle with the Snap to Component mode selected. I used two different contraints for this controller; The first contraint was a Point constraint, which moved the IK handle where the controller was moved. The second constraint was an Orient constraint, which allowed me to rotate the joint by rotating the controller. 

Before adding these constraints though, an important step was to Freeze Transformations on the controller. You can also see I have used good naming conventions again for the name of this controller. Without freezing transformations, the Translation and Rotation of the controller will not appear as above, instead with lots of different values due to the movement of the NURBs circle when it was created to the new position. The problem with this is that it makes it difficult to reset the pose of the character once you have moved it around. On the other hand, if you do use the Freeze Transformations function, all of the attributes of the controller will be set to 0, its new default. Now if the controller is moved, it will still add this translation/rotation in the channel editor, but you are able to drag + select these values and set them to 0 to reset it to its default state. This can be really handy when animating if something goes wrong or you want to test/reset a pose. It can also help with weight painting so you can test different poses and how the weight painting acts, with the ability to reset the position after you're done. This was a step I felt was very important to include, and you can see I have done so in the image above. 

Finally, for the leg IK handles I wanted to include a manipulatable Pole Vector for the IK handle. By default, the IK handle (when created) will determine its Pole Vector. This is then used to determine which way the IK handle will bend. Right now the automatic Pole Vector for my IK handles are good, but I wanted additional control over them, allowing the legs to orient left/right for additional control. In order to do this, I first needed to create a Locator joint (the object which looks like an axis) to control the Pole Vector. Next, I selected the IK handle and then the Locator joint and created it as the Pole Vector for the IK the constraints menu. Now, by manipulating the Locator joint I could adjust the way the knees were pointing. I would do the same processes as mentioned above for the elbows for which I also will be using IK handles for. 

Moving on, I went ahead and added some controllers for the Tassets, specifically the larger plates which hang from the tassets. For these, I used simple FK controls to control their movement. I started again with a NURBs circle like before, though I manipulated its shape to be something more desirable. I then followed all of the same steps as before, attaching the pivot to the center of the joint and freezing transformations. After this, I used an Orient Constraint on the joint to allow the controller to rotate the joint (and by extension the Tasset plating). This gave me plenty of movement for this part of the armour. I repeated this step for all four plating hanging from the Tassets. 

I continued the same controls for the arm, first adding an IK handle from the Clavicle joint to the Hand joint. Next, I created another NURBs shape to serve as a controller for the rig, freezing its transformations. I then added the same constraints to the controller, a Point constraint for the IK handle and an Orient constraint to the hand joint. Finally, I created a Locator joint to serve as the Pole Vector controller of the IK handle, which I have also frozen transformations for. 

Next, I wanted to create controls for the Spine. For this, I started by creating an IK Spine, placing it from the pelvis to the top of the spine joint. This creates the following layers in my outliner. 

In order to use this IK (as it works differently to a typical IK handle), I need to go to the connection editor and create a link between two attributes: Rotate Y and Roll. The 'Rotate Y' is connected to the controller, which is a new NURBs circle I had created as per before. The 'Roll' attribute is connected to the IK Spine handle. They are different names, but operate the same axis. Once this connection is made in the Connection Editor, rotating the Y coordinates of the controller will rotate the 'Roll' attribute, bending the character forward by doing so. I did the same for the character rotating on the Z axis, which I connected to the Twist attribute. I did this in the same process. 

Typically, on a more humanoid character with a more flexible body, you may use two separate controllers for this, one for the Roll and one for the Twist attributes respectively. This can help the character to Roll or Twist more naturally. However, this made no difference to my character which used only one spine joint in its skeleton, and natural movement would be of no benefit since the whole chest is to move uniformly being a large metal plating. 

Here is a demonstration of moving the controller around for the IK spine. It gives plenty of movement for the character to move left, right, up and down. 

Next, I started working on the head. I created three main controllers for now: Neck, Helmet and Visor. This would allow all three joints to be moved indepentandly, but these controllers would be parented in the order of the joints in the skeleton. So the neck would be the parent controller, followed by the helmet, followed by the visor. This means that the Neck controller would move all the other controllers with it, making the rig cleaner and easy to follow when moved. It is worth noting that although the visor of my character's helmet would not raise to see a person inside, I wanted to have the ability of opening the helmet just incase it proved useful, such as perhaps secondary animation. These were all set up like before, using Orient constraints to allow the controllers to move the joints via controller instead of joint. 

I continued adding more controllers, next working on a controller for the left and right Clavicle. This would help to move the shoulder independantly of the arms which are setup with IK handles. It would also move the shoulder plate independantly of the arm which was important to include. 

For the links in the Sabaton of my character, I needed to use a more practical approach. I wanted all of the joints in the chain to move at the same time, by simply rotating one controller. In order to achieve this, I needed to start by adding a controller as I would to control this movement, creating it with an Orient constraint on the first joint in the chain. 

Afterwards, I opened up the Node editor, viewing all of the joints in the chain in the editor. From here, I connected the rotation values from the first joint in the chain and connected it to the next one, and the next one and so on until all the joints in the chain were connected. 

Now, when the controller is rotated, all the joints will rotate in unison. Above is an example of this, precisely how I wanted. Though this does show a slight flaw in my modelling in which the Sabaton plate links have large cornered edges where they move away from the default position, something I had overlooked. Arguably, I could have investigated the technical side of how a Sabaton is created and used in real life to get better influence in my modelling process and create something that does not have these large corners protruding out when bent. However, the issue is only minor, and this probably wouldn't be seen since the camera should highlight the view from above, not below. 

I used the same method for the Back Scabbard, in which I had used a chain of joints for a more smooth deformation once bent. However, in order to achieve the same result, I needed to adjust some of the values when rotating the next joint in the chain, as otherwise it would bend too much. In order to do this, I used a unitConversion node, which would sit inbetween the parent and child of the rotation values. Above highlights the multiplier I used, which is 0.5 (which halves the rotation values of the parent). This reduced the rotation of the child joints which had been over the top before this change. 

I used the same technique for the tassets, since I wanted the plates to move individually just like the links in the Sabaton for the feet. Again, I added a NURBs circle and used an orient constraint to the first joint in the chain. Following this, I attached all of the joints in the chain in the node editor via the rotation values, only separated by a unitConversion node to tweak how the rotation operated. I used 0.5 as the multiplier again since this gave me a nice result. 

Something I had tried in the Node editor was connecting the translation and rotation of the controls of the parent control to the child controllers, so that they would correctly follow the movement of the parent. The issue was that the child controllers would follow the rotation of the parent, but not the rotation of the joint chain. Essentially, the tassets would rotate four times, one per segment, but the controllers would only rotate with the first controller. The idea of this node graph shown above was to help them follow the movement by increasing the amount they moved by the amount of segments in the tassets. 

This did work, though it led to an unavoidable error. Unfortunately, this connection prevented me from manipulating the FK controls of the child controllers, the large tasset plates. For some reason it caused them to lock and prevented any movement. This was unfortunate,and I lacked an explaination or the knowledge to perhaps ammend this. However, I had to put this idea aside since it simply did not work in the end due to this one major issue. 

For the knees and elbows, I used a combination of the methods previously used. To start, I created three NURBs shapes for both knees. The middle one would be the main parent control, followed by the two child controllers. The main controller would control the orientation of the whole knee section, and the two child controllers would rotate the upper and lower plates just around the knee cap plating. 

After freezing all of their transformations, I applied an Orient constraint like before to their respective joints. Once this was done, almost all of this rig setup for the knee was complete. However, for the bottom of the knee cap there were two plates which overlapped, and needed to move separately. To accomplish this, I added the controller to the parent joint of these two plates, and then attached the second one to the parenting joint via the Node Editor as I had done previously with the rest of the rigging. 

When rigging the hand, I ran into an issue. Unfortunately the orientation of the first joint in the hand was different to that of the proceeding two. I must have missed this during the orientation of the joints done earlier in this documentation. Unfortunately this meant that using the same system as before with the Node Editor would not work, as the rotation of the first joint in the finger would rotate the incorrect axis on the proceeding two. Since I was too far into the rigging stage, I was unable to fix this in a conventional manner. I had to try something else. 

Instead, I turned to the use of Blendshapes. Specifically, adding new attributes to the hand controller to allow for preset movement in the fingers. Based on my animatic, I felt it would only be needed to use two attributes to control the fingers, one would close the hand into a fist, and the other would expand the hand into an opened position. This would allow for things like grabbing/holding the Greatsword, or pushing himself up from the ground. I did not believe I needed control of the individual fingers and this would make animating a bit more tedious, so I decided to use two attributes to control the movement of the hand. 

To start, I needed to create two new attributes on the Hand control, which I named 'Fist CTRL' and 'Open Hand CTRL'. You can see these in the image above, highlighted in yellow. In order for the fingers to move via these attributes, I had to Set a Driven Key. This involved setting my Hand control as the Driver, the source. This followed by the Driven, that being what is controlled, which were all of the finger joint rotations. 

Once this was setup, all I needed to do was to set a key for the default pose, and a new key for the finishing pose, that being the fist or opened hand. You can see me working on the fist attribute in the above image. This would then be correctly set up, and - upon using the slider in the attributes section - would allow me to blend between the keyed poses. I completed this for both hands in the same manner. 

Here is the setup for creating the opened hand attributes. 

As mentioned before, I had completed the knees and elbows using the same technique. However, I did have a small issue regarding the controls for these sections of the rig. Specifically, the orientation was not suitable, and did not match the direction the joints were going. I don't believe this was a fault of mine with the orientation of the joints, as these seemed to work fine. The issue arose when Freezing Transformations on the controllers, which would reset the orientation too and cause it to match that of the world axis. This would be difficult to animate as rotating it would not match the direction of the arm. 

Luckily I was able to find a solve, albeit an unusual one. The first step of this solution was to create a Null layer, otherwise known as an empty group. I would then click on the joint and match the transformations of the joint to the Null. Selecting this Null would give the orientation I wanted for my controls. The final step was to parent the Control to the Null layer. The result would give a Controller which still had its tranformations frozen all to 0, but the orientation would inherit that of the Null it was parented to. This was perfect since it did not require any additional steps or redoing any work, so I started to implement this across my rig where appropriate. Specifically, for the knees and elbows. 

Here is an example of the outliner for my elbow controllers. As you can see, all controllers are parented to a Null to allow the orientation to be more appropriate and useful. 

Another tweak I made to the otherwise finalised rig was parenting the Pole Vector controllers to the Leg Ik controllers. The reason for this is that - upon moving the character around - these Pole Vectors would be stationary, and sometimes would move behind the character or to the side. The result of which causes the legs to deform horribly, since the pole vector of the IK handle will follow the controller due to this setup. This was easily parented to the IK controller though. 

However, in the above image you will notice that the controllers for the knee do not follow either, and get left behind. Originally I could not parent these to the joints of the rig or any other area as it would break the parent or simply not work. 

Despite this, I had some luck. Due to the Null layers I had used earlier, it made it possible to parent the Null to the joints so that the Null would inherit the translation of the rig, which would thereby be inherited by the controllers. This resulted in the desired outcome. 

To finish off my rig, I created a simple controller for the Greatsword. I didn't think anything else would be needed beyond this controller. I wanted to use a controller over simply keyframing the group layer since using the group might be a bit tedious to do, as I would have to keep selecting it in the outliner. Selecting it in the viewport would select one of the individual parts of the Greatsword model, which was bound to be a mistake I made during the animation. Since the mesh becomes locked when skinned, I felt that using a single joint and control for the Greatsword was a more suitable alternative. 

Here is the finalised rig. One additonal part I had not mentioned yet was the Main controller, which is the largest NURBs shape in the image above. This is the main controller, containing all the other controllers inside of it, serving as the main parent. This allows me an easy way to easily move around my character without anything overly complex. 

The final step I did before marking this task as complete was creating a layer system, specifically a layer containing all of the mesh of my character. I did not want to click on the mesh of my character when animating, I exclusively wanted to click on the controllers of the rig only. However, even though the movement of the mesh was locked, I could still click on the mesh or other parts I didn't want to be able to click on. To prevent this, I used a layer set to Reference mode which contained all of the parts I did not want to click on. This meant that the controllers were not in this layer, and they could be clicked on freely whilst the rest of the elements in the project could not be. This should be helpful when animating. 

After this, I considered the rigging stage to be complete.