Reduce duration of splats made by projectiles #6952
Conversation
WalkthroughA local variable Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🔇 Additional comments (1)
Comment |
|
How did you come up with the new formula? It's important to note that shorter is not necessarily better. There is a tradeoff because ideally we would display all splats forever. The game engine has a limit, so we need a time duration. This time should be as long as possible without hitting the limit too much, when the time is longer then the battlefiled looks more interesting, because things don't turn back to normal so fast. The problem is that it is not obvious what time that would be. The amount of splats produced in games can be vastly different. Without further context I think it is premature to reduce the splat times by a lot. |
|
The new formula is essentially a random adjustment - the numbers feel decent enough. For larger explosions it remains roughly half a minute. For very small ones (we're talking about tech 1 artillery) the LOD is so low that you won't even see them in general. It's fine if these disappear within seconds I think.
I don't agree with this - it would clutter the screen eventually. But that's beyond the point. I personally think the limit for the number of splats of the engine is quite low. A hundred tech 1 tanks can already cross the same limit using treads. That's why they were reduced the life time of treads in #6089, which was again a reduction of #5132, which was a reduction of the original value in Steam: Which defaults to 15 seconds for all units! This value makes sense when the average game has a unit cap of 250 or 500 units, like on launch. But now when there can easily be 4000-6000 units of which half of them may create treads the limit is just insufficient. And then we at FAForever included these splats that are made by projectiles on top of it 😄! When the limit is passed it can create various artifacts, ranging from splats not spawning, flickering of splats and even having other splats being rendered in splats (Fatboy is most notable here, where mass extractor splats end up mashed into the treads rendering somehow. I don't have a screenshot, unfortunately). Anyway, I don't personally really mind one way or another. I think these values are fine and I suspect they help fix some of the artifacts, given that ~50 tech 1 artillery artillery with split projectiles can easily generate hundreds of splats per second. |
|
The test was conducted using the FAF release version. Just have many Fatboys fire at multiple positions simultaneously and you can observe that the craters suddenly disappear and reappear when the camera is moving or zooming. Moreover, when multiple units are moving at the same time, many treads fail to generate properly. For instance, in the video, the large treads of the Fatboy only generated a short section. 4.mp43.mp42.mp41.mp45.mp4 |
|
@Garanas One question is whether this method will completely "remove" the crater after a period of time, making it no longer exist on the map, or whether it will merely make the crater "invisible", still existing on the map but simply being "unobservable". I just tried using this code, and I set the "duration" of all craters to "1". Although all craters disappeared after 1 second, the tracks soon stopped displaying normally. I don't think this helps with the issue of flickering decals after playing the game for a while. Ah, I think compared to craters, track marks seem to have a greater impact on this issue. I tried moving a large number of UEF T3 artillery (about 200) together, and even if no units on the map were firing, the track marks generated by the movement of a large number of units would still cause the decal to flicker. 1.mp4I think just 200 UEF T3 artillery pieces moving simultaneously would be enough to make the game's decals flicker, and even the textures of the power markers on the map would flicker abnormally. I think the game engine simply cannot support 200 units generating track tracks simultaneously. 2.mp4I changed the duration of all track tracks to 0, and the problem of the map's power indicator flashing when 200 T3 artillery pieces moved was solved. I believe that track tracks also present a problem of excessive decal generation in a short period of time. Each unit generates multiple track tracks within 1 second, and even with the current track track disappearance time, hundreds of units can generate thousands of decals in just a few seconds. This results in a far greater number of instantaneous decals than projectiles. In summary, craters generate continuous, cumulative decals, and their duration needs to be shortened to prevent excessive accumulation over time. Track tracks, on the other hand, generate excessive decals in a short burst, which may require alternative solutions. For example, completely eliminating track tracks and replacing them with a larger, more noticeable dust effect when all units move, or some other method, could prevent a single unit from generating a large number of decals in a short period of time during movement. |
I don't agree with this. There is no good solution here. It boils back to what I wrote earlier:
And to what BlackYps wrote:
The best we can do is to make the best with what we have. I don't think that removing a feature like tracks (or the splats for projectiles) is a good approach when it's not a problem on a lot of maps and army configurations. The tweaking of these values still make sense though, as it may allow us to support more maps and army configurations without artifacts. Unrelated, but since you mention it: using emitters is also not a great solution. Emitters can cause stutters. The game rewinds all emitters if they were not visible before as you are zooming in. All emitters have an LOD value, just like splats, decals and meshes. This is why the generated trail emitters of all units are much shorter than in the Steam version. In the Steam version they'd last about half a minute or longer. In FAForever it is reduced to a few seconds. We can maybe make the emitters easier to see, as all variations except snow can be hard to see at all in my opinion. |
I understand what you mean. The track mark is indeed a very good feature. But as you can see from the video, only 200 units with tracks are needed to make the decals in the game map flicker. I think it's very easy to achieve this number of units in most maps and battles. Also, it's just a personal request. Could you release a MOD that can remove all the track marks from T1 to t3 units and only keep the track marks of the experiment-level units? I think this would be very helpful. At the same time, I think it's worth a try to magnify the emitters generated when T1 - T3 units move. Since these emitters that have already been produced take up performance, it's best to make them more obvious. |
|
@Garanas I've noticed that each land unit has a GroundKickup01. If I change GroundKickup01 to GroundKickup02, the unit's movement animations become much better (more noticeable smoke effects).In this situation, even without track tracks, there can be a good effect on land unit movement. 01.mp4 |
3 participants
Description of the proposed changes
Reduces the duration of splats made by projectiles. We introduced these splats to give projectiles something to leave behind when they explode. To 'influence' the visual aspect of the environment somehow. However, it appears the duration is really long on average. From 15 to 90 seconds, depending on the type of projectile.
With these changes we reduce the time by a lot. There were reports that splats were flickering. That means there's too much going on for the game to manage.
Related: https://discord.com/channels/197033481883222026/1431095378349916261
Testing done on the proposed changes
Additional context
Related: #5616 and #3719
Checklist
Summary by CodeRabbit