2020-02-20 08:46 CET

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0005672Spring engineGeneralpublic2017-07-25 18:42
Assigned ToKloot 
Product Version103.0 +git 
Target VersionFixed in Version103.0 +git 
Summary0005672: Suspicious performance drop between icons and models
DescriptionI have found that my framerate drops from 78 to 18 when zoomed in far enough to see unit models when about 500 units are in view. I expect drawing models to be harder than drawing icons but I think Spring should be able to display 500 units on the screen. In my tests luaUI and luaRules were disabled, nothing was moving and only a few units (those with COB scripts) were firing. I had reloaded luarules twice previously which caused structures and units to duplicate.

DrawWorld Decals, Decals::Tracks and Projectiles increase significantly when zoomed in so perhaps there is a bug or relatively relatively easy optimization. In any case, if DrawWorld::Models was the source of the performance hit I would be less likely to suspect that something weird is occurring.

With previous benchmarks I recall expecting around 25 FPS with 800 units in the game, this was with luaUI and luaRules enabled.
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files




Google_Frog (reporter)

Here is the replay. Unfortunately it requires the sdd version at this point: https://github.com/ZeroK-RTS/Zero-K/commit/99290553f21b408a467fdbd4b7eed30daf072436


Google_Frog (reporter)

The 40% cost of DrawWorld::Projectiles is particularly surprising for me because:
 * There are almost no projectiles on the map and a small number of shields.
 * Projectile rendering does not depend on zoom level, as far as I know.


Kloot (developer)

Last edited: 2017-07-23 16:46

View 2 revisions

Drawing selection shapes for many units is slow.

In both selectedModels and shieldModels there are also almost 1K projectiles and over 5K particles which need to be sorted every frame, shields come with a fairly large cost.


Google_Frog (reporter)

I also took this screenshot.

With further investigation I noticed that this camera angle causes many of the units at that camera distance to not be icons. Angling the camera down slightly causes many of the units shown there to be drawn as icons. Perhaps something is broken with the check for whether a unit should be an icon? Maybe even off-screen units are being drawn?

Do particles appear under draw projectiles?


Google_Frog (reporter)

Here are two screenshots showing the effect. The difference between veryClearMinorTilt and veryClearMinorTopDown is a small tilt of the camera but they have significantly different framerate.

Mantis bans me if I do too many things (and the size limit stops zips) so I have attached some more screenshots to a ZK ticket created for the purpose: https://github.com/ZeroK-RTS/Zero-K/issues/2428


Google_Frog (reporter)

I think displaying units as models at a greater distance when the camera is top down is intended behaviour. It is good behaviour, perhaps there is a bug with it though?


Google_Frog (reporter)

Upon looking into the code I found that the icon-drawing check is not dependent on the distance between the unit and the camera at high camera angles. Instead, for every unit on the map, the distance from the ground to the camera is checked against the icon distance multiplier of the unit. The result is that every unit can be set to draw as a model even if they are on the other side of the map. There are InView checks that (I think) correctly prevent the unit from being drawn if they are not visible on the screen but the screen check is quite deep. I think the performance hit is due to detecting that every unit on the map should be drawn as a model.

GetUseDistToGroundForIcons: https://github.com/spring/spring/blob/develop/rts/Game/Camera/CameraController.cpp#L58

I found a springsetting, UseDistToGroundForIcons, and used it to disable the high angle behaviour for the attached screenshot. The framerate is around 27 fps compared to 13 in comparable images. I will disable the behaviour by default for the sake of performance. Regardless, I think this shows there is some optimization in the checks related to deciding to draw a unit.


Kloot (developer)

when a unit is marked as an icon certain other checks (including InView) are skipped, but 500 units worth of those checks should not add up to a loss of 10fps.

the marking itself is only done for units in LOS so that will process units on the other side of the map if they belong to your allyteam. once marked, a unit icon will always be drawn which might be the problem here.


Kloot (developer)

with Lua* disabled I get a framerate drop of 25 when looking at a screen full of icons (500 units at /disticon 10) compared to a screen full of nothing so the blame goes to out-of-view icons being drawn prior to c8d73777.

-Issue History
Date Modified Username Field Change
2017-07-23 07:24 Google_Frog New Issue
2017-07-23 07:24 Google_Frog File Added: springsettings.cfg
2017-07-23 07:24 Google_Frog File Added: selectedIcons.jpg
2017-07-23 07:24 Google_Frog File Added: selectedModels.jpg
2017-07-23 07:25 Google_Frog File Added: shieldIcons.jpg
2017-07-23 07:25 Google_Frog File Added: shieldModels.jpg
2017-07-23 07:26 Google_Frog File Added: 20170723_145831_Tabula-v6_103.0.1-1228-gff0286b develop.sdfz
2017-07-23 07:26 Google_Frog Note Added: 0018110
2017-07-23 07:28 Google_Frog Note Added: 0018111
2017-07-23 16:36 Kloot Note Added: 0018112
2017-07-23 16:46 Kloot Note Edited: 0018112 View Revisions
2017-07-24 04:03 Google_Frog File Added: bottomRightModelsNoSelect.jpg
2017-07-24 04:03 Google_Frog Note Added: 0018114
2017-07-24 05:07 Google_Frog File Added: veryClearMinorTopDown.jpg
2017-07-24 05:07 Google_Frog Note Added: 0018116
2017-07-24 05:07 Google_Frog File Added: veryClearMinorTilt.jpg
2017-07-24 05:09 Google_Frog Note Added: 0018117
2017-07-25 14:54 Google_Frog File Added: UseDistToGroundForIconsDisabled.jpg
2017-07-25 14:54 Google_Frog Note Added: 0018123
2017-07-25 16:20 Kloot Note Added: 0018125
2017-07-25 18:42 Kloot Assigned To => Kloot
2017-07-25 18:42 Kloot Status new => resolved
2017-07-25 18:42 Kloot Resolution open => fixed
2017-07-25 18:42 Kloot Fixed in Version => 103.0 +git
2017-07-25 18:42 Kloot Note Added: 0018126
+Issue History