E.T.Engines Archetype Based Entity-Component-System – Part 1: How to use it

To illustrate the way in which I program, I figured it would be interesting to show how I wrote the Entity-Component-System (ECS) for ETEngine. In this first part I will go over the basics of what it is and how we can work with it. In the next part I will go into the nitty gritty details of how it was implemented.

What is an Entity Component System?

Entity Component Systems are a design pattern that formalises the relationship between an Entity in a games Scene, it’s Properties (Data / Components) and the functionality that can be applied to them (Systems).

ECS follows the principles of Data Oriented Design, in which Data Structures (the Components) are defined separately from the logic (Systems). Entities are simple identifiers, with which we can find all the components which hold the data that makes up this entity, which are stored separately. Systems then modify the data in components in a way that’s agnostic to specific entities.

This design pattern is an alternative to other common aproaches game engines use for structuring scene data, like for example Scene Actors (in which all properties and functionality are members of an Actor, often implemented using lots of inheritance), or the nowadays somewhat ubiquitous Entity-Component model that both Unity and Unreal implement in their own way (Components contain both data and functionality, and entities may or may not do so too). Both of these approaches follow a more OOP based approach, and while this may seem a bit more intuitive to work with, there are several benefits to using an ECSs based architecture instead:

  • The separation of concerns makes ECS very easy to modify. Components can be mixed and matched freely for each entity without needing to rewrite anything
  • Components can easily be added and removed from entities at runtime, without needing to worry about breaking complex relationships. Systems will automatically start and stop affecting entities with the relevant components
  • ECS based architecture is highly scalable because it uses composition instead of complex inheritance structures, which makes it easy to add new features as one doesn’t need to worry about breaking existing code or respecting strange edge cases that are distributed across a large code base
  • Last but not least, using ECS can have big performance benefits, especially when handling scenes with large numbers of entities. This is because data can be structured in a way that makes iteration very cache friendly. They also enable mostly automating parallel execution, because systems can strictly define mutability and execution sequencing

Example of a feature implemented using ECS in ETEngine

One of the the features in my engines demo is a spawn system, which is used to shoot balls with rigid body physics from the camera into the scene. Here is how this system is defined:

Continue reading “E.T.Engines Archetype Based Entity-Component-System – Part 1: How to use it”

Planet Renderer – Week 5 – 6: Height, Triangular CDLOD

I missed last weeks post because I was writing a research paper about the graduation work and didn’t get around to updating my blog since. You can read the paper here, I go over a lot of the topics I discussed in previous posts, but also discuss some new things. Aside from that I made the terrain sample a height map in the vertex shader to offset the height of the triangles appropriately. I also made sure that the backface culling doesn’t cull terrain with potential peaks that loom over the horizon. This video shows the results quite nicely:

The more interesting change was added last week:
Continue reading “Planet Renderer – Week 5 – 6: Height, Triangular CDLOD”

Planet Renderer – Week 4: Culling

As I hinted on in my last post, I will be discussing the implementation of culling for planet terrain rendering. When the camera is close to the surface, a lot of the terrain geometry is not visible, so it would not be sensible wasting CPU time on generating it or GPU time on drawing it.

Along with the following picture, my video from last week shows quite well what is going on:
Frustum and backface culling planet terrain rendering opengl c++

Here only the necessary geometry is generated. The implementation to achieve this uses two methods combined: backface culling and frustum culling. I will discuss both methods here along with the implementation…

Continue reading “Planet Renderer – Week 4: Culling”

Planet Renderer – Week 3.5: Terrain LOD

This is a bit of a delayed update, mainly because my computer broke down and I needed to reinstall all software.

Regardless I modified what I had in week 2 to display terrain with level of detail. You can see the results here for yourself:

Apart from that, I also added textures and text rendering with sprite fonts.

Continue reading “Planet Renderer – Week 3.5: Terrain LOD”

Planet Renderer – Week 2: Basic OpenGL Framework

Gif showing icosphere subdivision program in opengl c++

This week I have implemented a basic OpenGL framework for future application of the planet renderer. It can be found on Github, which will be frequently be updated to  keep track of the progress of the rendering tech.

Continue reading “Planet Renderer – Week 2: Basic OpenGL Framework”

Planet Renderer – Week1: LOD Terrain Research

I have put some time into researching the topic of generating terrain at the size of planets with level of detail dependant on the distance of the camera.

There are a lot of different approaches to solving this problem, and it is already clear that I won’t have time to test every one of them myself, but I have identified some reoccuring themes during my time scavenging the internet, and I willl put together a summary of that. Continue reading “Planet Renderer – Week1: LOD Terrain Research”

Planet Renderer

Announcement: Starting this week, every sunday I will be writing a blog post about the progress of my graduation work.

The topic is researching and implementing the creation of a real time planet renderer, with the deadline at some point next January. This is a topic I have been wanting to approach for a while now, so I have been pushing to be allowed to implement this topic as my graduation work.

Continue reading “Planet Renderer”

Hello world!

#include <iostream>
void main()
{
std::cout << “Hello World” << std::endl;
std::cin.get();
}

I have merged my old blogspot blog with this wordpress blog on my new website, so all posts after this one are OLD – as in, before I started higher education.
I added this stuff because I think it’s a nice way of documenting the progress I made over the last few years. 😀