Improve memory management of treads

[Garanas]

An interesting one, every time a unit would:

• Transition to or from 'Stopping' movement state
• Transition to a new terrain type
• Get beamed up / down from a transport

A unit with treads would:

• Re-allocate the TreadThreads table multiple times
• Kill all threads, if they exist
• Allocate new threads, if we need them

And then something like this happens, that constantly triggers the transition events:

bumping.mp4

On top of that, this pull request decreases the time that a splat (a tread mark) exists by tech while increasing the LOD by tech. See also:

• https://github.com/FAForever/fa/pull/4640/files#diff-4efe2c03fd02522260393e6dde9105da93b49718bc4100b67d194f8b06084c35R34-R46

[Garanas]

Note that the system doesn't actually work properly: try moving 200 tanks at once and you'll see what I mean. There appears to he a maximum to the number of splats being rendered, and that maximum is relatively low in comparison to the number of splats generated.

[BlackYps]

I think that's the same reason why building tarmacs etc. disappear sometimes when tilting the camera. The render limit kicks in. I guess they implemented it to not stress the hardware too much, but today it shouldn't be an issue anymore. Probably needs an engine patch to increase it though.

Do I see this correctly that different tread textures per terrain type are possible?

[Hdt80bro]

Yes, any effect for any terrain type can be changed, see https://github.com/FAForever/fa/blob/deploy/fafdevelop/lua/TerrainTypes.lua

[Garanas]

I think that's the same reason why building tarmacs etc. disappear sometimes when tilting the camera. The render limit kicks in. I guess they implemented it to not stress the hardware too much, but today it shouldn't be an issue anymore. Probably needs an engine patch to increase it though.

Tarmacs are decals, they work different. I'm not entirely sure what the exact difference is.

[Garanas]

Do I see this correctly that different tread textures per terrain type are possible?

Yes, but it didn't quite work like that. At the moment terrain would only disable treads (no need for treads on rocks or metal, for example). As a result the majority of generated maps have no treads. I'm wondering whether that is why generated maps always felt faster than regular maps. With this pull request we change that - treads always work, even when the terrain type tells you not to.

[BlackYps]

generated maps have no tread marks because no terrain type is set. The fix for that should be to set an appropriate terrain type on generation, because there are more effects that also depend on the terrain type, not enforcing tread marks on all terrain.
Unless you want to have it always enabled for a different reason.

[Hdt80bro]

It doesn't look like this will work. Adding back the missing function is trivial, but letting treads underwater, on snow, and on tarmacs looks very unnatural. Since threads are very lightweight, I'm interested in the performance gains. You might be able to get more by consolidating all treads for the unit into one thread, instead of one for each. The Fatboy treads also looks very noisy since it always overlaps both full treads, so I'm not sure that's better.

[Hdt80bro]

This delays tread creation by one interval any time the unit moves again

[Garanas]

Visually that is fine - during the first interval the unit barely moves.

[Hdt80bro]

I can notice it--it's logically an error, just remove it

[Garanas]

adjusted it to waiting just a single tick

[Hdt80bro]

Why do you think you need it?

[Garanas]

Having an infinite loop with no wait statement is asking for trouble.

[Garanas]

@Hdt80bro I partially understand.

Adding back the missing function is trivial, but letting treads underwater, on snow, and on tarmacs looks very unnatural

I agree with the water, but treads have always shown on tarmacs. See also:

Testing on Arctic Refuge and you're correct: the treads do not show on snow. Odd - in my personal perception they should be visible on snow too, but maybe a different type of tread. I'll add in the terrain type check again.

You might be able to get more by consolidating all treads for the unit into one thread, instead of one for each.

I like the idea, but that would be something for a second iteration. This first iteration is already a good improvement memory wise on the current implementation.

[Hdt80bro]

Ah, my bad, these are left over from vanilla

Still, not making tread marks on regular concrete, underwater, on snow makes sense (treads look like the dirt being kicked up, something ice and snow doesn't have--some snow types looks like they're only a thin layer and we could change them, but the tread would probably still look different than normal)

[Garanas]

We could look into adjusting the terrain type:

But how do we change them back, after the tarmac is gone 🤔

[Garanas]

To me the fatboy doesn't look that bad

[BlackYps]

But how do we change them back, after the tarmac is gone

Maybe on destruction of the building, when the tarmac is set for removal with a waiting time period. It's not perfect, as treads would show up as soon as the building is destroyed, but while the building is still alive it would work.

[Garanas]

@BlackYps it wasn't so much about when to change it, more about what to change it (back) to?

[Garanas]

I'll be merging these changes in as they are a good improvement over the old implementation, without changing the old behavior.