Messages

1

Feature requests / Re: Smart Shader Binding

« on: July 26, 2018, 05:28:35 am »

Coming soon™ to an SFML near you.

While your upgrade is really good, I believe it is not what I was thinking about. The thing is now whenever we do a RenderTarget::Draw() call, the shader is rebinded every time, and so are the linked sampler. So it means  quite a lot of texture binding if your shader use  a lot of different sampler. And I believe this could be avoided by checking if the shader has changed, or its sampler.
However I guess that now with your upgrade it would be even harder to track down the binding in the different contexts. So its probably not worth it except for some very specific cases, and thus it is maybe not something that SFML should do ?

2

SFML projects / Re: ALAGEngine - 2.5D Isometric Shading Engine

« on: April 19, 2018, 10:42:37 pm »

I guess it's my fault because I did not uploaded the rebuild executable. I also remarked that I missed to push some sources. It should be better now. It's not impossible there are still some shaders issues though, I should do more test with other gpu (like ATI).

3

SFML projects / Re: ALAGEngine - 2.5D Isometric Shading Engine

« on: April 18, 2018, 12:16:52 am »

From what I see, I think you are still trying to run with the old file. You should pull (or download) the sources and compile again.

4

SFML projects / Re: ALAGEngine - 2.5D Isometric Shading Engine

« on: April 17, 2018, 07:46:31 pm »

Yeah probably, I should also have more foam for the crashing and it should leave a trail behind. I should also have more randomness in the wave pattern.

5

SFML projects / Re: ALAGEngine - 2.5D Isometric Shading Engine

« on: April 17, 2018, 10:41:23 am »

My bad, a vec3 that should have been a float;  my gpu tends to ignore these kind of things. It should be fixed now.

6

SFML projects / Re: ALAGEngine - 2.5D Isometric Shading Engine

« on: April 16, 2018, 11:13:04 am »

This is nothing short of amazing. Where can I find a download link?

On the git repository: https://github.com/gregouar/ALAG

7

SFML projects / Re: ALAGEngine - 2.5D Isometric Shading Engine

« on: April 07, 2018, 11:55:15 am »

I basically use the heightmap to cast the shadow by considering texels as if they were voxels (so yes, I do not have shadow casted by backface ; I was planning on adding a depth/size value in the heightmap so that I can have better shadows for convex geometry but I don't know yet how to render such assets in Blender). And since I'm working with directionnal lights for these shadows, I only need to precompute the casted shadow when loading the scene and store it in a texture. Then I render them in the framebuffer of the light, using the heightvalue for the depthtest.

Also, here is my attempt at shallow waves rendering:

8

SFML projects / Re: ALAGEngine - 2.5D Isometric Shading Engine

« on: March 16, 2018, 01:14:56 am »

Hi guys ! Here are the latest news.

I mainly worked on my screen space foam rendering algorithm:





The idea is pretty simple, while I generate my heightmap, normalmap and so on I also generate a velocity map which encodes the speed and direction of my water fragments. Then during rendering I can use a simple raytracing algorithm to decide if the fragment will soon collides some opaque geometry. Then I modify the albedo and material of the fragment in function of the distance to the collision in order to generate foam. Since I generate my velocity map with the other maps, I have a  free Perlin noise that I can use to perturb my velocity vectors, to give it the random flavor that foam has.

I also changed my old sinus wave to a Gerstner wave. I generate it by taking N samples on [0,1], moving them along a circle (or ellipse) with angle depending on x. And then I just do a quadratic interpolation between my resulting points, so that I get a function y = f(x). It looks like that (linear interp here):

Quadratic interpolation allows me to compute very quickly the normal map.

Moreover, I added some antialiasing to interesction between 2.5D sprites (which was kind of ugly because of artefacts due to lack of precision in heightmaps). The idea is simple: I use the alpha pass to put some fragments that should be behind, on top, with opacity depending on the difference of depth. It is not very accurate, but the difference is subtle enough to really be a good tradeoff:

Top left: without AA, without SSAO ; Top right: without AA, with SSAO
Bottom left: with AA, without SSAO ; Bottom right: with AA, with SSAO

And that's it for today, stay tuned !

9

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.

10

SFML projects / Re: ALAGEngine - 2.5D Isometric Shading Engine

« on: March 09, 2018, 12:59:31 pm »

Like I explained, you can choose if you want to puts objects as static or dynamics. Static objects have pretty much no impact on the performances since I just copy them in the buffer the first time they appear on screen. For dynamics objects, you just have the cost of drawing their 4 textures to the differents buffers.

Then all lighting is deferred, so it does not change anything for that part which stay "constant" (still depending on the amount of transparent fragments and reflectives one (I use a thresold on reflectivity for SSR). I probably should take some time to analyse my code and do some profiling to improves the performances though. So if any of you has any tips or suggestions, I'm listenning ; I'm still new to OpenGL and advanced graphics (e.g. I read somewhere that branching shaders are bad but it seems that nowadays GPU can handle without any trouble and I gain performances increase by branching out some fragments).

By the way, I fixed some issues with aliasing and SSAO:

Before and after:

11

SFML projects / Re: ALAGEngine - 2.5D Isometric Shading Engine

« on: March 07, 2018, 03:48:31 pm »

However, at least for your final game you want to create with your engine you should work on the performance I think. I tried it on my laptop and the graphics are awesome but I get about 5 FPS only with the GPU being utilized at 30% and one of the CPU cores runs at max utilization.

Sure, optimization is a big part of the job. However, you should already get better performances than that, I'm particularly surprised that the CPU is bottleneck. 

Since I was talking about it, I finally started working on water. Here are the first results, using Perlin noise:


EDIT: And after a bit of additionnal work:

12

SFML projects / Re: ALAGEngine - 2.5D Isometric Shading Engine

« on: March 06, 2018, 09:13:44 am »

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

What do you mean ? The meshes of the 3D models ? If yes, I don't have them for most of the assets because I kind of only recover their prerendered versions from my old projet and lost the original 3D models. But their were super high poly, so you would probably see pretty much nothing. 

By the way, I implemented some basic parallax mapping, using raytracing for more accuracy. I plan to mainly use it for water rendering (and maybe dynamic modification of the relief ?).

Without parallax (we can some weird effect near the bottom tower for example):


With parallax:

13

SFML projects / Re: ALAGEngine - 2.5D Isometric Shading Engine

« on: March 02, 2018, 12:03:02 pm »

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

14

SFML projects / Re: ALAGEngine - 2.5D Isometric Shading Engine

« on: February 28, 2018, 10:19:51 pm »

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

15

SFML projects / Re: ALAGEngine - 2.5D Isometric Shading Engine

« on: February 27, 2018, 09:50:50 pm »

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.