Unity Triple A – Characters looking at stuff via IK

I have been talking about doing this for ages, and as my interest for Triple A techniques increases and the blog was looking a little sparse, I thought I would do a few tutorials on more Triple-A techniques. In this article, I am going to talk about using Inverse Kinematics in Unity and in particular characters looking at each other.

If you have ever played games like Uncharted 4 or Final Fantasy XV, when characters talk to each other whilst the player is controlling them, you will see them physically look at each other. This to me is really cool and adds a level of immersion that you wouldn’t get if the characters “just” talked to each other. If you look at the gif above you can see a transform being moved around the environment and the characters head looking at it, whilst the rest of his body is still. That is the sort of thing we will be looking at in this article.

So firstly what is IK?

Well in simple game dev terms, it is an animation technique.

Most animation is produced using a technique called forward kinematics. This is where an animation is created by rotating the angles of joints in a skeleton to predetermined values. The position of a child joint changes according to the rotation of the parent and thus the end point of a chain of joints can be determined from the angles and relative positions of the individual joints it contains.

Inverse Kinematics is working backwards to forward kinematics (hence the name!). By taking a chosen point in game space, you work backwards and find a valid way of orientating the joints so the endpoint lands at that position.

In simple terms, it allows us to make characters do stuff like point at things, look at things, touch an object at a specific point, etc in a more dynamic way. Unity actually has this built into Mecanim, which is pretty sick.

In order to get IK working you need a “correctly configured avatar”. In order to get one easily, I grabbed the Ethan from the Standard Assets.

Then we go an make an animator controller with his idle animation and set it up for IK by clicking on the little settings icon and enabling IK pass.

Then make sure your animator controller is actually assigned to your character’s animator.

Setting up the character to look at stuff is super easy. Create a new script called IK Controller and add the following:

Add a sphere into the scene and set it up as your _lookObj. Set up the other references. Run the game and move the sphere around a bit and viola.

We have a system similar to what is shown above.

Now in conversations, you can do a distance check if the characters are close enough you can enable the IK look at.

There you go. Easy!

If you want a sample project all the code lives here:

https://github.com/coxlin/IKTest

Get Shifty (Bitwise Operations)

Image result for get schwifty

As I fired up my pc today I actually looked at those post-it notes that have been sat on my desktop. And one of those little tasks was “Stuff I need to brush up on – C# Bit Shifting”. Have you ever used a bitwise operation? I have maybe once. Have you needed to do a bitshift in real life? On the other hand, have you ever been to a coding job and have to do one of those coding tests and it had bit shifting is on it? Yeah ok. Essentially, it is one of those things that in 2017 (or nearly 2018) you are unlikely to have used bit shifting, etc day to day, but it is one of those things that it is kind of useful to know. I was super rusty on it because I mainly do gameplay programming, graphics and SDK integration inside of Unity day to day. The closest I come is using Flags.

Anyway, to the plot!

So what are Bitwise operations?

Well they are operators like +, -, * &&, etc, etc that operate on ints and uints at a binary level. This means that they operate upon the actual digits of a binary integer.

To put it another way. See these binary numbers I stole from google images:

Image result for binary numbers

The bitwise operators operate on the binary numbers. Get it? Well, here is the binary table, to remind you of how binary number are represented:

128 64 32 16 8 4 2 1
1 1 0 1 0

Basically, the operators change where the ones and zeroes go in a binary number.

So let’s look at some of these operators! We are looking at operators in C#, because C# is a beautiful language.

Bitwise AND (&)

The & operator compares each binary digit of two integers and returns a new integer with a 1 wherever both numbers had a 1 and 0 anywhere else. Let’s look at 2 numbers:

128 64 32 16 8 4 2 1
 0  0  1 0 0 1 0 0

The above number is 36.

128 64 32 16 8 4 2 1
 0  0  0 1 0 1 1 0

And the above number here is 22.

If we use the & operator on both, we take wherever both numbers had a 1. This produces 4.

128 64 32 16 8 4 2 1
 0  0  0 0 0 1 0 0

Basically, the operators change where the ones and zeroes go in a binary number.

Sure OK. But why is it actually useful? Well we can look in the context of flags.

A flag is a special enum that can hold multiple values at a time.

[Flags]
public enum AttackType
{
    NoEffect = 0
    Melee = 1,
    Fire = 2,
    Ice = 4,
    Wind = 5,
...
}

Imagine we have a JRPG. In a JRPG abilities have elements and abilities. Abilities could have multiple elements. We could use a flag for that. Say we want to check if an ability has Fire and Wind in it. We can use the bitwise & operator.

int mask = AttackType.Fire | AttackType.Wind;
bool isFireAndWind = (attackType & mask) == mask

The above bool will return true.

Bitwise OR (|)

The | operator compares each binary digit across to integers and gives back 1 if either of them are 1. Unlike AND where both have to be 1, 1 could be in well one or the other.

128 64 32 16 8 4 2 1
 0  0  1 0 0 1 0 0

The above number is 36.

128 64 32 16 8 4 2 1
 0  0  0 1 0 1 1 0

And the above number here is 22.

You know, like last time. If we apply OR.

128 64 32 16 8 4 2 1
 0  0  1 1 0 1 1 0

The above number is 54.

Makes sense?

Cool. Let’s have a look at our JRPG example again:

_ability.AttackType = AttackType.Fire | AttackType.Wind;

The above code is setting the ability’s attack type to Fire and Wind. The game can then check this later when doing the battle calcs.

Bitwise NOT (~)

The bitwise ~ operator is different than the previous ones we have looked at. Where as the & has been similar to && and the | has been similar to ||, the ~ operator is similar to the ! operator. You know how the ! operator can flip a boolean from true to false. The ~ operator reverses a binary value.

128 64 32 16 8 4 2 1
 0  0  1 0 0 1 0 0

The above number is 36.

The same as last time. If we apply the operator to it we get:

128 64 32 16 8 4 2 1
 1  1  0 1 1 0 1 0

OK cool. I mean to me this is not the useful part of the NOT operator for gameplay programming anyway.

If we look at our JRPG example with our flags. You can use the NOT operator to unset a flag.

_ability.AttackType = AttackType.Fire | AttackType.Wind;
_ability.AttackType &= ~AttackType.Wind;

The above will remove the Wind element from the ability.

Bitwise XOR (^)

The ^ operator, like the previous operators, compares the binary digits of these numbers. If only one of the two comparing integers in the binary is a 1, it inserts a 1 into the result. Otherwise a 0 is inserted.

128 64 32 16 8 4 2 1
 0  0  1 0 0 1 0 0

The above number is 36.

128 64 32 16 8 4 2 1
 0  0  0 1 0 1 1 0

And the above number here is 22.

You know like all the previous times.

128 64 32 16 8 4 2 1
 0  0  1 1 0 0 1 0

And the result is 50.

Cool. So in regards to our example, the EXCLUSIVE OR is true only if the other is true, but not both. We can use it to toggle a value inside a flag.

_ability.AttackType = AttackType.Fire | AttackType.Wind;
_ability.AttackType ^= AttackType.Wind;

The above code “toggles” Wind.

Bitwise Shifting (<< / >>)

Bitwise shift operators work a little differently than before. Instead of comparing 2 integers, these operators shift an integer.

128 64 32 16 8 4 2 1
 0  0  1 0 0 0 1 1

The above number is 37. If we 37 << 3 we slide all the digits left by 3

128 64 32 16 8 4 2 1
 0  0  0 0 1 1 0 0

And the above number here is 12. You can also right shift the integer >> by any number that does a similar thing.

This is a harder one to find a decent example, or at least I cannot think of a time I have actively had to use it. If you look at the maths of bitshifting though, you can use it to do calculations. Shifting the bits of an integer number left by one place is the equivalent to multiplying the number by 2, whereas shifting it right is equivalent to dividing it by 2. I guess an example could be hardware that was used back in the day. This hardware did not have floating point support and thus in order to do any arithmetic, you had to do bitshifting. Wierd huh?

Again, I have never needed this in my day to day, but it is one of those things I have seen in programming tests. I have theorised why this stuff is probably still on tests in the past and the whole “programming test” is a post for another day.

Regardless, I hope this post will be helpful in some way when understanding bitwise operations, flags and bitshifting.

A summary of the Rendering Pipeline for Humans

Image result for Xenoblade chronicles 2

I just started playing Xenoblade Chronicles 2 on the Switch. It is pretty neat. Anyway In this post I wanted to talk about the rendering pipeline, or rather put it in simple terms that less tech savy people can understand.

In a game, rendering can be seen as the process of drawing a scene on a computer screen. It involves a mathematical combo of geometry, textures, surface treatments, the viewers perspective and lighting. In other words, it is a combo of the geometry that forms the meshes made in Maya, Blender, whatever, the textures that are applied to those meshes, shaders that do some neat stuff to make it look cool, where the camera is looking and how the scene has been lit. The Rendering pipeline then represents the flow of processes that take place to show a virtual environment on your screen. Basically, how your games console draws that sweet Vidja Game on the screen (bit of an oversimplification, but you get the idea).

In simple terms, there are three stages of the pipeline:

The application phase runs on the CPU (generally) and deals with all your gamey stuff. This includes moving object, input, collisions, etc. This then affects the geometry part of the pipeline that basically determines where stuff is. It involves calculations regarding the position of the camera, the transformation, scale, rotation of each object and all the mesh data we have. The rasterisation phase then actually displays the image on the screen. It goes through some more in-depth processes to get that desired image on to your sweet 43inch Ultra HD TV.

Now it is a bit of a cop-out to say “more in-depth processes” so let’s have a look at what those actually are. We are going to look deeper into both the Geometry and Rasterisation parts of the pipline.

I know what you are thinking.

Those sound like pretty technical things! S’alright, we are gonna look at each one individually. Imagine we are trying to render a model on our screen. Maybe it is a model of a character. Or a car. Or big massive gothic cathedral. Or an awesome mech. I will probably refer to the model as just a “character.” This is the process that happens to get it on the screen.

  • Geometry – So we kind of looked at this phase earlier on. In deeper terms, a model is made out of polygons and vertices. These are shapes that make up a 3d model. In other words they describe the structure of your game character. Not in gameplay terms but how the shape of the character should be in the game terms. The geometry phase processes all of these polygons and vertices so that data can be used in other phases.
  • Illumination – This is where the models are coloured and lit. In other words, you could see it as textures that represent the details of a character, like Link’s skin and clothing in Zelda are applied to the model and the details of how the model should be lit by light sources in the game like street lamps, the sun, etc are applied. This is the process where fancy programs called shaders (not Destiny 2 shaders, CURSE YOU BUNGIE!) can make models in the game look real nice.
  • View Perspective – The model is processed through a viewing perspective, or rather a camera. The process looks at how the camera is set up, whether it has an Orthographic projection (often used for 2D games) or Perspective projection (often used in 3D games) and how big the field of view of the camera is.
  • Clipping – This process looks to see what parts of the model are outside of the cameras viewing volume or rather what parts of the character can be seen by the camera. The bits that cannot be seen are clipped away.
  • Screen-Space Projection – This where we take a projection of the 3d object and put it into 2D space so it can be displayed on a screen. Monitors fundamentally show a 2-dimensional image so we are mapping the 3d model into this space and producing a 2D image to be displayed on the screen.
  • Rasterisation – This is where fancy post-processes occur. A post-process is an extra visual technique that is applied to the image and includes techniques such as bloom. These techniques are applied to the 2D image created by the Screen-Space Projection phase.
  • Display – This is the final image.

And yeah that is that really. I hope this helps understand how the rendering pipeline works a bit better.