Frame drop when updating country distance field

[OneBogdan01]

Godot version

v4.1.1.stable

godot-cpp version

4.4

System information

Windows 10

Issue description

This is caused because of the brute force approach when generating a SDF for the countries. This incurs a frame drop when assigning a province to a new country. It is easier to notice when the camera is in movement. I confirmed that this is the case because of the subviewports and not any other logic.

The fix is implementing a JFA algorithm for doing this in a more efficient manner. This paper can be used to achieve just that.

Another approach could be to move this to a compute shaders, this might result in faster times, but it has to be tested.

[adadgio]

Hi, I've tried to implement a multi-pass algorithm (6 passes in my example) like the paper suggested. I can set the Subviewport to render always without noticable performance in my editor, but have no way of testing it's actual performance. It seems to create a satisfying distant field, but was a pain to setup !

Here is a screenshot of the result.

Technique: use backbuffer copies with color rect with X jfa shader passes until the final output, which is copied in the final sprite. Could be set up to use a X number of passes with a bit of work...

Would you like me to make a PR on your repository with the test scene so you can have a look at it ? Disclaimer, I'm not very good with shaders, so I used AI as a starting point to write them.

Regards

[OneBogdan01]

Thanks for reaching out! You can open a PR and I will take a look after my university exams are done, which is this week.

[adadgio]

Here we go ! #16

You'd have to tweak the params to get what you see in the proposed image.

Hope the exams went well,

[OneBogdan01]

Here we go ! #16

You'd have to tweak the params to get what you see in the proposed image.

Hope the exams went well,

Hi, thanks, I ll see how they go when I get the results, since it is always a ride. I went into your PR and I think I get a pretty good output already via the 32 stride to 1. Is there any reason I should want to get the output you show? I left some comments on the PR, I am thinking I would like to use the techniques you showed there in my own branches, as to maintain consistently with the rest of the codebase. Tell me what you think!

[adadgio]

Yes, there is a good reason (I did it for provinces, but you can do it for countries the same way). The shaders are much faster and can be updated more often (hopefully keep the SubViewport as "always" running), its purpose is to be able to create gradient shaders and achieve the same province/country effect you can see on this image:

[OneBogdan01]

Those borders look amazing! Are these with vector based or is it the technique used in the plugin?

[adadgio]

I struggled. No, not at all, the AA scaling is the same technique you used. The thin borders work by calculating how close a pixel is to a border (color change on province) map, an only draws a pixel if close enough (controled by border_with). Strangely... i cannot make them so thin inside a viewport with a color rect, it only works on a Sprite2D, i have no idea why... (i wanted to make it run only once, since its expensive).

I think it would be possible to use the province distance field I posted in the example, but again, i could not for the love of god make thinner borders than the width of distance field one.

[OneBogdan01]

I struggled. No, not at all, the AA scaling is the same technique you used. The thin borders work by calculating how close a pixel is to a border (color change on province) map, an only draws a pixel if close enough (controled by border_with). Strangely... i cannot make them so thin inside a viewport with a color rect, it only works on a Sprite2D, i have no idea why... (i wanted to make it run only once, since its expensive).

I think it would be possible to use the province distance field I posted in the example, but again, i could not for the love of god make thinner borders than the width of distance field one.

It might be because it is textured bounded, so you will get bounded by how big the image is at the end of the day. The real Parado games use a vector approach instead, so they define splines for the borders and then run the effects we do over them. They are infinitely scalable. Definitely something that I want to try sometime.

[OneBogdan01]

@adadgio Hello, I believe there is either something wrong with the shader approach you showed me a few days ago, or something that intrinisc to the JFA algorithm
Top is the approach you had with the copying in the same viewport

Zooming in there is some kind of pattern with JFA:

And this is the same but from the naive way:

By doing a distance 1 in the final shader you get

[OneBogdan01]

I am not sure how to what is going on wrong here...

[adadgio]

Ok, I tested it form my commit, and indeed, there is something wrong. I'll check my old file to see if I can find the problem, i can replicate as well and confirm the output image is bugged.