Lua scripting also offers the users more control over the engine than the editor, like a wider variety of systems that can be added or the possibility to change the skybox.

The engine also implements resource management for textures, geometries and materials. This feature manages the loading and creation of these assets while also providing a centralised point of access to them.

Glare Engine works via Deferred Rendering and users can visualise the result of each pass from the editor itself without needing an external debugging program such as RenderDoc. This window can also show the depth map that is generated from a light if the selected editable entity has the component “Cast Shadow” or other processes results such as SSAO.

As mentioned before the engine supports post-processes like SSAO and Bloom which are enableable and editables from within the editor. Any post-process can easily be added due to it’s post-process system management.

In terms of programming paradigms, the engine works with an Entity Component System in pursuit of optimization and saving frame time. This means that the engine has components that contain data, these components can be added to entities so that systems can work over these entities using the data that their components contain.

Another goal of Glare Engine is to give the users all the tools they need to create scenes and visualize its performance without the need of opening an IDE or the terminal. For this sake the engine also has its own terminal and performance tab. The logs from the terminal will be dumped to a log.txt file, this helps users debug their applications and also provides more in depth information in case of a crash.

Lastly Glare Engine also implements PBR (Physically Based Rendering), which is a computer graphics approach that aims to achieve photorealism.

Shadow Mapping is a technique that is used for generating shadows from light sources. The way it works is by rendering the scene from the light’s point of view and taking a “picture” where we capture the depth of each pixel and output it to a texture. Everything that is shown on the depth texture will be lit from the light source, and everything that is not on the texture but is inside the frustum of the light will have a shadow casted on, unless it is being lit by another light source.

After we have generated the depth map we just have to convert each rendered point to the light’s coordinate space, afterwards we index the shadow map to obtain the closest visible depth from the light’s perspective. Lastly, we compare both depths to determine if the rendered pixel’s depth is greater than the shadow map’s. In that case the point will be within shadows and thus will not be lit.

Shadow Mapping Implementation

For the Shadow Mapping implementation in our engine we have used ECS.

Each light is an entity that has its own transform and light component (Directional Light Component, Spotlight Component, etc.). Additionally, lights that are able to cast a shadow have the “Cast Shadow” component. This component stores the light’s depth texture, its material instance and its light space matrix, that way we can pass it on to the light’s shader when computing the shadows.

We use a system that runs after all of the geometries’ transformations are computed. This system goes through every light with the Cast Shadow component, generates the view and projection matrices for that light, attaches its’ depth texture to the framebuffer that will “take the picture” and finally renders the scene using the generated light space matrix. This way each light has its own shadow map that is generated rendering the scene as if it were a camera.

Finally, on the light’s fragment shader we compute the shadow and use this result to determine how much of each light will be applied to the pixel, if the light is not able to cast shadow the result will always be 1, so it will not affect the light’s result.

For computing the shadow first we perform a perspective divide and transform the projection coordinates to the range of 0 and 1 so that we can use these coordinates to sample from the Depth Map.

In order to achieve softer shadows and reduce the aliasing we have used the Poisson Sampling technique in combination with PCF (Percentage Closer Filtering). This means that we sample from the Shadow Map N number of times each time with different UV coordinates. Each time that the sample is occluded from the light source we subtract to the final light’s result, thus giving us an artificial gradiance on the shadow’s edges and softening them.

The “PoissonDisk” value that you see there is just an array containing constant vec2 that is used for randomizing the sampling.

In order to avoid shadow artifacts there are some solutions that we have implemented. The first and most noticeable shadow artifact is usually shadow acne, this occurs because of the limited resolution of the shadow map which means that multiple fragments sample from the same value. In order to avoid this we just need to add a bias to the depth comparison on the shader. This bias could be variable basing it on the surface’s normal and the light's direction, but during testing we found out that a constant value worked perfectly for us and we could avoid these extra calculations without any noticeable problem.

Another shadow artifact that usually occurs is Peter Panning, the effect that this artifact has is a slight detachment of the shadow from its object. It is the result of our previous fix, because we are applying a bias and reducing the depth of some of our shadow’s points the ones that are the closest to the object aren’t sampled at the exact position. Luckily there is an easy fix that we can apply for this artifact, we just need to change the cull faces to front when rendering the scene in light space.

The last shadow artifact that we had to overcome was Over Sampling. The problem with this shadow artifact is that the regions that are outside of the light’s frustum are considered to be in shadow. This is caused by the fact that these values of depth are achieved from outside the light’s frustum. In order to fix this we must configure, in the case of OpenGL, the border so these coordinates return a maximum depth of 1 and make the textures clamped to the border. Even with that there is still some Over Sampling, the solution to this is also rather simple, we just add a guard to the Compute Shadow function that returns whenever the projected vector’s z coordinate is larger than 1.0.

These are the general settings of our shadows, but there are still some specifications depending on the type of light that is going to be computed.

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.

If skyboxes didn't exist, worlds would feel empty. Players don’t even notice that they are surrounded by 6 still images that are moving with them wherever they go, giving them a sensation of really being inside a world. But that is what they really are, 6 images distributed in the inside of a cube.

To make this, you first need to create a cubemap texture, and render a cube to screen that always goes along with the camera, with the texture mapped using the cubes position as texture coordinates.

When using a Deferred Rendering pipeline, things start to change. The skybox has to be the last thing you render, since you don’t want to compute the lights for the background or apply any post processing to it. The problem here is that you need to have access to the geometry passes depth texture or depth buffer because you only want to render the skybox where no object has already been rendered, behind everything basically. So in order to do that, you take the geometry passes framebuffer and you copy the depth buffer to the skybox passes framebuffer.

The texture coordinates used by the fragment shader to sample the cubemap texture are not the same UVs that the cube geometry has. A skybox's texture coordinates are obtained using the vertex positions, in this case, since it is a cubemap texture and not a 2D texture, the UVs are vec3. If you look closely, the z coordinate is flipped, this is done because the cubemaps coordinate system is left-handed.

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.

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.

PBR implementation

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.