ALAGEngine - 2.5D Isometric Shading Engine

[Gregouar]

Hi everyone,

First of all, let me introduce myself: my name is Grégoire, I'm a PhD student in mathematics. I spent most of my teenage years developping video-games (well, at least prototypes). Maybe some of you knew me from the French section for Holyspirit, which used to be my main project:


After a while, the motivation left me and I kind of stopped developping things (mainly to do more mathematics).
However, I'm now nostalgic of that time, and I recently decided to start again doing stuff (which is not good for my thesis, but heh). So, here I am to tell you about my new project !

The project

Origin

Six years ago, I started working on a some kind of 2.5D shading engine (i.e. old-school prerendered 3D assets but with dynamic, "mordern" lighting effects), using the SFML. It looked like this:

Not very good looking, alright.

Hence, in order to do video-games again, I decided to start by first developping a new 2.5D shading engine, still with the SFML and OpenGL. So here I'm to present what I'm working on, hoping to get some feedbacks and ideas how to improve it.

Generalities and progress

Technical specifications:

• C++
• SFML/OpenGL
• Deferred Rendering
• PBR Shading
• Isometric/2.5D assets

   
Before going into technical explanations, let me put some nice looking screenshots, so that you can see what it looks like right now:



And moving:



Basic concept

The idea is very simple (and not original, there are other examples on youtube, also Pillars of Eternity use some kind of similar technology) and is the following: a lot (well at least I think) of 3D engines use a method called "deferred shading". It consists in doing all lighting computations in the final step of rendering, so that we do not need to compute lighting for obstructed fragments (i.e. pixels hidden by other objects). Concretly, what they do is to render all geometry of the scene in 4 differents buffers which will contain all the necessary informations to compute lighting of the final visible fragment (the one closer to the camera if you want). Those buffers consists in the albedo (i.e. diffuse color), orientation of the surface (some kind of normal map for the whole screen), material (like specularity) and position. I invite you to go take a look here for more explanations : https://learnopengl.com/Advanced-Lighting/Deferred-Shading

Now, what we have to do is replace the part we render the scene in the 4 buffers by rendering 2.5D isometric prerenderred assets. Of course, it means we have to prerender all 4 passes, like this:


Then in the scene, we get something that look like this:

Albedo:

Normal:

Heightmap (in 2.5D we only need the height, the position being given by the coordinnate of the fragment and the camera):

Material:

Note that the asset I use for the building is not PBR, so I just putted an uniform roughness.

Moreover, I use OpenGL depth buffer to determine if a fragment is obstructed by another, so that I can intersect 2.5D objects like if they were in 3D. This will allow me to render complex scenes without having to cut things in multiple parts (like I used to do with Holyspirit for example).

Then, using those 4 buffer, I can dynamically light the scene, add SSAO (Screen Space Ambient Occlusion, i.e. shadowing the corners using the screen geometry), add bloom, etc. In order to make the engine as modern as possible, I decided to implement PBR Shading (i.e. Physically Based Rendering). Those are methods more advanced than the classical Bliin-Phong model, inspired by the physic of our world. They were mainly developped by Disney (for their animation movies) and Epic Games (for the UT4), I think. They allow to get a really nice realistic result and they make the creation of assets more intuitive (material are defined by their "roughness" and "metallicity"). Just by playing with those 2 parameters we can get these kind of results:


I invite you to read the following tutorial to learn more about it: https://learnopengl.com/PBR/Theory

What the engine can do now:

• Render the geometry of the scene with 3D intersection of objects using their heightmap
• Lighting of the scene using PBR methods
• Directionnal shadow casting using the visible geometry of the assets
• Dynamic shadow casting for omni lights using invisible simplified 3D geometry added to the scene (good for buildings, wall, ...)
• SSAO
• SSR
• Bloom
• Two layers of rendering, allowing basic transparency (mainly for antialiasing)
• Optimization for static objects using tiling (I'll explain this in another post)

   
Most of the "classical effects" were done by following and adapting the content from here: https://learnopengl.com/

Goals

In the short term
There is still a lot of things to do to improve the architecture of the engine, add basic fonctionnalities (animated objects for example) and optimization (e.g. optimize lighting and shadowing). I also plan to do rain, with wetness effect for exposed zones (with a similar tech than what I do for directionnal shadows). I'm also thinking about adding 3D mesh in the scene (maybe for the characters, because prerendering all animations is really costly in terms of textures, eating a lot of ram and disk space) and for animated foliages. I'll add screen spaces decals, for blood rendering for example, and particles for smoke. I would also like to add terrain editing using heightmaps. I'm also thinking about adding screen space physics simulation for particles.
And if you have other ideas, I'm listening.

In the long term
I plan to use the engine in an indie open-source game (not Holyspirit 2). But the project is not mature enough for me to talk about it right now.

And why not 3D ?

The first answer that comes to my mind is very simple: I can't do low-poly 3D mesh. But I can do messy hight-poly things. Hence it means I can make my own assets.
Moreover, I really like the old-school look that the 2.5D iso gives.
Finally, it's really fun to develop, and it allows to do interesting optimizations (but it's more costly than simple 3D or classical 2D).


What about the sources ?
You can find them here https://github.com/gregouar/ALAG. However, they are still a bit messy so you should be careful before using anything from there. Also, I must warn you that I use a modified version of SFML where I add a new class: MultipleRenderTexture, allowing me to do multiple render targets in an SFML-like framework (but it's probably not really well done and maybe Laurent will be mad to see what I did  ).

[Mario]

Looks neat. But maybe a stupid question: Why don't you just use multiple `sf::RenderTexture`s in the first place?

[Elias Daler]

Looks incredible!

Btw, don't be shy: you don't have to hide images under spoilers. People are more likely to see them if they're not hidden. Plus, add w=480 or something like that in [img] tag so that images are not cropped in your post.

[Gregouar]

Looks neat. But maybe a stupid question: Why don't you just use multiple `sf::RenderTexture`s in the first place?

Thanks ! If I'm not mistaken, it should be faster to do multiple render in one pass than to do multiple passes. Especially when it comes to bloom where you would need to redo all lighting computations.

Btw, don't be shy: you don't have to hide images under spoilers. People are more likely to see them if they're not hidden. Plus, add w=480 or something like that in [img] tag so that images are not cropped in your post.

w
Okay, thanks for the advice ! 

[Phanoo]

Nice ! It's a good idea to create an engine, separated from the game project. When i start making a game with low level tools like SDL/SFML i always end up spending all my time creating the engine, then I have no motivation left for the game itself. Just be careful about the project size, a man can't compete with 100-people studios ! 

[Gregouar]

Nice ! It's a good idea to create an engine, separated from the game project. When i start making a game with low level tools like SDL/SFML i always end up spending all my time creating the engine, then I have no motivation left for the game itself. Just be careful about the project size, a man can't compete with 100-people studios ! 

Sure, but I don't want to end up like with Holyspirit, where my architecture was a complete mess and nothing could be really used outside of the project. Here, I would like to do something at least a bit reusable and that will simplify my life afterward. But really, I'm not trying to make a full engine, with lots and lots of functionnalities and a perfect architecture. I'm just trying to make something that I hope I will be able to use correctly. 

In fact, from my experience, the two things that made me drop Holyspirit was the production of assets (it requires a lot of time and it's not really my cup of tea, even if I was helped a lot by my brother at that time) and the messy code (at some point it was not bearable to do bug chasing and add functionnalities, so I would like not to fall in this trap again).

[Ceylo]

I really like the rendering of your scene, both realistic and simple enough I’m having a hard time understanding why not use 3D though. I know very few about making video games so don’t be surprised if my questions look basic :-°

And why not 3D ?

The first answer that comes to my mind is very simple: I can't do low-poly 3D mesh. But I can do messy hight-poly things. Hence it means I can make my own assets.

What do you mean with messy high poly things?

Moreover, I really loke the old-school looj that the 2.5D iso gives.
Finally, it's really fun to develop, and it allows to do interesting optimizations (but it's more costly than simple 3D or classical 2D).

Do you mean costly on development time or at runtime for rendering ?

[Gregouar]

What do you mean with messy high poly things?

I mean that making a model ready to be put in a real-time rendering engine is an art that I do not master. I can only play with displacement maps and smooth modifiers to get something that look not too bad. But then I end up with a messy stack of polygons.

Do you mean costly on development time or at runtime for rendering ?

Well it depends; can be both. But I had in mind at runtime. What I'm still not sure if how it would compete with the same scene rendered in 3D with low poly mesh (buth high poly enough to give the same kind of look), keeping the same shading methods.

[Phanoo]

In fact, from my experience, the two things that made me drop Holyspirit was the production of assets (it requires a lot of time and it's not really my cup of tea, even if I was helped a lot by my brother at that time) and the messy code (at some point it was not bearable to do bug chasing and add functionnalities, so I would like not to fall in this trap again).

I had the same problem with assets. I started a nice platformer with a sonic-like engine (handling momentum and walking on slopes), but when the asset creation time came, I felt overwhelmed by the amount of work that needed to be done and got demotivated.

For the code don't try to make the best the first time, follow a simple rule "every time I modify my code, I should make it of equal quality or better, not worse". I've applied this rule to my program and worked very well. Every time I worked on a piece of code that started to get out of control, I took some time to improve it just enough to make it easy to work with again. Then repeat the process... It allows to avoid focusing too much on 'over engineering', just add the needed level of complexity, not more.

[Gregouar]

So I decided to try to implement some Screen Space Reflection, but as expected it's quite slow.

Without SSR:


With SSR and normal map for the ground:


With SSR and flat ground:

[eXpl0it3r]

So is that value in the top left corner?

[Gregouar]

So is that value in the top left corner?

It's the average frame per second and worst frame, but it's not accurate since I was messing with taking screenshot and changing options. Truly it's ~70 FPS without SSR and ~40 FPS with SSR.

[Gregouar]

Today, I would like to speak about an optimization that I made. Here is the problem:


I put something like one thousand tori in my scene. Even if I do all lighting computions at the final step, the rendering still cost a lot of time just to render the "geometry". Here you can see that I'm at something like 10 frames per second.

So, how can we improve that ?

The first solution that probably come to mind is to use VBO. However, I don't think it's good with my pipeline since I need to render 4 different sprites for each entity (for the 4 passes/buffers). But then I thought: most of the scene geometry does not need to be rendered at each frame (we already do the shading in deferred), most objects do not move.

Hence I came with the idea to separate all entities in two sets: the static ones and the dynamic ones. Also, it's not because a "static entity" moves somewhere on the screen that I need to recompute the all scene. Thus I decided to split my screen into multiple tiles, and whenever I tile need to be rerendered, I do it. So that's nice, now I can render my scene again, with all the tori. As expected I run at 60 to 70 frames per second, like without any of them.

However, this means that if I move the camera, I still need to rerender the whole scene !  Which is really bad because it would make everything laggy. But hey, since we are rendering the static geometry in a separate buffer, I can just take a buffer a little bit bigger, and then move it with the camera (I basically just added 1 more tile in width and height). Whenever I reach the boundary, I can just blit (copy) my buffer on itself, one tile in the direction of the camera (really you need to swap between two differents buffers), and update the missing part. With this and my 1000 tori, I have a pretty smooth camera movement, with only one frame that takes a bit more of time to render (equivalent to ~20 FPS in this case).

This will allow me to render very complex scenes without having to worry about the number of draw calls. I hope that this can be useful for anyone with the same kind of 2D engine working with a depthbuffer.

And as bonus, here is a nice screen of the SSR:

free image hosting

[Gregouar]

I think it's time now to show you what in looks like moving:

[Tank]

Really nice. Can you render a blended wireframe on top, just out of curiosity?