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.

 

Design Patterns: Object Pooling

Image result for Golf Story

Today’s image is from Golf Story, a Nintendo Switch Game that reminds me a lot of Mario Tennis, one of my favourite GBC games.

This article is going to talk about Object Pooling.  The idea behind Object Pooling is to improve Memory usage by reusing object from a “pool” of a fixed size instead of allocating and freeing them individually. I am going to put this in Unity terms as it is what I do professionally every day and the best way I can explain it.

In Unity you have Instantiate and Destroy methods that are used to Create and Destroy objects. For objects that have quite a long lifespan, these methods don’t cause a massive CPU overhead or at least don’t really interrupt the experience (there are of course various scenarios where this case be the case, but for this example let’s go with this). For objects with a short lifespan, this can cause issues. If you have a lot of objects that are created and destroyed per second then

You're going to have a bad time

The CPU needs to allocate more time to dealing with this creation and destruction. With Unity and also managed languages in general like C#, there is also the magic of Garbage Collection, i.e. a system that deallocates memory that is no longer in use. Depending on what you are working in, Garbage Collection can happen without you really knowing and also in ways under the hood you don’t expect. If you are calling Destroy a lot in Unity you are going to trigger the garbage collector. And triggering the garbage collector likes to slow down CPUs and can cause noticeable slowdowns in gameplay.

Object Pooling can be a way around this. The idea is to create all the objects you’ll need before the gameplay. Instead of actively creating new ones and destroying old ones, the objects get reused from a pool.

To put it another way, you are creating a pool that has a collection of reusable objects inside of it. Instead of creating and destroying these, the objects have a state of whether the game is actively using them or not. Before your gameplay you initialize the pool which creates all the objects you will need up front and sets them to the not being used state. When you need a new object, you ask the pool for one. It finds an available object that is not currently in use and returns it. When the game is finished with the object it is freed up again. Objects can be used without having to create and destroy them all the time.

There is a caveat to this though. You are essentially deciding how many you need of a certain amount of object before you run the game. You could get into one of two scenarios. You may have a smaller pool of objects that save on memory however when you get to your gameplay, you find you have too many. On the other hand, you may assign the number for the pool to create to be more than you will ever need, using more memory.

There is a way to get around this. You can make an object pool that expands if it runs out of objects. If you reach the maximum amount of objects in the pool, the pooling system can create one and add it to the current pool. Although there will be a very small overhead of creating the object, it is better than creating and destroying these object all the time like a maverick.

The thing we haven’t addressed though is when we should use them. Well, object pools are designed for when you need to frequently create and destroy objects that are of a similar size (ideally identical). If you look at a bullet hell game, you don’t want to be creating and destroying all those bullets all the time as it will most likely kill your performance. Similarly with particle systems. That continuous smoke cloud coming out of your Volcano will want to use pooling.

Essentially, that is a brief overview of Object Pooling. If you are creating and destroying lots of similar objects in your game, then Object Pooling is for you!

Design Patterns: The Strategy Pattern

Have you guys played Pyre yet? No? Well do. It is one of my favourite games this year. It is also a sort of Strategy game… kind of… it is hard to define what it is really, but it has strategy elements!

In this post I am going to talk about the Strategy pattern. In wikipedia term, the Strategy pattern is a behavioural software design pattern that enables an algorithm’s behaviour to be selected at runtime. Fancy.

In game development terms, we could look at enemies. In an action game, maybe you want the enemies to have different behaviours when they fight the player. I am going to use like an Ace Combat style game as an example. Each Enemy Pilot has some standard stuff, but we want the pilot AI to do many different things. We could use the strategy pattern for this.

public class EnemyPilot
{
    .. Other code here
    private IPilotAI _pilotAI;
    void Update()
    {
         _pilotAI.Update();
    }
}

In the above C# code, I have a class that is the EnemyPilot that contains the IPilotAI interface that we can set at runtime. We can now make a number of AI behaviours that use the Pilot AI interface. This is much better than inheriting from the whole EnemyPilot class each time and we are encapsulating the only thing that varies, i.e. the Pilot AI. And really it as that. Cool huh?