Got Stuttering On Pc With Gsync Or Vsync Monitor? - Microsoft Have Released A Patch

Discussion in 'TSW General Discussion' started by paul.pavlinovich, Feb 28, 2021.

  1. paul.pavlinovich

    paul.pavlinovich Well-Known Member

    Joined:
    Aug 21, 2020
    Messages:
    1,684
    Likes Received:
    1,994
    For those of you experiencing stuttering on PC with a gsync or vsync enabled monitor and card. It might not be TSW2. Microsoft have just released a patch on preview which might be of interest. It will come to everyone in the next monthly update but if you're desperate and want to give it a try...

    Microsoft support article
    https://support.microsoft.com/en-us...d=_unht0vesnckfqhs2kk0sohzwxf2xpssqjgdvg3y100

    Tech Radar article where I learned about the patch
    https://www.techradar.com/news/windows-10-gets-a-fix-for-annoying-stuttering-in-some-games

    Paul
     
    • Like Like x 3
    • Helpful Helpful x 2
  2. hyperlord

    hyperlord Well-Known Member

    Joined:
    May 20, 2019
    Messages:
    1,245
    Likes Received:
    1,270
    I manually downloaded and installed the update and made an NVIDIA driver update, too.
    Will try out this evening (after work) after rebooting my PC.

    The stuttering got a lot better thanks to the guides here in the forum (geloxo Callum B. ) but it's not yet "perfect" @ ~ 45-50 fps on my machine. Tinkered with the ultra-fast refresh so this might play into my test, too.
     
    • Like Like x 1
  3. paul.pavlinovich

    paul.pavlinovich Well-Known Member

    Joined:
    Aug 21, 2020
    Messages:
    1,684
    Likes Received:
    1,994
    Let us know how you go. I've just ordered a 165Hz monitor that supports g-sync to replace my aging 60hz monitor so its going to impact me more shortly I suspect. Right now I'm running at 60fps without too many issues and same - using a lot of the suggestions from here on the forum plus making sure the computer itself is happy using benchmarking tools.
     
  4. hyperlord

    hyperlord Well-Known Member

    Joined:
    May 20, 2019
    Messages:
    1,245
    Likes Received:
    1,270
    Hey guys,

    the first test came out so good I started tinkering a lot more (again). The experience while driving was best since I play any TSW game. There are very short (1 sec) hangs when huge areas are loaded and this is not happening frequently. While driving the scenery is really smooth but I do notice some micro-micro stuttering. This is why I went back to this great thread again and set the VSYNC to 1/3 and the ingame limiter to 48 fps. With DX12 my rig can bring that fps (and yeah, since everything is going so much better now I raised the picture scaling to 130% @ WQHD to "fix" AA). Turning on VSYNC ingame worses the experience so I keep this off for the ongoing tests.

    I need to verify today the again modefied frame-target/VSYNC settings and if it is nor worsening I test more routes for consistency of the experience and report back.
     
    • Helpful Helpful x 1
  5. hyperlord

    hyperlord Well-Known Member

    Joined:
    May 20, 2019
    Messages:
    1,245
    Likes Received:
    1,270
    Hey guys,

    still tinkering, yesterday I tried the 1/4 vsync with locked 36 fps but the result was more visibilble stutters even though the framerate was constant. I think this is my perception because I now know the game can run faster/smoother on my system.
    I upped the internal limiter to 45 fps and it got a lot better.

    I now changed the vsync to 1/3 and keep the fps target 45 fps locked and try again this afternoon.

    What I observed during gameplay: As long as the FPS are constant the scenery seems lag-less. But when the framerate drops like 1% or less there comes a quick hang, more hang and sometimes with audio pitching a little bit. I run in the DX12 mode, maybe it's something special to this mode only? But I'm okay with that since it is not happening that frequently anymore ... maybe I got used to it ;-)

    The tile-loading is wayyyyy better with having this in the engine.ini:
    r.TextureStreaming=0
    r.Streaming.FullyLoadUsedTextures=1
    r.Streaming.HLODStrategy=2

    With DX12 I can keep the constant FPS target 98% of the time (with the tested routes [ECW, SKA]) so maybe my experience changes when I'm forced to go back to DX11 somewhere in the future. I know my SSDs are underperforming because my mainboard is 12 years old and not the providing modern sata-speeds so there is potential, too. I'm not planing to upgrade soon because TSW starts to perform way better on my system from day to day hehe

    I'll report back if I learned more from testing.
     
    • Like Like x 1
  6. paul.pavlinovich

    paul.pavlinovich Well-Known Member

    Joined:
    Aug 21, 2020
    Messages:
    1,684
    Likes Received:
    1,994
    I run DX12 too hyperlord it seems to help. I do also use those settings.
     
  7. hyperlord

    hyperlord Well-Known Member

    Joined:
    May 20, 2019
    Messages:
    1,245
    Likes Received:
    1,270
    Tested couple of routes and it works really great at the moment. I switched back to DX11 since the strobo-locos where back (under certain circumstances - don't know if daytime is the key). WIth DX11 I get FPS in the range between 30-45 with "okayish-short (like 1sec) because it has been a lot worse" drops when entering freight yards (populated with other trains).

    While driving there are close to zero hangs/stutters in 98% of the time, the 2% is my engine.ini and the underperforming SSDs (due to SATA speed).
     
    • Like Like x 1
  8. paul.pavlinovich

    paul.pavlinovich Well-Known Member

    Joined:
    Aug 21, 2020
    Messages:
    1,684
    Likes Received:
    1,994
    I've not had any weirdness with DX12 hyperlord there is a patch downloading right now so I'll see if it is still the same after that :)
     
  9. Shaun123

    Shaun123 Well-Known Member

    Joined:
    Jan 22, 2018
    Messages:
    488
    Likes Received:
    1,304
    I’m definitely noticing some input lag still? Even if the FPS doesn’t drop, the refresh rate of my monitor is, probably because of G-Sync?

    Time to play around with a few settings I think!
     
  10. geloxo

    geloxo Well-Known Member

    Joined:
    Nov 21, 2018
    Messages:
    956
    Likes Received:
    1,694
    What a finding! The HLOD one was a lifesaver for me. It removed the lag when heavy scenes are loaded and also when AI trains are spawned. For high speed trains this is a must, and in particular in GWE route where the scenery and traffic are both quite heavy.

    But I think the second one (r.Streaming.FullyLoadUsedTextures) is not really needed, as with the first (r.TextureStreaming=0) you are already disabling texture streaming according to Unreal documentation. Definitely the main problem related to tile loading lag and stuttering appears to be the usage of streaming for textures and LODs. They should seriously consider removing it completely from game.

    Cheers
     
    • Like Like x 1
  11. Shaun123

    Shaun123 Well-Known Member

    Joined:
    Jan 22, 2018
    Messages:
    488
    Likes Received:
    1,304
    Here’s a few things I’ve tried in trying to get best combination:

    My GPU is a RTX2080 Super,
    Monitor - 27” ASUS VG27 1440p 144hz

    Texture Streaming - Off & DX12 enabled.

    So G-Sync/V-Sync enabled plus in game FPS capped at 60 FPS, noticeable mini stutters but nothing of concern.

    G-Sync/V-Sync enabled - FPS uncapped, in game FPS running between 100-120, sometimes higher depending on route. Noticeable mini-stutters as above but my concern is GPU fan noise, which is distracting.

    G Sync Off - V-Sync On, monitor refresh rate 144hz and in game capped at 60FPS, stutters far less noticeable if any, but I’m noticing less smoothness, if that makes sense?

    So, still look for anymore suggestions, but we’ve had a few good ones posted already.

    Also, I must say the stutters aren’t game breaking in the slightest, just slightly frustrating at times!
     
  12. fanta1682002

    fanta1682002 Well-Known Member

    Joined:
    Dec 22, 2019
    Messages:
    1,175
    Likes Received:
    561
    r.TextureStreaming=1 IS VERY GOOD
     
  13. geloxo

    geloxo Well-Known Member

    Joined:
    Nov 21, 2018
    Messages:
    956
    Likes Received:
    1,694
    The problem with it is that it loads low resolution textures in the objects not visible by camera to help performance. So when you pan around you see how textures are being loaded and it creates the small stuttering, and also the effect of changing textures is something I personally don´t like at all. When disabled the whole scene is loaded and kept in memory when tile is processed so everything has the same quality when panning around since the moment the objects become visible.

    It was also bugged in the earlier game releases and it loaded lower resolution textures in the locomotives and cabs as well even while being visible for camera instead of the full resolution textures. That was the main reason why I disabled texture streaming months ago. In any games I have seen that feature the quality is always degraded when using it and you normally don´t need it at all on systems with enough memory installed.

    Cheers
     
    Last edited: Mar 14, 2021
    • Like Like x 2
  14. geloxo

    geloxo Well-Known Member

    Joined:
    Nov 21, 2018
    Messages:
    956
    Likes Received:
    1,694
    Hi. Best results so far with:

    DX12 enabled (again)
    FPS set to unlimited (no need to limit them nor to use the vsync trick)
    r.TextureStreaming=0
    r.Streaming.HLODStrategy=2
    r.CreateShadersOnLoad=1
    r.FinishCurrentFrame=1​

    The last line removes the buffered frames and also solved the flickering headlights issue with DX12 in my case. As a result of that line the FPS are a bit lower but super steady during rendering. As DX12 gives higher FPS the overall result is much better in my opinion and you don´t have the severe FPS drops when approaching yards or big stations. With DX11 I couldn´t use that line as the FPS reduction was massive.

    Cheers
     
    Last edited: Mar 16, 2021
    • Like Like x 1
  15. solicitr

    solicitr Well-Known Member

    Joined:
    Jun 20, 2020
    Messages:
    11,735
    Likes Received:
    17,949
    Unfortunately, if you like to use Livery Designer or use LD-modded rolling stock, DX12 is right out. Instant crash on load.
     
  16. geloxo

    geloxo Well-Known Member

    Joined:
    Nov 21, 2018
    Messages:
    956
    Likes Received:
    1,694
    Yeap, but the performance difference is amazing. Steady 50FPS as average on whole GWE in my last tests, including the depots and platforms. Another 50FPS at Hagen with crowded yard from cab view. Never had something like that before as the FPS were jumping up and down all the time and never were so good and stable at Hagen, specially at the bridge area which for some reason was a resource hog with DX11.

    TS2Prototype-Win64-Shipping 2021-03-16 02-53-30.png

    The tile loading is still an issue as the FPS drop, but they drop even with default game settings, so maybe we need a NASA SSD disk to solve it... DX12 is still the most effective method for rendering even if not yet supported.

    The current settings I use are quite extreme indeed, as r.ViewDistanceScale is the one that hits performance on yards due to high amount of rail splines as it increases their detail with distance. I also went down to 0.25 with the static meshes that also improves the rail curvature... Both were fine for my system. The combination of DX12 plus r.FinishCurrentFrame where the final key for stability.

    My system is a i9-9900k + Nvidia 2080Ti. I run at 1080p with 200% scaling and I used the following for engine.ini in the tests:

    [SystemSettings]
    r.MotionBlurQuality=0
    r.TextureStreaming=0
    r.Streaming.HLODStrategy=2
    r.CreateShadersOnLoad=1
    r.FinishCurrentFrame=1
    r.StaticMeshLODDistanceScale=0.25
    r.ViewDistanceScale=5
    r.LandscapeLODDistributionScale=3
    r.LandscapeLOD0DistributionScale=3
    foliage.LODDistanceScale=5
    grass.densityScale=1.5
    r.Shadow.MaxResolution=4096
    ts2.passenger.DensityScale=3

    The system resources are used properly (9 Gb on RAM, another 8 Gb on card, card core under good load and all CPU cores under load as well and balanced). DX12 is clearly more efficient for this game. With the above settings I would get half the FPS with DX11. So game is fine, ready for DX12 and able to support much better visuals if needed. All we need to do is to tune the Unreal features in a different way than the one used for current default game config.

    Resources.jpg

    Cheers
     
    Last edited: Mar 16, 2021
    • Like Like x 2
  17. paul.pavlinovich

    paul.pavlinovich Well-Known Member

    Joined:
    Aug 21, 2020
    Messages:
    1,684
    Likes Received:
    1,994
    I use Livery Designer with DX12. I have heard some of the logos cause problems but general painting and creating shapes and text seems to work.

    Paul
     
  18. solicitr

    solicitr Well-Known Member

    Joined:
    Jun 20, 2020
    Messages:
    11,735
    Likes Received:
    17,949
    Now that's interesting. Unless a recent patch cured it, running DX12 for me always caused an instant crash on loading LD itself, or loading any service that had custom liveries in it.
     
    • Like Like x 1
  19. hyperlord

    hyperlord Well-Known Member

    Joined:
    May 20, 2019
    Messages:
    1,245
    Likes Received:
    1,270
    geloxo Nice you found a cure for the DX12 headlights flickering, I added your recently shared ini-lines, switched back to DX12 and can't wait until my workday is over to test it out. Yesterday I ran the Cement Mixer scenario, at the location from your screenshot I had like 17 FPS :D
     
  20. geloxo

    geloxo Well-Known Member

    Joined:
    Nov 21, 2018
    Messages:
    956
    Likes Received:
    1,694
    I was also surprised by how well Hagen yard behaved (all yards in general) with the combination of DX12 and r.FinishCurrentFrame=1. I presume the problem are the tracks themselves in DX11, as the scenery around is not so big indeed. One big difference between the two modes is the effect of r.ViewDistanceScale. This increases the level of detail of distant sleepers and also the one from tracks with third rail but the overall scenery draw distance is not increased so much because the changes in the values maybe mean just 100m more in the viewdistance, which is relevant for the tracks but not relevant for the houses or trees for instance (just few more are added).

    With DX11 going from 2 to 3 may mean 5 or 10 FPS less and definitely values lower than 20-30 FPS in Hagen or complex yards and it´s relevant in routes like GWE where 4 tracks are used in main line. A total no go... But with DX12 and r.FinishCurrentFrame=1 the effect seems to be less relevant and you are still above 30 FPS even with a value of 5. Indeed going from 2 to 5 in that case does not drop FPS. Before that I never went above r.ViewDistanceScale=2 in game due to this problem to handle big yards. Now I can even go as crazy as r.ViewDistanceScale=10 that gives you an amazing distant track detail and the FPS are still kept stable. So it seems having stable FPS helps the overall performance as well (maybe some CPU-GPU workload is released).

    Cheers
     
    Last edited: Mar 16, 2021
    • Like Like x 1
    • Helpful Helpful x 1
  21. solicitr

    solicitr Well-Known Member

    Joined:
    Jun 20, 2020
    Messages:
    11,735
    Likes Received:
    17,949
    Nope, still the same: just picking an alternate livery crashes it, as does trying to open Livery Designer, or even a timetable service in a default livery if the route has modded liveries in it.
     
    • Like Like x 1
  22. geloxo

    geloxo Well-Known Member

    Joined:
    Nov 21, 2018
    Messages:
    956
    Likes Received:
    1,694
    Another set of interesting findings, this time related to the tile loading and the periodical hitches (micro lags).

    Tile loading is one part of the process to create the world ahead. For that Unreal uses level streaming (or tiles streaming), so content will be read from disk and objects will be created in world. This is done by separate threads. Unreal also implements a garbage collection system where objects that are no longer referenced or have been explicitly flagged for destruction will be cleaned up at regular intervals (so the part of the world we left behind is being destroyed).

    This part is too deep for me but I understand the concept, so probably someone with deeper knowledge of Unreal could help us here. There´s one feature which is acknowledged to be a soruce of hitches in proyects:

    s.ForceGCAfterLevelStreamedOut --> Whether to force a garbage collection after levels are streamed out to instantly reclaim the memory at the expensive of a hitch.
    This is enabled in game default settings (value 1), so every time a new tile is loaded also the old objects are cleaned. This could make sense but you turn into the situation where you create and destroy things at the same time, so that may freeze game when a heavy tile like a yard is being created. There are also some variables that schedule object cleaning over time, instead of forcing it to happen when a new tile is created. That could be an option to prevent the hitching:

    gc.LowMemory.TimeBetweenPurgingPendingKillObjects
    gc.TimeBetweenPurgingPendingKillObjects​

    On the other hand the creation of the objects ahead is split into several frames, so tuning how much work/objects are handled per frame would allow to improve how efficiently a heavy tile like a yard is being created.

    Interesting variables to explore:

    s.ForceGCAfterLevelStreamedOut
    s.ContinuouslyIncrementalGCWhileLevelsPendingPurge
    gc.LowMemory.TimeBetweenPurgingPendingKillObjects
    gc.TimeBetweenPurgingPendingKillObjects

    r.Streaming.NumStaticComponentsProcessedPerFrame
    s.LevelStreamingActorsUpdateTimeLimit
    s.PriorityLevelStreamingActorsUpdateExtraTime
    s.UnregisterComponentsTimeLimit
    s.LevelStreamingComponentsRegistrationGranularity
    s.LevelStreamingComponentsUnregistrationGranularity​

    Some support reading about both topics:

    Sub level streaming FPS drops - UE4 AnswerHub (unrealengine.com)

    Peter Leontev - Entrepreneur & Game Tools & Tech Programmer | Level Streaming And Garbage Collection Optimization Tweaks In Unreal Engine 4

    Aparently there´s no magic formula to find the gold settings working in every game, but maybe we can find the best possible set for our game.

    Cheers
     
    Last edited: Mar 16, 2021
    • Like Like x 1
  23. geloxo

    geloxo Well-Known Member

    Joined:
    Nov 21, 2018
    Messages:
    956
    Likes Received:
    1,694
    Ok guys... Good news! I have found the reason for the tile loading hitching (or at least one of the reasons) and also a fix. The problem is the following variable:

    r.Streaming.NumStaticComponentsProcessedPerFrame --> If non-zero, the engine will incrementaly inserting levels by processing this amount of components per frame before they become visible

    It´s set to 50 in default game config, meaning that additional 50 components are processed per frame. Changing it to 0 solves the issue and removes the tile loading hitching and lag as we are not adding any extra amount of objects per frame during the creation of new tiles. Just add the following to engine.ini:

    r.Streaming.NumStaticComponentsProcessedPerFrame=0​

    I have made several tests in GWE which is a heavy route. Using a morning service (so with AI traffic and so on) I always had some stuttering and freezing when arriving stations. Specially in the case of Reading there was always a sequence of 3 freezes around 2 miles away from station till the station was made visible, and FPS went down to 20-30. After the change the station simply loaded instantly. The whole route now runs perfect and I have just observed small variations in the FPS which are the normal ones as the rendered scene is not static but no side effects at all so far (I´m talking about 5 FPS up or down normally, even when tiles are loaded). This is simply amazing.

    Could you please check if you get the same results and if you see the same on other routes as well? In that case we should warn DTG about this so that it could be analyzed by them too as impact in game smoothness is huge.

    Cheers
     
    Last edited: Mar 16, 2021
    • Like Like x 1
  24. JetWash

    JetWash Well-Known Member

    Joined:
    Mar 6, 2021
    Messages:
    2,367
    Likes Received:
    8,770
    I’m not seeing the same thing unfortunately. Earlyish 166 run to London, Winter Clear and the stuttering is the same as it’s always been. Good news it seems to be working for you though!

    3900x, 2080ti OC, SSD, 32GB RAM & run the game in 4K
     
    Last edited: Mar 16, 2021
  25. geloxo

    geloxo Well-Known Member

    Joined:
    Nov 21, 2018
    Messages:
    956
    Likes Received:
    1,694
    Oh... Maybe the screen resolution is the difference, but I run at 200% scaling, which is also very demanding. Anyway this is the config I used for tests. Be sure to run game in DX12 mode:

    [SystemSettings]
    r.MotionBlurQuality=0
    r.TextureStreaming=0
    r.Streaming.HLODStrategy=2
    r.Streaming.UseFixedPoolSize=1
    r.Streaming.PoolSize=0
    r.CreateShadersOnLoad=1
    r.FinishCurrentFrame=1
    r.Streaming.NumStaticComponentsProcessedPerFrame=0

    r.StaticMeshLODDistanceScale=0.5
    r.ViewDistanceScale=5
    r.LandscapeLODDistributionScale=3
    r.LandscapeLOD0DistributionScale=3
    foliage.LODDistanceScale=5
    grass.densityScale=1.5
    r.Shadow.MaxResolution=4096
    ts2.passenger.DensityScale=3

    The important lines are the ones above r.StaticMeshLODDistanceScale (marked in blue). The rest you can skip as they are my own scenery tweaks. Anyway don´t go too extreme with the scenery settings, specially with r.ViewDistanceScale as the track details can´t be infinitely high without starting to have severe impact on performance, specially in yards and stations.

    Cheers
     
    Last edited: Mar 16, 2021
    • Like Like x 2
    • Helpful Helpful x 1
  26. solicitr

    solicitr Well-Known Member

    Joined:
    Jun 20, 2020
    Messages:
    11,735
    Likes Received:
    17,949
    Observable decrease in 'hitching' through Munchen, one of the busiest paces in TSW. But not a huge one - then again, I'm only using 120% scaling.
     
    Last edited: Mar 16, 2021
    • Like Like x 1
  27. geloxo

    geloxo Well-Known Member

    Joined:
    Nov 21, 2018
    Messages:
    956
    Likes Received:
    1,694
    Nice, nice. We are on the good way. I´m testing now the following parameters, so you may want to try them as well:

    s.ForceGCAfterLevelStreamedOut=0
    s.ContinuouslyIncrementalGCWhileLevelsPendingPurge=0
    s.UnregisterComponentsTimeLimit=0

    s.LevelStreamingActorsUpdateTimeLimit=0
    s.PriorityLevelStreamingActorsUpdateExtraTime=0

    With them we prevent the forced garbage collection upon new tile loading and remove the time limit for elements registration and unregistration. The first three should specially help in the tile loading, as we are not forcing the previous tiles destruction (it´s done periodically anyway, but we just don´t force it to happen). The last too are also removig the time limit but for the scene updating process.

    Cheers
     
  28. Tigert1966

    Tigert1966 Well-Known Member

    Joined:
    Aug 18, 2020
    Messages:
    1,599
    Likes Received:
    2,651
    I have to confess I don't really understand a lot of what was said above, but I tried your settings on SEH and there is a noticeable improvement. I noticed one very small stutter and that was all. Running at 200% scaling I was getting a very constant 40 fps. Reducing that to 150% scaling 60-70 fps but a few extra stutters, but very short, no big pauses.
     
    • Like Like x 1
  29. geloxo

    geloxo Well-Known Member

    Joined:
    Nov 21, 2018
    Messages:
    956
    Likes Received:
    1,694
    Yeap, that matches with the results I have seen as well. There are some limitations and maybe we can´t solve them until a core updating is released. There are pieces of the routes that need to load a lot of stuff in short time (maybe a yard next to a big station and that happens in the border of two tiles, so the worse case) and that needs some extra effort and maybe is simply too much even for high-end systems. But I have seen that the overall rendering is vastly improved and the FPS drops only occur when the system is really put into severe stress.

    DX12 appears to handle much better the rails drawing and both static and skeletal meshes so it´s not struggling in the yards, even if the track details are high, which is not the case with DX11. With the addition of r.FinishCurrentFrame=1 we also get more stable FPS in the whole route. If we manage to find the magic behind the tile creation/destruction to minimize the hitching we would have solved some of the main issues that affect game rendering.

    Cheers
     
    Last edited: Mar 16, 2021
    • Like Like x 3
  30. hyperlord

    hyperlord Well-Known Member

    Joined:
    May 20, 2019
    Messages:
    1,245
    Likes Received:
    1,270
    Will give the improved ini a try today, haven't had time yesterday so I'm excited
     
  31. geloxo

    geloxo Well-Known Member

    Joined:
    Nov 21, 2018
    Messages:
    956
    Likes Received:
    1,694
    Nice. Yes please let us know if you see benefits. I was testing game yesterday and the tile hitch is not really removed (or at least not in all routes). So I have doubts now that r.Streaming.NumStaticComponentsProcessedPerFrame=0 is really helping, even when using other values than 0. However s.ForceGCAfterLevelStreamedOut=0 appears to help something. The other variables which were not in the ini I pasted with the Hagen screenshot do not seem to help either (I tried with different values as well).

    I think the real enhacement comes from the combination of DX12 and r.FinishCurrentFrame=1. That is what makes game really change and behave fluently and as a side effect the tile loading is improved in some cases.

    Cheers
     
    • Like Like x 1
  32. solicitr

    solicitr Well-Known Member

    Joined:
    Jun 20, 2020
    Messages:
    11,735
    Likes Received:
    17,949
    Any suggestions how to cure the conflict between DX12 and Livery Designer?
     
  33. geloxo

    geloxo Well-Known Member

    Joined:
    Nov 21, 2018
    Messages:
    956
    Likes Received:
    1,694
    I have no idea, about the editor but, after further reading and investigation, today I got some new positive results ;) Let me try to explain it the best way I can, as I think now I have really found the reason for the tile loading lag and the test results show that this can be definitely been improved. Sorry if I simplify it too much but I´m not an expert on UE4. Please also correct me if I´m wrong.

    New tiles creation

    The routes world is divided into tiles (levels). Game thread books a fraction of time in ms (the update time) on each rendered frame to create the objects that are going to be included in the tile. A defined amount of objects (the granularity) are processed in a group on each frame. The following variables are used to configure this process. I include also their default values:

    s.LevelStreamingActorsUpdateTimeLimit = 5 (5ms per frame booked for creation)
    s.PriorityLevelStreamingActorsUpdateExtraTime = 5 (5ms per frame booked for high priority creation)
    s.LevelStreamingComponentsRegistrationGranularity = 10 (10 elements to be created during each frame)
    r.Streaming.NumStaticComponentsProcessedPerFrame= 50 (50 static objects to be processed per frame before the tile is made visible)

    Old tiles destruction

    On the other hand the objects from tiles we left behind have to be destroyed to prevent incresing memory usage and resources. This is done by the so called garbage collector in Unreal. In a similar way to creation there´s a fraction of time per frame to do that and also a number of elements that will be processed in a group at every frame. Some additional variables exist in this case and I also include their default values:

    s.ForceGCAfterLevelStreamedOut =1 (forces the destruction of old tiles once a new tile is created)
    s.ContinuouslyIncrementalGCWhileLevelsPendingPurge = 1 (repeats the destruction periodically until no more tiles are pending)
    gc.TimeBetweenPurgingPendingKillObjects = 61 (a destruction cycle will be called every 61s to clean old objects)
    s.UnregisterComponentsTimeLimit = 1 (1ms per frame booked for destruction)
    s.LevelStreamingComponentsUnregistrationGranularity = 5 (5 elements to be destroyed during each frame)

    The problems

    The method is good but the periodical lag we see is a known issue in UE4, so many users report similar problems related to tile loading. The main ones we have in our case are the following:

    - If destruction happens at the same time as creation the game suffers a hitch. This is caused by s.ForceGCAfterLevelStreamedOut=1 and s.ContinuouslyIncrementalGCWhileLevelsPendingPurge=1, as we are forcing the garbage collector to be called. On the other hand disabling those variables will not prevent RAM usage to grow over time until you exit to game main menu to load another route, so we still need some periodical cleaning. This can be done with gc.TimeBetweenPurgingPendingKillObjects=61 but we don´t need this to happen every minute and this can be increased to reduce the cleaning frequency so that creation is not disturbed.

    - If a tile becomes visible before the incremental object processing has been completed, then all pending work needs to be finished immediately and that could produce a hitch. So r.Streaming.NumStaticComponentsProcessedPerFrame needs further tweaking to increase the default value so that more objects are processed in each incremental step.

    - Every rendered frame needs to use the booked time for both creation and destruction when they need to happen. If this booked time is too high the game will produce the stuttering. On the other hand we need to create a large amount of objects in short time as the trains move fast. We can balance this by dedicating less time per frame but creating more objects in each of the frames. This can be configured with the time limit and the granularity variables.

    - If we process too many objetcs per frame there will be a hitch on heavy tiles. On the other hand if we process too few the scenery won´t be loaded in time before we arrive and we will see pop-in bridges, houses or even tracks close to our point of view.

    - There´s a physical limit that I doubt we can overpass: the creation of a big station or yard, or even worse, a big station next to a yard. It´s going to be lag there as we can´t create infinite objects in miliseconds, specially if there are complex buildings and AI trains involved there. We must live with this, but we can try to reduce the duration of that lag if we are able to reduce the bottlenecks in the object creation.

    What I propose for the testing are the following changes to the default values, at the expense of a bit higher memory usage but with much less stuttering and better FPS stability (as seen in my test results):

    s.ForceGCAfterLevelStreamedOut =0 (don´t force destruction of tiles at the same time the new ones are created)
    s.ContinuouslyIncrementalGCWhileLevelsPendingPurge = 0 (don´t repeat periodical destruction even if tiles are still pending)
    gc.TimeBetweenPurgingPendingKillObjects = 300 (we can clean every 5 minutes, as the memory usage would not increase too much)
    s.UnregisterComponentsTimeLimit = 1 (1ms per frame booked for destruction produces less stuttering)
    s.LevelStreamingComponentsUnregistrationGranularity = 5 (objects to be destroyed per frame)

    s.LevelStreamingActorsUpdateTimeLimit = 1 (1ms per frame booked for creation produces less stuttering)
    s.PriorityLevelStreamingActorsUpdateExtraTime = 1 (same as above for priority creation. This is added as an extra booking)
    s.LevelStreamingComponentsRegistrationGranularity = 25 (as we booked less time per frame we need to create more objects)
    r.Streaming.NumStaticComponentsProcessedPerFrame= 250 (more objects can be created in each incremental step of tile generation)

    Probably there´s a better combination of times, objects amount and periodical cleaning interval, but the results using the above variables configuration clearly point to the aparent reasons for the tile loading lag:

    1) Forced destruction at the same time as creation (maybe to prevent higher memory requirements for game)

    2) Too much time booked per frame for the object creation (maybe to allow less powerful systems to run game)

    3) Heavy tiles become visible when not all required objects have been processed by the creation incremental steps, so work needs to finish immediatelly and a hitch is produced (not easy solution to fix this exists and probably this is an engine limitation due to nature of route details at some areas)

    If you see your memory usage growing too much then maybe 10 minutes is too long for the scheduled cleaning, and you should put lower values in gc.TimeBetweenPurgingPendingKillObjects. Once you load another route the memory will be purged anyway, so don´t panic.

    The complete ini file for DX12 mode would be as follows:

    [SystemSettings]
    r.TextureStreaming=0
    r.CreateShadersOnLoad=1
    r.FinishCurrentFrame=1 <<-- This is only required for DX12 mode
    s.ForceGCAfterLevelStreamedOut=0
    s.ContinuouslyIncrementalGCWhileLevelsPendingPurge=0
    gc.TimeBetweenPurgingPendingKillObjects=300
    s.UnregisterComponentsTimeLimit=1
    s.LevelStreamingComponentsUnregistrationGranularity=5
    s.LevelStreamingActorsUpdateTimeLimit=1
    s.PriorityLevelStreamingActorsUpdateExtraTime=1
    s.LevelStreamingComponentsRegistrationGranularity=25
    r.Streaming.NumStaticComponentsProcessedPerFrame= 250​

    Add your own additional tweaks for scenery, viewdistance, shadows, etc. The ones I use to improve image quality are the following:

    r.StaticMeshLODDistanceScale=0.4
    r.ViewDistanceScale=5
    r.LandscapeLODDistributionScale=3
    r.LandscapeLOD0DistributionScale=3
    foliage.LODDistanceScale=5
    grass.densityScale=1.5
    r.Shadow.MaxResolution=4096
    ts2.passenger.DensityScale=3​

    I made some tests at Munich-Ausburg having just very sparse stuttering at some specific dense points (3 or 5 in the whole route) while driving above 350km/h. But that stuttering was lasting less than half a second. Compared to the standar one this is a massive improvement. I even tried an entry to Munich station at 200km/h as an stress test and there the expected lag happened as the tile is superdense, but station and yard were created in less than 1 second with a very small stuttering/hitching. Spawned AI traffic did not create any aparent stuttering even at high speeds.

    I´m waiting to receive my new video capture video to show you the results in a video. Please let me know if you find this consistent and also matching with your own results. In general I think most routes behave better after those changes and where there´s residual stuttering or lag is where it´s impossible to improve it anymore due to the nature of the tile complexity. Maybe we can find alternative values but I would suggest to focus on those variables set as they appear to be the guilty ones :)

    Cheers
     
    Last edited: Mar 18, 2021
    • Like Like x 2
    • Helpful Helpful x 1
  34. hyperlord

    hyperlord Well-Known Member

    Joined:
    May 20, 2019
    Messages:
    1,245
    Likes Received:
    1,270
    I'm implementing the vars in my ini and report back
     
    • Like Like x 1
  35. solicitr

    solicitr Well-Known Member

    Joined:
    Jun 20, 2020
    Messages:
    11,735
    Likes Received:
    17,949
    I will deff give it a spin- but OTOH, my rather dated setup has a 1080 monitor with no Gsync, and refresh of 75. (Also, DX11)
     
  36. geloxo

    geloxo Well-Known Member

    Joined:
    Nov 21, 2018
    Messages:
    956
    Likes Received:
    1,694
    Don´t lose faith so fast mate! :o :D

    Cheers
     
  37. geloxo

    geloxo Well-Known Member

    Joined:
    Nov 21, 2018
    Messages:
    956
    Likes Received:
    1,694
    Quick update. Please use:

    r.Streaming.NumStaticComponentsProcessedPerFrame= 500 (it was 50 in default config and we didn´t change that)

    Just checked that it clearly helps regular tiles generation (prevents bottlenecks so work for tile generation is finished on time more frequently). Heavy tiles are slightly improved by it but they are still a challenge. Please use that value and start from there. I have updated the previous post with this change.

    Cheers
     
    Last edited: Mar 17, 2021
  38. hyperlord

    hyperlord Well-Known Member

    Joined:
    May 20, 2019
    Messages:
    1,245
    Likes Received:
    1,270
    Okay I did some testing yesterday but not to an extend I wanted to :)
    Thank you geloxo for spending so much time with this issue and sharing so much useful information! I think I'm understanding as far as possible regarding the GC variables and the logic behind it.

    I continued with the freight journey on RRO since I noticed I have low fps with short standstill around Langerfeld.
    First I tried as I said earlier with everything applied and in DX12. I had like 20-27 FPS BUT constantly without the hangs. The ride was smoother as the framerates might suggest.

    Sadly r.FinishCurrentFrame=1 is too much for my current config. I thought about dialing down the resolution but then the flickering would come back. So I decided to remove FinishCurrentFrame=1, set the game to DX11 again but left the "new blue variables" in. It was the same smooth experience but with +10 FPS. What is pretty cool: Those lockups (where the train engine soundloop pitches or other audio glitches) are gone.
    Tried the Hagen freight yard with the 363 later and yeah ... smooth even though the FPS not mega high.
    I'm okay with that since I have not a potent machine and I think I'm more or less at the limit.

    What I noticed (I graph my PC via SNMP polling) when looking at the recorded average CPU utiliziation during game: In DX11 it's 25% more.
    During both runs the RAM went up to the top and the pagefile got extended. So I think I need some more tuning maybe?
    I never have thought that performance/experience is possible just with ini-Tweaking and without upgrading any hardware (which has potential when I do so). Average FPS between 30-45 was okay and the hangs on RRO (tried RSN and ECW, too) are gone. I'll report back with the new value for r.Streaming.NumStaticComponentsProcessedPerFrame

    Capture.JPG Capture2.JPG

    My system:
    i7-965 Extreme @3,2 GHz, RTX2060 Super, 16 GB RAM (DDR3), Crucial SSD (but underperforming due to mainboard SATA)
    Running game fullscreen 2560x1440 resized/upscaled to 125% no overclocking of GPU or CPU

    My engine.ini (I think there is more tuning potential without loosing visual quality ...)
    r.MaxAnisotropy=16
    r.ViewDistanceScale=1.5
    r.LandscapeLODBias=-2
    r.LandscapeLODDistributionScale=3
    r.StaticMeshLODDistanceScale=0.25
    r.SkeletalMeshLODBias=-5
    r.MipMapLODBias=-3
    r.HighQualityLightMaps=1
    r.TextureStreaming=0
    r.CreateShadersOnLoad=1
    r.CreateShadersOnLoad=1
    r.Streaming.FullyLoadUsedTextures=1
    r.Streaming.HLODStrategy=2
    r.Streaming.UseFixedPoolSize=1
    r.Streaming.PoolSize=0
    r.Streaming.NumStaticComponentsProcessedPerFrame=50
    r.Shadow.DistanceScale=2.0
    r.Shadow.FilterMethod=1
    r.Shadow.MaxResolution=4096
    r.DefaultFeature.MotionBlur=0
    r.MotionBlurQuality=0
    r.AmbientOcclusionLevels=4
    r.DepthOfFieldQuality=0
    r.TemporalAASharpness=1.0
    r.TemporalAASamples=64
    r.TemporalAAFilterSize=1.0
    r.TemporalAAPauseCorrect=1
    r.PostProcessAAQuality=6
    r.ToneMapper.Sharpen=1
    r.MaterialQualityLevel=1
    r.SSR.Quality=2
    r.AmbientOcclusionFadeRadiusScale=50
    grass.densityScale=5
    foliage.ForceLOD=0
    foliage.DitheredLOD=8
    foliage.DensityScale=1.0
    foliage.LODDistanceScale=5
    s.ForceGCAfterLevelStreamedOut=0
    s.ContinuouslyIncrementalGCWhileLevelsPendingPurge=0
    gc.TimeBetweenPurgingPendingKillObjects=600
    s.UnregisterComponentsTimeLimit=0
    s.LevelStreamingComponentsUnregistrationGranularity=5
    s.LevelStreamingActorsUpdateTimeLimit=1
    s.PriorityLevelStreamingActorsUpdateExtraTime=1
    s.LevelStreamingComponentsRegistrationGranularity=50
     
    • Like Like x 2
  39. Tigert1966

    Tigert1966 Well-Known Member

    Joined:
    Aug 18, 2020
    Messages:
    1,599
    Likes Received:
    2,651
    Top work geloxo I tried these latest settings yesterday and for me the frame rate was down and the stutters were back. But that’s possibly because I was playing a scenario with a lot of fog and rain. I’ll play around some more over the weekend.
     
    • Like Like x 1
  40. davidh0501

    davidh0501 Well-Known Member

    Joined:
    Apr 29, 2020
    Messages:
    1,134
    Likes Received:
    1,638
    Nice work.
    One day we'll have optimised settings for the ini.
     
    • Like Like x 1
  41. geloxo

    geloxo Well-Known Member

    Joined:
    Nov 21, 2018
    Messages:
    956
    Likes Received:
    1,694
    Thanks guys. All I did was a research on the Unreal forums to collect the experience from other users and the suggestions done by the official developers. I think there´s no magic combination and each system will get better results with some tweaks than others. In most cases the above variables just influence in how the game threads behave (if more checkings or actions need to be done per frame) so there´s a clear impact on how we "disturb" the rendering smoothness. The main problem is that even without disturbances the system still needs to render a heavy scene which is generated very fast, so maybe that´s a limitation we can´t remove (I don´t expect that we can remove it completely).

    About the possibility to use the settings with DX11 and remove r.FinishCurrentFrame=1 as hyperlord explained this is something I didn´t tried myself, so I will test it today. The CPU usage is something that could be explained by DX12 being more efficient, and therefore requiring less CPU-GPU interaction, so this is not meaning than your CPU is under its optimal utilization but just that it´s not required to be used more.

    Cheers
     
    • Like Like x 1
  42. solicitr

    solicitr Well-Known Member

    Joined:
    Jun 20, 2020
    Messages:
    11,735
    Likes Received:
    17,949
    Tried the new settings last night and the result was a butter-smooth, hitch-free drive at 45fps! Caveat: it was a Class 37, so not exactly taking an ICE into Munchen. I'll try that next.

    New question: how does one access the Unreal console? So far all I can do is quit game/edit engine.ini/restart game.
     
    • Like Like x 1
  43. geloxo

    geloxo Well-Known Member

    Joined:
    Nov 21, 2018
    Messages:
    956
    Likes Received:
    1,694
    You need an application called unreal unlocker. Check the dynamic weather tool thread in my signature. There a step by step guide is included as I also use the console for my tool. Console is very fast and easy to test different settings in real time.

    Important: in the console the commands need to be entered without the "=" symbol used for the ini file. Use a blank space instead. For instance: r.ViewDistanceScale 5



    Cheers
     
    Last edited: Mar 18, 2021
    • Like Like x 1
    • Helpful Helpful x 1
  44. geloxo

    geloxo Well-Known Member

    Joined:
    Nov 21, 2018
    Messages:
    956
    Likes Received:
    1,694
    Final touches after today´s testing. I have seen that we should not leave s.UnregisterComponentsTimeLimit=0 but set it to 1. We will just book 1ms per frame and just destroy 5 objects, which is not having a big impact but ensures a small cleaning is still done per frame and memory usage does not grow so fast. We will still have the periodical scheduled cleaning, so we are safe. Anyway we are creating objects faster than we are destroying them, so memory will increase. Maybe scheduled cleaning can also be reduced to 5 min with gc.TimeBetweenPurgingPendingKillObjects=300.

    On the other hand I think the amount of objects to create was too high and we may be generating hitches in some cases (just the opposite to what we wanted). For instance I noticed that if a tile generation includes an AI train inside this is too much for my system at least, even on a regular tile with just a small station inside. I would propose to reduce the values to a half like this:

    s.LevelStreamingComponentsRegistrationGranularity=25
    r.Streaming.NumStaticComponentsProcessedPerFrame=250

    This is still 5 times the default amount but you may require even lower values depending on how powerful your system is. Observe the following to find the best balance: too much objects in those variables can generate hitches even on regular tiles while too few may lead to scenery not loading in time and pop-in bridges, houses or even tracks closer to your train. I updated the previous post with these new proposed values.

    Cheers
     
    Last edited: Mar 18, 2021
    • Like Like x 4
  45. hyperlord

    hyperlord Well-Known Member

    Joined:
    May 20, 2019
    Messages:
    1,245
    Likes Received:
    1,270
    Hi geloxo
    Thanks again for doing all the tweaking!!! I planned to have such tedious tuning-sessions on Saturday but you keep on saving me a lot of time! :)
    You were right, I ran with the settings before your last update yesterday and performance was a little bit, like 3 FPS lower than before. I thought this might be because of the route (RSN, didn't run the entire route with those new settings before). Today I changed the 4 vars to your new findings and will report back. It seems like my system is responding very granulary to those variables and things you tweak on your machine behave quite similar on my machine ;-)

    Changed settings in my ini now:
    grass.densityScale=1.5 (saw this a couple of times at other inis, was 5 in mine)
    s.UnregisterComponentsTimeLimit=1
    gc.TimeBetweenPurgingPendingKillObjects=300
    s.LevelStreamingComponentsRegistrationGranularity=25
    r.Streaming.NumStaticComponentsProcessedPerFrame=250
     
    Last edited: Mar 19, 2021
    • Like Like x 1
  46. JetWash

    JetWash Well-Known Member

    Joined:
    Mar 6, 2021
    Messages:
    2,367
    Likes Received:
    8,770
    It goes without saying that you have to test these settings on the same route, at the same time of day, in the same loco with the exact same weather.

    I’ve fallen into this trap before thinking I saw a big improvement in something yet it was entirely down to the route and/or time of day which I’d changed.

    Sure you’re doing that anyway but just in case :)
     
    • Like Like x 2
  47. geloxo

    geloxo Well-Known Member

    Joined:
    Nov 21, 2018
    Messages:
    956
    Likes Received:
    1,694
    I think we are on the good way to get the optimal results. The stuttering is really improved once we reduced the booked time per frame for the objects creation/destruction. Adjusting the amount of objects per frame and tile seems to be the key to get the lowest tile loading lag without creating additional hitches ourselves. I guess there will be a balanced limit for each PC and things like Munich station tiles will always have a small lag upon loading. But so far I´m very happy with results as the stuttering is now really small, less frequent and average FPS are stable as well. It seems to help on DX11 as well so maybe we won´t need DX12 at all.

    Be careful with grass density as for some reason it produces quite a big impact on some routes when going above the value of 3. On SEH it also produced floating bushes inside of the tunnels when above 2 (I noticed it with the freight services). That´s why I took 1.5.

    You are right about the tests JetWash as AI traffic is not always the same and that´s an important factor that people tends to forget while tweaking configs. I always do the tests using the same service in each route to be able to observe the real changes effects.

    Cheers
     
    Last edited: Mar 19, 2021
    • Like Like x 1
  48. solicitr

    solicitr Well-Known Member

    Joined:
    Jun 20, 2020
    Messages:
    11,735
    Likes Received:
    17,949
    It might not be a bad idea to agree on one particular service/location/weather conditions as the Reference Test (much like audioheads back in the day used to use Dark Side of the Moon)
     
  49. geloxo

    geloxo Well-Known Member

    Joined:
    Nov 21, 2018
    Messages:
    956
    Likes Received:
    1,694
    Is not that you have to use always the same service for all your tests but that you test the modifications made to a parameter using the same service. If not done that way you are never able to see the impact of that parameter alone.

    Cheers
     
    Last edited: Mar 19, 2021
  50. solicitr

    solicitr Well-Known Member

    Joined:
    Jun 20, 2020
    Messages:
    11,735
    Likes Received:
    17,949
    I understand, but I was talking about having a common reference service for all the different .ini noodlers to use, so that when notes are compared they're on the same page.
     
    • Like Like x 2

Share This Page