Experiment setup to determine sane LOD values for tree (groups)#6761
Experiment setup to determine sane LOD values for tree (groups)#6761
Conversation
HardwareCPU: 7950x3d DataBase line when completely zoomed out: ~1.5ms
|
|
@Basilisk3 / @lL1l1 / @Hdt80bro / @BlackYps / @speed2CZ / @4z0t / @GodFuper (yes, you make pull requests so here we go 😄 ) and maybe @clyf, and @Dhomie - given that you all have a development environment, please take five minutes to test the changes in question and make a similar comment to #6761 (comment). That should give us enough data to make a decision. |
HardwareCPU: 7800x3d SettingsSet Moholog is open but nothing is being posted in there (debug spew is off). ACU spawn is in north rock, so it does not affect the trees being viewed in the southwest corner (south air). UI Mods (some of them do auto selections which create ~1ms lag spikes intermittently, and I've ignored those spikes):DataBase line when completely zoomed out: ~1.15ms
|
|
Video settings are the same as @lL1l1 to make comparisons easier. HardwareCPU: Ryzen 5600X (but in a virtual machine, so performance is a bit lower than normal) DataBase line when completely zoomed out: ~2.4ms
I think we can reduce the amount of measurement points to two passes with 14, one with shadows and one without, and another with 1.0 where all trees are culled for comparison. |
|
What I find really interesting is the big perfomance drain of the shadows. We should collect some more data about this, but it seems that people could dial in their settings with this tradeoff, where they can decide if they would rather always have shadows or a long tree visibility distance. |
|
I tried testing it again and at first got the same result as before, but after disabling UI party's alternative start sequence I got your result. What's odd is that after re-enabling it, I still don't get the old result. |
That you @BlackYps immediately hit more than 16 ms/frame right off the bat with decent hardware (even if it runs in a virtual machine) is terrifying!
It feels to me that for shadows there is a second batch of (less optimized) draw calls. |
I wouldn't read too much into it unless we have more benchmarks to compare. The virtualization leaves me with roughly 80% of the single core performance compared to bare metal in the cpu-z benchmark, but I don't know how the load in the game might differ from this artificial test, especially regarding the cpu cache. |
|
I was hoping to have some more data. But this will do. What if I make a pull request where I push the the value to |
|
Since we have the new extreme LOD option, wouldn't it be a bit much to bump it from 2.6 to 10? |
|
The extreme option is there for those with the best hardware. And if you have that (as in my case) then you should still be fine, as long as shadows do not render indefinitely. Let's continue this in #6851 |




Description of the proposed changes
Now that we have #6752 to bake properties we have the ability to bake in the LOD values that we want. And since #6751 is merged in we can safely assume that all players will start with the 'High' settings for LODs. Users that take the 'Extreme' setting are on their own.
With that we have everything we need to restart the discussion in #6715.
This pull request provides a standardized test that we can use to inspect the behavior and compare it between hardware configurations. We have to make some assumptions.
With these assumptions we can get some data. The tree groups are broken automatically. There's two hotkeys with a standardized camera configuration:
Then you can open the console using
~. You can open the statistics by typingShowStats. If you open the entity count tab then you can see there's quite a few props. If you open the frame tab then you can see the current time (in milliseconds) it takes to render a frame. This is a combination of he Lua code being run (in the UI thread, each frame) and the rendering of what is on screen. You can also see the current frames per second (fps).Then the experiment can start:
weightfactor of tree groups in blueprint-props.lua. Ideally we check all values ranging from 2.6 up to 14.0 in steps of 2.0.Additional context
Note that FAForever/FA-Binary-Patches#115 also exists. It does not solve the problem of this pull request - if you increase the LOD by too much it will still just lag. but it may (instead) give players the ability to scale the LOD values of the entities (units, projectiles or props) that the player is most interested in.
I'm not sure if being able to scale LOD values of props, units and/or projectiles is a healthy game option to have. It's super specific and technical. Not a lot of players will understand that.