Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Gregouar

Pages: [1]
Feature requests / Smart Shader Binding
« on: March 14, 2018, 03:33:35 pm »
Hi !

If I understood well, binding textures is a pretty heavy operation. That's why SFML try not to unbind them if we do several draw calls in a row, using the same texture.
I wonder if it would be possible, or even worth it, to try to do something similar with shaders ?

The idea would be to try to not bind/unbind shader if we continue to use the same, except maybe if a uniform sampler has changed (and in this case, only rebind the corresponding texture). I guess the difficulty would be to track down in which context the samplers have been updated yet... Maybe this can be done by keeping the linked textureId of the context in memory in a std::map (like TextureTable in the shader class). Then we only need to compare them to the one linked in the shader, if it has not been changed ? This could be good if comparing two small std::maps is really faster than binding textures.

For example, maybe all sprites we want to draw using a shader needs to read in the same texture. I'll try to do something like this and see if it has any significant impact on performances.

SFML projects / ALAGEngine - 2.5D Isometric Shading Engine
« on: February 25, 2018, 05:50:02 pm »
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


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:



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


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/


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  ::) ).

Pages: [1]