Decals reset sorting offset after 32 instances

[Wartificer]

Godot version

4.1.2.stable.official

System information

Windows 10 - 4.1.2.stable.official - Forward+

Issue description

I was making an SMG and while implementing decals for each bullet hole on meshes, I noticed that overlapping bullet holes would glitch because they where all on the same positions and sorting offset. So I implemented a system where my player would remember each bullet as an Int and set that int as the sorting offset for each bullet hole decal, this way each decal would have a different, rising sorting offset. This fixed my original issue but opened another one that seems unsolvable: Whenever 32 shots are fired, the next one would "reset" the sorting offset of the decal that was -32 places before to be on top, even though the sorting offset is still set correctly for each one. I've attached a minimal reproduction project below which shows this issue. Here's a video also showing the issue:

https://github.com/godotengine/godot/assets/139187233/c092b672-03c2-4c4f-b83d-b6babbefc458

Steps to reproduce

1) On some mesh, instantiate decals with rising value on the sorting offset for each one 2) On the 32nd decal, each decal instantiated after it will reset the visibility of the '32 places before' decal to be placed on top

Minimal reproduction project

Decals Issue.zip

[Calinou]

Note that for performance reasons, you may want to prevent too many decals from overlapping in general. Otherwise, FPS will drop if the player gets close to overlapping decals due to fillrate.

This can be done by removing the old decal when placing a new decal nearby (or not spawning a new decal in the first place).

[Wartificer]

Note that for performance reasons, you may want to prevent too many decals from overlapping in general.

I'll probably do this, since overlapping this many bullet holes doesn't look good in the first place, and other games probably do something similar. I think I'll just remove any decals in contact with the decal that will be placed, that seems like the better solution. Still wanted to post this in case this is an actual solvable issue in the engine.