Glare Engine is a multithreaded engine based on the OpenGL rendering API. It has a wide variety of features implemented in the engine. In terms of user experience, it has an application class for the users to inherit and override the init, update and fixed update themselves. In order for the engine to work, you will also need to implement the CreateApplication method and create an application of your inherited class and return it. 

After having the Forward Rendering Pipeline fully functional, we started to change it to a Deferred Rendering Pipeline. In summary, instead of computing the lights in the same shader as the geometry pass, basically computing the lights per drawn object, we first make a geometry pass that outputs the object position, normals, and color as textures and then, after every object has been drawn, we compute each light once, based on those textures.

This has a huge improvement on our performance, that is if we render a lot of lights at the same time. Deferred Rendering is used for large quantities of lights, mostly small lights, that is when the performance improvement really starts to be noticed. It is not magic and it does not come without setbacks. Using this type of pipeline, limits the engine to one material. This material has to be large enough to support all kinds of different types of objects, so if you want to implement it, you have to forget about doing specific materials

Lights

Making this change is not enough to use the full potential of the Deferred Rendering. Lights need to be tweaked in order to squeeze every frame out of it. On our first iteration, all of our lights (directional light, spotlight and point light) were computed using a plane geometry, the whole screen basically. This means that the lights, even though that are only calculated once, they calculate each of the pixels of the screen, so as you can imagine, this is not the best. For directional lights using a plane is the way to go, since it is a global light, so you must compute all of the pixels of the screen. In the case of spotlights and point lights, using the whole screen is a waste of resources since usually they only light up a small part of the screen. The best thing in this case is using a geometry that suits each of the two lights, a sphere for the point light and a cone for the spotlight. This technique limits the computing of the lights to only the amount of pixels that the volume covers, allowing for a much larger quantity of lights. 

The bloom is a post-process effect that has as goal recreate the effect of something glowing. It consist in extracting an rgb value of a “light-finished” scene render target that surpasses a given threshold and save that values into its own texture, after that we blur the given texture with a Gaussian blur which makes the blur harder on the inside and finally we blend the given texture to the final texture of the scene.

This post-process effect has been implemented in the engine as follows.Firstly and after all the lights have been processed we’ve store in a texture only the values that surplus a given threshold (brightness)

After that we started doing the Bloom pass and it came with the first problem as we can not write on the same texture we’re reading, for that we used 3 different materials one that blurs horizontally, one that blurs vertically and one that is used as a decoy passing between them the blurred texture in each axis. To finalize we blend the final blurred texture into the main one.

The entity component system also known as ECS is a popular method used to avoid the inheritance of Object Oriented Programming. Instead of having huge class trees, objects are formed by adding components. These components normally have no inheritance between them, and in order for components to have behaviours, systems exist. It is a data-oriented design.

The systems are the connection between the components. They take different components and add a behaviour to them. In summary, systems are not created for a specific object, instead, they are created to affect objects that meet a certain criteria or pass a filter, which are the components. For example, if a system has a signature of transform and velocity components, all the entities that have those 2 components will be affected by that system.

Making a good ECS is hard, and most of all it takes time. There are 2 good examples of engines using ECS such as Unity and Karisma Engine of Digital Legends. Also, there are a lot of already well built ECS libraries out there like Entt [8]. A bad implementation or simply a good to go implementation, can lead your engine to lose performance instead of losing it. ECS is meant to be used when a large quantity of entities is at play.

Us at Glare Engine, implemented a simple version of ECS which cannot be compared to the ones mentioned above. It works and it is profound enough for us to grasp an understanding of this new programming paradigm called ECS that is slowly invading the graphics programming world.

Screen Space Ambient Occlusion is a technique used to simulate the natural light phenomenon that happens without us even noticing. As we all know, light in real life, bounces off when colliding into something. This means that the corners of objects usually are less bright than the other part. This can really be appreciated by looking at wall corners for example.

If we take a look at the image on the right, we can see that the corners of the mesh are darker than the rest of the mesh. If we take this image and use it together with the light calculations, we can multiply the amount of ambient occlusion that a pixel has to the light output to create similar results as the real life ambient occlusion where edges are brighter and corners are darker, this gives the scene a more realistic lightning look.

The SSAO algorithm was developed by Crytek. The good thing about this algorithm is that it simplifies the ambient occlusion calculation and makes it more performant. The idea here is that you only compute the ambient occlusion once per pixel. You need to sample random points around that pixel's view space position, and check if these points are inside or outside the geometry (using the position texture). Depending on the number of points that fall inside or outside of the geometry in the world, the pixel will be brighter or darker.

• > points inside → Darker

• > points outside → Brighter

There are two parameters that can be tweaked from the editor in order to achieve the desired results: bias and sample radius. The sample radius, as you can imagine, is the radius from the pixel's view space position,where the sample positions will be checked. The bias is used to avoid acne issues that might appear due to precision problems and it is added to the sample positions depth when computing the occlusion.

After computing the occlusion value for each pixel and before we pass it to the lightning pass, we make another pass that blurs out the result to achieve a more smooth results instead of really sharp lines or also to avoid weird fragments that might appear, since the points we sample are random, so the results are random. This technique is not perfect, but it does the work trying to make the least calculations possible. In the case we wanted a more detailed AO technique we can always implement the HBAO and HBAO+ techniques.

When programming the engine, we encountered performance issues that appeared when a lot of objects were being rendered at the same time. To solve this, we started to use instanced rendering or batched rendering. This means that objects that share a geometry and material could be rendered in one single draw call instead of having to make a draw call for each of them. This performance gain starts to be noticeable when large amounts of the same type of objects are being rendered, it is not really for small quantities.

After we had this manually done, for it to be scalable we had to implement a way to automatically select the object that could and would be instantiated, since doing it on your own was not really fast. So before rendering objects, we analyze and sort the objects that have the same geometry and material id, and store the world transform in a list with a key made up of those two values. After sorting the map, we render the objects that have 1 world transform in the list as usual and the ones that have more than 1 are rendered using instanced rendering.

This algorithm can be improved in many ways, since the sorting algorithm is slow and probably we lose more performance doing it than rendering each one separately when the entity count is low.

Glare Engine has PBR implemented for all of its 3 types of lights. Each of them have the same base code with some varieties. The spotlight for example, has an added code that handles filtering the pixels to make the cone lookalike cutoff shape.

The first part of the shader (line 63 to 67) is used to compute the radiance of the pixel. With the distance from the light’s center to the pixel's world position, we calculate the attenuation of the light to then use it to know the brightness of the pixel.

The Fresnel Schlick equation is used to try to get similar results of the base Fresnel equation which can be a bit heavy. The Fresnel equation provides us a percentage of light that gets reflected from a surface after a ray of light hits it. F0 in this algorithm represents the surface reflection at zero incidence.

With the DistributionGGX function we calculate the NDF or Normal Distribution Function, that based on the roughness of the surface computes the quantity of microfacets aligned to the halfway vector.

The GeometrySmith function is another one that we need to use for the Cook-Torrance BRDF to work. The value returned from this function represents how much a microfacet is overshadowed by another in a surface. Lightning reflection starts to reduce when roughness gets higher.

All of the three values above are calculated to then compute the Cook-Torrance BRDF which allows us to know the reflectance or the amount of light that gets reflected.

In the end we calculate the NdotL which we use to know if a pixel is facing the light or not, with a dot product between the surface normal and light direction. And to finish, we use all the data we computed to get the pixels outgoing radiance.