Monday 24 October 2011

Week 4

Week 4 has been a tough development and learning process for the rigging area of the pipeline. It has been the first time I have ever tried to rig and it should NEVER EVER be underestimated. From what I have gathered about the rigging process, it is that crucial period in which the outcome of the rig depends on your skills as a modeller and consequently influence the animation process and so on. On a note of workflow I have learnt a few valuable lessons about how the rigging process fits into the whole pipeline of game production and how choosing the right time to rig your model can be crucial to the entire process.


First I will talk about what I have learnt about the process of rigging and then I'll go on to the workflow process of rigging. 


Rigging is the process in which (game) assets that require animation are given what is effectively a virtual skeleton in order to allow the animator to easily and realistically manipulate the asset. Rigging is mostly used for characters as they require an efficient method of manipulation without letting the scene file get too messy. In this case I will be mainly talking about rigging a character although rigs can be created for any asset that needs manipulating for example a crane would require a rig if it were to be animated (although its not compulsory it would definitely speed up the workflow which is crucial). 


For a humanoid character we must first look into the bio-mechanics of the human body.... This effectively means how we move in fancy words. The adult human skeleton has 206 bones and although we don't need to understand what every single bone does (unless you are animating for medical science uses) we do need a general understanding of certain key bones and their limitations so we can mimic this in our rigs as realistically as possible.



An example of how bio-mechanics can influence the rigging process can be explained with this page from the book The complete Idiots guide to Anatomy & Physiology by Michael Lazaroff (2004). On this page it explains how the human skeleton is essentially 2 skeletons within 1. The first being the axial skeleton which is composed of the skull and the spine; the second part of the skeleton is the appendicular skeleton which is composed of the arms and pelvis through to the legs. The reason they are classed as 2 different skeletons is because they are believed to have evolved separately to one another. Biology aside, the reason we can look at this in terms of rigging is because I now posses better understanding of the skeleton and when I rig my character I now know to create the different joint hierarchies separately up until a certain point. This allows me to give my undivided attention to certain areas of the rig to achieve maximum realism and when I am satisfied I move on to the next bit.  This is also an example of a systematic workflow in which the chances of messing up the entire rig is reduced.  
























































The other valuable lesson to be learnt from bio-mechanics is the different types of joints that exist within the human body and where these joints would be. Above is the same book which explains the different types of joints both visually and text explanations. This is important to keep in mind, particularly when creating controllers for the rig as every joint within the human body will have its limitations. For example the shoulder joint which is a ball and socket joint will allow rotation all the way around in certain axis as well as movement towards and away from the body however it will have limitations in movement for example cannot do the same movement as say a knee joint. 




This explains the function of the shoulder joint movements and so by using this knowledge I can constrain my rig correctly to mimic the human skeleton as accurately as possible. A few other pointers I have picked up whilst working through the rigging process.



The Local rotation axis for FK should have the axis match the world axis as closely as possible.


The Local rotation axis for IK should have the x axis pointing towards the child joint.



The use of referencing when creating the rig allows you to do the final tweaks to the modelling while the rig is being created. 


Organising files is key to an efficient workflow.




Systematic workflow I found on a forum from a games designer:


Design:
1. We write down/ sketch the basic game concept on paper and pin it somewhere. (this is better done up-front as it will help you with level and asset creation). 
2. We then start filling out stuff we've missed and pin it again. (this is a continuous process)
3. Our concept/ level design artist starts sketching the first levels and the props that we'll need.

Assets:
4. I usually start with modeling the low-poly prop cages in 3ds max.
5. We test the unwrapped/ untextured props in a level mock-up.
6. We tweak the low-poly versions to fit our level design (scale, alignment, pivots, etc)
7. I unwrap all the assets.
8. I prepare those that need normal maps for mudbox/ zbrush. (drop an edit poly on the stack and optimize polygon density and hard edges)
9. I export the unwrapped models and paint the base textures using Mudbox and Photoshop.
10. We do another dry run with the basic textures.
11. Detail texture pass. (Or mudbox sculpting/ exporting/ normal map baking pass)
12. Beta Level (or level module) assembly.
13 Test again.
14 Final tweaks
15 Final level assembly.
16 Final test.
(despite their titles, the last 3 steps will usually be repeated a few times)

If you don't have a dedicated programmer working on the mechanics while you create the assets, you're better off coding your basic gameplay elements between step 6 and 7. This way, you're not going to waste so much time with assets that might not be needed due to your gameplay mechanics.

Also, when starting on a level we usually pick the most complex module (a room or a part of the map/ zone) and do that first, just to pin the atmosphere down and check if the props we've planned will suffice or fit together nicely. Once done, we move on to the rest of the level.

Once we complete a level, we play test it (extensively) and usually abuse the Combine scripts and the "Delete key" untill everything performs as it needs to.

17. Material tweaks (AO and so on)
18 Second unwrap pass (channel 2) and lightmap baking. We usually do this on groups (based on object proximity) and we try to avoid Flatten Mapping as much as possible.
19. Beer, rinse, repeat from #2.

P.S: we've tried other workflows and ways to do this, but this fits our now 3 manned team (down from 5) perfectly.






No comments:

Post a Comment