Los performance issues and possible solution

[hokomoko]

So, following the switch to recalculate LoS each frame, planes have become a CPU-munching monstrosity, especially in BA where they have a large sightdistance and players tend to spam them in the 100's.

A possible solution is to allow specific units (in this case the planes) to see their entire sightdistance/radardistance without taking topography into account (similar to how land units see planes).

Would you use such a thing?

(irrelevant comments will be ignored)

[gajop]

(If I understood correctly) I can imagine this exploited by players who know about it for scouting in particularly cliffy maps, like http://zero-k.info/Maps/Detail/7973

Is that the only option? Are there no alternatives, like reducing the resolution, introducing a crude but fast LoS check or separating unit detection from the display (thing that appears when you click "L")?

[hokomoko]

You may look at it as an exploit, but at the moment a land unit can see an air unit without the latter seeing the former.
This basically makes it symmetrical.

Reducing the resolution is indeed an option available to game devs.
Crude and fast is probably not an option.
Separation is not an option,

[gajop]

Makes sense for it to be symmetrical then, and I'm sure some may like this feature, so why not.

At the same time, why not make the identical topography-included check for units? Makes sense for some games where you have few units but want things to be precise.

[Google_Frog]

Do we need to recalculate LoS every frame? Perhaps every second or third frame would be sufficient. This could even be configurable. Regardless, I think it is a good idea to allow disabling of terrain-occlusion on a per-unit basis. This option could also be added to radar.

[hokomoko]

At the same time, why not make the identical topography-included check for units? Makes sense for some games where you have few units but want things to be precise.

We have it, and it's called LoS, but the issue is that it's very hard to make LoS symmetrical.
Currently LoS means: "can I cast a ray from the origin to a point 5 elmo high in the target square without hitting the ground" (with some small approximations).
This is obviously not symmetrical between units, since not all units are 5 elmos tall.
Hence the presence of AirLos - using the assumption that planes are high enough to never be hidden by terrain - usually true, and easy to calculate.

also see this post: http://zero-k.info/Battles/Detail/413572#157528

Do we need to recalculate LoS every frame? Perhaps every second or third frame would be sufficient. This could even be configurable. Regardless, I think it is a good idea to allow disabling of terrain-occlusion on a per-unit basis. This option could also be added to radar.

This is indeed a good idea. It may be possible to reduce the number of LoS casts in a smart manner - if many planes need recalculation, some will only be calculated every few frames.

[FLOZi]

Do we need to recalculate LoS every frame? Perhaps every second or third frame would be sufficient. This could even be configurable. Regardless, I think it is a good idea to allow disabling of terrain-occlusion on a per-unit basis. This option could also be added to radar.

A minor tangent; the latter is semi-possible through setting a ridiculously high https://springrts.com/wiki/Gamedev:Unit ... EmitHeight

Still a +1 from me though

[Jools]

Hence the presence of AirLos - using the assumption that planes are high enough to never be hidden by terrain - usually true, and easy to calculate

It's not really usually true: planes fly very low in spring, you often see them being bumped up by terrain for instance, so this assumption feels contradictory.

I second what GF said: I don't think LoS needs an update every frame, why not do it every slow update? Or configure it?

[hokomoko]

It's not really usually true: planes fly very low in spring, you often see them being bumped up by terrain for instance, so this assumption feels contradictory.

Wanna bet? we can take a random game, and log all the frames where a plane was visible when it shouldn't have been according to topography.
What percentage of a plane's lifetime do you think we're going to end up with?

[Google_Frog]

I prefer a global LoS update rate setting to an intelligent shifting update rate. LoS update rate has a small impact on user experience and game balance so I don't want it changing based on unit count. Also, the ability to set the update rate at every X frames is less prone to breaking than a more complicated system.

[hokomoko]

I prefer a global LoS update rate setting to an intelligent shifting update rate. LoS update rate has a small impact on user experience and game balance so I don't want it changing based on unit count. Also, the ability to set the update rate at every X frames is less prone to breaking than a more complicated system.

Yes but:

1. When you try a global rate, you'll set it to 1 (or maybe 2) in ZK, because a slower rate isn't really needed in ZK. Then when people play a 14v14 on super speed metal their game will slow into a crawl.
2. You're right that giving the gamedev the ability to configure things allows them to handpick the right values for their game, but it also allows them to have the wrong values due to copy pasta, not caring, not knowing or any other reason.
3. It's way more fun to implement, and will actually give consistent results (updating every other frame will not make LoS take half the resources).

[abma]

isn't this basicly the same problem as map deformations? (ignore please when irrelevant )

[raaar]

What were the previous values for LOS refresh rate? How has that changed since 100.0?

allowing game devs to pick different refresh rates is good.To prevent screwup just give them reasonable default values (if once per frame is too performance-intensive, maybe once every 3 game frames, or 6 game frames?)

dynamic los refresh rate could be an optimization : does a fighter really need to updade its LOS contribution on a given frame if it's been updated for half a dozen other fighters on same team within 200 range (with a min rate of, for example, once every 10 frames).

Performance issues on BA are also a game dev problem. Why should fighters be so cheap? Would increasing cost and stats by about 50% or even 100% make the game worse?.

[Google_Frog]

If they have performance problems then game devs should be able to search for, and find, these options.

[hokomoko]

isn't this basicly the same problem as map deformations? (ignore please when irrelevant )

Very similar indeed, and that's why I think a similar approach (spreading recalculations over multiple frames when necessary) is the correct approach.