Hi. Please stop using Unreal default project settings in game core (default engine.ini values). They are simply useless, too old and not optimized at all for nowadays hardware nor for the design of the game. Those values are so bad that result in systems underperforming below their real capacity. Look, I created a post 2 years ago for TSW2 explaining the most relevant needed changes, It can be used as basis to find the best values you want to use according to your needs for different platforms: https://forums.dovetailgames.com/th...-engine-ini-optimizations-for-ue-v4-26.50311/ TSW3 was released, it came with same UE4 version and same engine.ini. I played it for less than 20h and parked it. Now we have TSW4, still same UE4 version and still the same hardcoded engine.ini designed for platform games 20 years ago. Those settings are so badly optimized that today, using a i9-12900ks CPU, 4090 GPU, NVMe disks (x10 faster than SSDs) and 64GB RAM, I still have the same results I had 2 years ago with my old HW. Even one of the most recent HW setups can't run game fine. You keep squeezing Unreal beyond its limits and I can understand that and your business model, even if I strongly disagree on that approach as well as other users, but please don't ignore anymore the artificial limitations you are generating by the usage of a so outdated parameters set on an app which is mainly driving all major workload on a single game thread. Main topics to consider are the following: 1. Don't use the old render thread sync method. Use RHI method instead. It's more than proven that RHI sync results in much lower latency as clearly explained in the UE documentation. Combining that with the usage of DX12 you can improve performance and smoothness dramatically. https://docs.unrealengine.com/4.26/en-US/SharingAndReleasing/LowLatencyFrameSyncing/ 2. Don't use MB size caches in the era of the GB size VRAMs, RAMs and disks. That makes usage of caches basically useless, in particular if you pretend to deal with HD textures like nowadays. 3. Don't add additional latency to game thread because it's already overloaded when a new tile loading happens. Reduce frame times to 1 so that tasks running on a frame can be completed faster and be released, and other tasks can still take advantage of the remaining frame time. For instance: adding a 10ms delay with the hope that a heavy task could be split in several frames simply does not work. It may work in 1990 but not now. On a fast modern system it just adds a 10ms delay to the current frame, even if the task can be completed in just 0.5 ms. When this happens in 100 tasks you have as a result 1 second freeze because thread is just waiting for nothing. When Unreal is not able to finish a task in one frame it will anyway move it automatically to the next frames until task is completed. You don't need to do anything. When using those extra delays you are just generating a long freeze on tile loading process artificially because those 10ms extra delays are also propagated to each new frame on each task too until all tasks are complete, resulting in thread having to wait much more than in the same situation with tasks split in several frames but with no artificial delays set. 4. Optimize gargage collector because it's generating extra delays on game thread when triggered too frequently, even it that's still needed to control memory usage. It does not need to be triggered every minute as it will just release less than 100 MB in memory. Increase purge interval to several minutes (remember we are in the GB era, so memory is meant to be used). By no means force garbage collector upon new tile loading. It's the worst thing you can do to an already overloaded thread because you put yet more workload to the most demanding step of the rendering process, when new scenery is loading. 5. Enable DX12 PSO cache. As in the case of shaders the PSO cache allows to pre-compile and re-use the PSOs. However currently there´s no PSO cache folder created anywhere in "Documents\My Games\TrainSimWorld4" (that would be the expected default location; I didn´t find it at least) which indicates that such cache is not enabled at core project in Unreal editor. Trying to enable it via engine.ini does not generate any cache files either, so it´s apparently disabled, which would prevent DX12 to take advantage of the benefits of pre-compiled PSOs generated during game loading for instance. Please guys take a deep dive in unreal configuration. Game can run really much better that it runs and achieve high fps figures. I can get 90 fps and stay above 60 fps on complex areas but I also get 2 second freezes during tile loading in the middle of nowhere without any reason other than game thread being holding on a timer. That makes no sense. If you publish new routes with increasing level of detail as time goes by, but you continue using not only the old engine but also the old default paremeters, no system on Earth will be ever able to run it fine. I don't want to play TSW4 for just few hours as I did with TSW3 but I have no problem to do it again. Less hours mean less money invested on this as well as you can imagine. Cheers
Thank you for this post. I stopped playing TSW because of perfomance problems - and i know that they are fixable. I just can't play something that is poorly optimized and stutters all the time - it ruins all the fun and experience. I got tired by fixing engine.ini instead of developers. I love trains and i love driving them, but not with stutters.
You are welcome. Yes, I´m tired as well. I played TSW2 for 1400h and got a lot of DLCs to support them. I just played TSW3 for 20h and got a few 50% discounted DLCs only. If this is the way they want it then let it be. This is not good for players nor for the studio I would say. And the solution to the problem is indeed so simple that it hurts to see they simply ignore it. All they need to do is to configure a 5 Kb file to get the best out of the game engine. Cheers
I'm curious if these ini settings were optimized via patch on console (since they can't be edited manually) whether it would make the gameplay smoother? Perhaps something DTG should be seriously looking into testing so that their "new" game can be something that actually runs well on a modern console.
I’m on the verge of spending a lot on a new and much faster PC in the hope that the pauses and stutters will be at least less noticeable. It’s very worrying that some folks here are still seeing problems on rigs with some of the fastest processors, M.2 SSDs and graphics cards.
I’ve currently got a 5800x3D, 3090 & NvMe drives and on DX12 I’m not really seeing anything overly problematic. It’s definitely better on DX12 than DX11 and improves with the caching.
could u please reply to this post with the custom engine.ini u use if u can get that frame rate i swear i got the classic custom engine.ini that was added with some new lines for TSW3 by someone and been using that with TSW3 and using the same now and finding frame rate way worse
I have modified my enhancement used for TSW3 and found a significant improvement in TSW4 so far, using DX12 (Based on very helpful input by "Jetwash" in this forum, with sincere thanks.) Here's my current Engine.ini setup: [SystemSettings] foliage.LODDistanceScale=5 gc.MinDesiredObjectsPerSubTask=20 gcNumRetriesBeforeForcingGC=5 gc.TimeBetweenPurgingPendingKillObjects=200 r.AllowLandscapeShadows=1 r.AmbientOcclusionLevels=3 r.AmbientOcclusionMethod=1 r.CreateShadersOnLoad=1 r.DFDistanceScale=10 r.DFFullResolution=1 r.DistanceFieldShadowing=1 r.GTSyncType=1 r.LightMaxDrawDistanceScale=50.0 r.MinScreenRadiusForLights=0.00 r.OneFrameThreadLag=1 r.RenderTargetPoolMin=3000 r.Shadow.CSM.MaxCascades=5 r.Shadow.CSM.TransitionScale=2 r.Shadow.DistanceScale=2 r.Shadow.FilterMethod=0 r.Shadow.MaxCSMResolution=4096 r.Shadow.MaxResolution=4096 r.Shadow.RadiusThreshold=0.03 r.Shadow.SpotLightTransitionScale=4096 r.ShadowQuality=3 r.StaticMeshLODDistanceScale=0.25 r.Streaming.Boost=2 r.Streaming.FramesForFullUpdate=2 r.Streaming.LimitPoolSizeToVRAM=0 r.Streaming.MaxTempMemoryAllowed=12000 r.Streaming.NumStaticComponentsProcessedPerFrame=500 r.Streaming.PoolSize=24000 r.ViewDistanceScale=5 s.ContinuouslyIncrementalGCWhileLevelsPendingPurge=0 s.ForceGCAfterLevelStreamedOut=0 s.LevelStreamingComponentsRegistrationGranularity=50 s.LevelStreamingComponentsUnregistrationGranularity=10 TimeOfDaySystem.AutoExposure.ExposureBias=-0.5 TimeOfDaySystem.AutoExposure.SpeedDown=5 TimeOfDaySystem.AutoExposure.SpeedUp=10 TimeOfDaySystem.BloomIntensity=0.17 TimeOfDaySystem.Clouds.HighAltitude.CloudDensityMult=0.3 TimeOfDaySystem.CloudShadowVolumetricResolutionScale=4 TimeofDaySystem.LegacyEmissiveAdjustments.EmissiveMultNonLamp=500 TimeOfDaySystem.SkyLightPollutionLuminance=1.0 TimeOfDaySystem.StarIntensity=50 TimeOfDaySystem.SunIntensity=50000 TimeOfDaySystem.VolumetricCloud.GroundContribution=1 TimeOfDaySystem.VolumetricCloud.LayerHeightScale=1.8 TimeOfDaySystem.VolumetricCloud.RayMarchedShadows=1 My Rig: AMD Ryzen 9 5900X 12-Core CPU; ASUS Cross Hair VIII Formula Mobo; Win 11 Pro (64 bit); 32GB RAM; 2TB Corsair Force Series MP600 Pro 2TB PCIe Gen 4.0 M.2 NVMe SSD. 1TB SAMSUNG 960 EVO M.2 NVME SSD; MSI GeForce RTX 3090 VENTUS 3X 24G OC; Dell G-Sync 144Hz Monitor.
geloxo Your advice will simply be ignored. I can assure you of that. Optimising or upgrading to UE5 would cost money, which Dovetail does not seem to wish to spend on investing in bringing TSW up to todays standards. Cheapskates basically, trying to sqeeze as much money as they can out of users without spending money on keeping the game properly up-to-date quality wise. Users and advice from users be damned.
I´m using just the same I posted 2 years ago, so you can take it from that post. For sure there are newer versions published here that include other settings. All you need to do to improve game performance and reduce hitching is indeed just the opposite to what deverlopers did: - Use DX12 - Increase viewdistances - Use higher detail LODs - Increase memory pools - Reduce frame times - Increase garbage collector frequency - Load as much assets as you can per frame instead of split that in several frames There´s a problem when streaming, tile loading and garbage collection happen at the same time (in the same frame) because the thread is very slow to resolve tasks in short time due to all those artificial delays. Therefore thread hangs until each frame loop reads all pending workload instructions and you see a short freeze. In dense areas that is repeated every few meters resulting in several freezes lasting up to 1 second and repeated during several seconds in a row. A fast system will still have to wait the same amount of time per frame as a slow system, that´s why this is not a good global solution at all. So in plain words game works better when it has as much assests as possible loaded in memory in advance and per frame. The way to force that is to increase details and viewdistance so that more scenery and trains are loaded at higher detail earlier in time and only map tile loading is happening cyclically (typically every kilometer). That way you just get a 0.1 second short freeze every minute or some seconds (depending on train speed) instead of the current insane amount of constant short freezes. VRAM usage will increase to values in the 10 GB range after some minutes so this may be a problem for people trying to run game on a smartphone maybe, but not for a modern system on 2023-2024. Memory usage can be still purged by using garbage collection every few minutes and workload can be still levered on slower systems tuning viewdistance, object LODs and the rest of graphical options as it has been done for decades in all games. One of the most effective and well known ways to reduce hitching in general is using DX12 PSOs as it reduces CPU calls allowing you to handle several objects in batches. That´s why DX12 works better. It´s incredible that game is still using DX11. Game thread implementation has to be the most effective one instead of including workarounds to deal with slower systems limitations because slower systems can still tune graphical options to deal with those limitations. That way game will always behave better as soon as HW evolves instead of being stuck in the performance figures from years ago even if HW is upgraded. This is the same mistake as in Microsoft Flight Simulator case when implementing a solution for consoles led to fast PC systems not performing as fast as they could do and having degraded performance and a graphical quality degradation. The additional problem in our case is that Unreal default parameters are meant to deal with very small workloads, memory usage and amounts of objects per frame. You can´t simply use them because that will be a disaster. They are ok for a small application or an Android game, but not for the TSW4 requirements and its modern routes and trains, specially if they pretend to increase the graphical load on it. Cheers
Mine is an I9-12900KF with a 3080 card and M2 SSD - using -DX12 and the most beefed up version of Jetwash's engine.ini tweaks I'm running in 4K on ultra and good FPS, very few stutters (even on first runs).
It would also take very long to move to ue5 if players want all their dlc to move across. The other option is to start from square 1 and lose your collection. Although moving to ue5 won't solve all the problems.
It won't solve all problems but it would solve several. At some point the UE will have to be updated as 4 is now becoming outdated and its functionality limited compared to 5.
To be honest I don´t expect TSW is moved to Unreal 5 in short time, if ever moved at all... UE4 + DX12 + optimal project settings is just what we need for the time being and that´s indeed possible in short time. If there´s an engine including tons of documentation and a large knowledge base that´s Unreal. Cheers
Uggh.. all these configuration settings gives me old FSX vibes where you'd scour all kinds of sites just to get bits and pieces of information to endlessly configure the sim to run smoothly on your system.
I wouldn´t get a new system just for TSW. Get it when you need it for other games as well because it´s too old. Any modern PC for sure helps, as the brute force approach sooner or later will result in higher fps and faster loading times, but there are other factors to consider for a game to perform well and there is where current technical limitations in the engine basically result in the same behaviour for everybody unless they are fixed. That´s why it´s important that devs take this seriously, unify the project configuration in updated data sets optimized for noways consoles and PCs (even one per platform if needed) and perform the tests so that this results in stable configs that help game to perform as it can really perform, because it can indeed do it very well in many situations with the proper tuning even on low and mid range systems. For the time being there are also some intermediate solutions before investing on a complete new system, like getting a G-sync or Freesync monitor if your GPU supports that. That will remove the stuttering caused by the changing FPS if you are frequently having problems to stay at a given FPS target (for instance you can achieve 60 fps in some cases but in others you go down to 45 fps). Tile loading hitching will be still there but it can be mitigated with some of the posted tweaks but you will have a smooth rendering while being in the min-max Hz ranges supported by the monitor. Be aware that some monitors are not full range and there will be a min fps value (min Hz) for this feature to work. Cheers
so im on a 3060 gigabyte i7 11700k 11th gen and have 64gb Ram Fury DDR-4 sticks and using them settings i livestream with Obs studio and find the frame rate was 20fps worse off now on TSW4 then it was on TSW3 with the settings so not happy but if u can reply here with them setting listed ill see if they are the same as yours as i think they mite be from someone else who tweet it
Please consider that game is still pre-release and new routes may have more details than older ones. I just tested a couple of routes only so I´m even tuning my own settings. First post contains the link to my original proposed settings for TSW2. That´s what I currently use. Wait until you can have access to the DLC collection to test the old settings with old routes too. It´s the same engine but now it gets additional workload that it didn´t have before because they added some new features. That´s the problem. Weather and light conditions also matter and may have an impact on your performance. However you can still tweak viewdistance. Don´t go too agressive with it as that´s one of the main drivers to make performance worse, even if high values help to reduce tile loading hitching. Cheers
As JD said, improvement should increase on second run of a route. Where is the cache located on Windows? (I have disabled Shader caching in Steam, as it is for OpenGL/Vulcan only)
Cache for Nvidia case is here: \AppData\Local\NVIDIA\DXCache That solves only the problem of first time shaders compilation, not the general hitching game will still reproduce after shaders are already compiled. Cheers
Genuinely I’m finding it to be way way smoother than TSW3 was. The fact is that this game stutters like hell in DX11 but doesn’t in DX12. I’m barely getting stutters on the first run.
Save yourself the trouble and don't. I went from a Rx480 to a 2080ti and the stutters are still there. Sure, you can crank the graphics a bit more and you will get higher frames in busy areas and so on but the stutters will still be there...
On what kind of drive is your OS installed? HDD or SSD? When I had a 2070 Super I had very few stutters and with .ini tweaks (mostly a lot higher drawdistances)
Improvement due to shaders being used again doesn't mean they can't gain (a lot more) "free" resources by optimising UE4 to enable higher settings. There is no reason to have such bad scaling on a recent PC and PS5.
Never disagreed on that, but the first run freezes are noticeable, and disappear on second run. Still microstutters, but as the engine is the same I wouldn't have expected that to be any different from TSW3. Nevertheless, apart from the microstutters, runs smoothly at 75 FPS on my system, running from a dedicated SSD. Haven't checked DX12, so will see if that makes a difference.
As DX12 cache appears to be not enabled in default config you can try experimenting a bit. Pipeline cache has three operating modes: - Priority: used to compile new elements on demand at highest priority (used while playing) - Fast: used to pre-compile new elements on high priority (used during loading screens) - Background: used to pre-compile new elements on low priority (used while game menus are visible) The following lines are needed to enable DX12 cache and will create new files on "\Documents\My Games\TrainSimWorld4": r.ShaderPipelineCache.Enabled=1 D3D12.PSO.DiskCache=1 D3D12.PSO.DriverOptimizedDiskCache=1 The following blocks are optional and can be used to tune the pipeline cache settings. To limit the times dedicated per frame for cache operations: r.ShaderPipelineCache.BatchTime=1 r.ShaderPipelineCache.PrecompileBatchTime=1 r.ShaderPipelineCache.BackgroundBatchTime=1 To define the batch sizes (how many elements to cache in one go): r.ShaderPipelineCache.BatchSize=10 r.ShaderPipelineCache.PrecompileBatchSize=10 r.ShaderPipelineCache.BackgroundBatchSize=10 From the optional blocks the relevant variables are the first ones (BatchTime and BatchSize) as they control de highest priority compilation of new elements during gameplay. Once they are cached (no matter if they were created during gameplay, loading screens or at the menus) they can be reused during next game runs. As well as in the regular shaders cache case the first run will take more efforts to generate them and you may see some short freezes but in general DX12 players should see a relevant benefit after caching elements as they don´t need to be compiled constantly. Other settings you may want to test are: r.CreateShadersOnLoad=1 (compiles shaders during loading but uses more memory) niagara.CreateShadersOnLoad=1 (same as above but for particle emiters shaders) r.ForceAllCoresForShaderCompiling=1 (use all CPU cores to compile shaders but uses more memory) r.Shaders.FastMath=1 (use optimized calculations for shaders) r.Shaders.Optimize=1 (use optimized shaders) I think some of them are already set in default values but I can´t check that now, so some may not be really needed. I put them just in case. I´m still testing the batch times and batch sizes values so I decided to start with low frame times and small sizes to get the less possible impact on performance per frame. Please take into account that new cache files may grow so for the time being consider those features experimental only and monitor them before including them in your settings. I think they were included in Unreal as part of a future improvement and may not be yet complete or even included in game core project. I just made a test on the british high speed route adding those settings to my original settings pack, after having deleted all previous cache files and shaders to start from a clean situation. I run for just 5 miles to let caches generate and then quit game and repeat test. That resulted in virtually no regular tile loading hitching even at 125 mph, so very few and much shorter microfreezes. The dense areas still take several frames to be loaded and there are still some noticeable freezes but overall result is promissing. Can anyone tell me if there´s any new tool to read current variables? I used Unreal Console Unlocker in the past but it seems to crash game now. It would be good to know which are the default values currently used. I have been out for a quite long time... Cheers
------ Your settings: r.ShaderPipelineCache.BatchTime=1 r.ShaderPipelineCache.PrecompileBatchTime=1 r.ShaderPipelineCache.BackgroundBatchTime=1 r.ShaderPipelineCache.BatchSize=10 r.ShaderPipelineCache.PrecompileBatchSize=10 r.ShaderPipelineCache.BackgroundBatchSize=10 r.CreateShadersOnLoad=1 niagara.CreateShadersOnLoad=1 r.ForceAllCoresForShaderCompiling=1 r.Shaders.FastMath=1 r.Shaders.Optimize=1 ------ Default Settings: r.ShaderPipelineCache.BatchTime=16 r.ShaderPipelineCache.PrecompileBatchTime=0 r.ShaderPipelineCache.BackgroundBatchTime=0 r.ShaderPipelineCache.BatchSize=50 r.ShaderPipelineCache.PrecompileBatchSize=50 r.ShaderPipelineCache.BackgroundBatchSize=1 r.CreateShadersOnLoad=1 niagara.CreateShadersOnLoad=0 r.ForceAllCoresForShaderCompiling=0 r.Shaders.FastMath=1 r.Shaders.Optimize=1 PSO cache is disabled by default (obviously )
As I said before, I hardly have stutters and mostly when compiling shaders. Believe me, i'm the first to complain on issues, but this aint one of them for me.
Cool for you, I guess. This isn't something new though and it is present in DTGs own footage. This game simply is as primitive as OMSI is. I just did a run, none of my hardware went above 80% and my GPU sits at 40C, my 99 percentile was... well, I'm not allowed to state what it was on this forum...
It's far from being as primitive as OMSI is, but then again it's not their primary focus. TSW is not optimised as it could be, that's true. But a lot of problems also come from users systems. Some have soo much LOVE loaded that it's not even funny.
I'm using one of the newer patreon only builds of the Unreal Unlocker and it seems to work fine, must be some improvements made over the free version that makes it more reliable.
The issue is present on consoles which are a closed system dedicated to gaming. Therefore it is universal. As geloxo mentions above, there could be some settings that DTG should have played with before sending TSW3/4 out the door that may have helped the user experience on all platforms. PC users are just lucky that they can tweak their ini settings (amongst other things) to make the game run acceptably.
Hyperbolic, but not far from, with the tile loading LOVE middrive. I can have 10 Edge tabs open including Youtube videos, Photoshop and lots of other programs open and still maintain a stable 3-digit framerate in most games I throw at this, except TSW, in fact it doesn't make any difference, GPU usage doesn't get affected by background tasks anyway, of course proper programs being an exception.
I could only imagine how painful it is on console, .ini tweaks help a lot. But still, I thought it was a thing of the past, having to tweak a game for hours, just to make the game run acceptably. But hey, at least we got fog now...
Agreed. Reminds me of a funny pie chart "Flight Simulation: A Comprehensive Analysis" posted years ago. It was made in jest, but oddly accurate how much time was actually spent flying vs. time spent configuring and changing things to make the sim look and run well. Was very thankful and relieved when the latest Microsoft Flight Simulator showed up and the days of playing with config files were a thing of the past.
Good news guys, in particular for DX12 and relatively powerful machines. I found a new way to reduce latency, hitching and also improve a bit the first time generation of shaders in new routes, so it should be less disturbing now due to the overall hitching reduction and optimizations on the game threads. The configuration data set included below is temporary until game official release comes out, in case they change something. It´s based on my former data for TSW2, adjusted for my current PC specs. Once data set is stable I may create a separate topic to explain it properly so that users can tune it for their needs. Anyway main parameters were already explained in my old post as well as in Unreal documentation. System specs: i9-12900ks Nvidia 4090 64 GB RAM DDR5 6400MHz NVMe disks Windows 11 G-sync monitor 3840x1600 (+150% scaling in game) Overall performance figures after tweaks during regular gameplay: No stuttering caused by changing fps due to usage of G-sync monitor Less than 0.1s hitching and less frequent hitching points (mainly at some heavy tile loading events only) 60 stable fps at stations (e.g: Riesa and Dresden) 40-50 variable fps during heavy tiles loading --> some routes still have such "black points" with high scenery density (e.g: arrival to Dresden) +70 stable fps on regular tiles in main line (e.g: ECML) Around 10 GB VRAM usage Around 15 GB RAM usage 100% GPU usage Less than 30% CPU total usage Original configuration main problems to address: Unstable fps Excessive delays per frame Excessive garbage collector usage Hitching during tile loading Hitching during first time shaders generation Hitching caused by LOD and texture Mips changes Methods to improve them: Use RHI sync method (as clearly indicated by Unreal docs) Reduce frame times to 1 ms Remove game thread waiting time on sync with render thread Balance parallel list sent from render thread to RHI thread (ignoring the previous frames results) Use all CPU cores for shaders generation Generate shaders on load Enable DX12 cache Disable DX12 cache pre-compilation as it´s not useful at menus or loading screens (requires proper definitions at game project) Increase quality to force less LODs and texture Mips transitions in the shorter distances to player, while still using texture streaming to balance performance workload on the short/medium/far distances Cheers
The current test set is the following (updated after TW4 public release): Important note: this data set requires the addition of -DX12 option to game launch options and it´s optimized for DX12 only. Settings are still valid for DX11 users but performance results may change. If you use DX11 variables starting with D3D12 should be removed as they have no effect on DX11. Blue - threads, performance and shaders (basic required set - common and DX12 specific tweaks) Black - garbage collector and level streaming (basic required set - common tweaks) Red - streaming, VRAM and shadows cache (optional - configure quality according to your system) Green - graphical quality, shadows and lights (optional - configure quality according to your system) Pink - sounds (optional - configure according to your own preferences) Add the following blocks to Engine.ini file. They are the basic required sets you need to use: [SystemSettings] r.GTSyncType=1 r.OneFrameThreadLag=1 g.TimeToBlockOnRenderFence=0 r.RHICmdBalanceParallelLists=1 D3D12.MaximumFrameLatency=0 s.IoDispatcherCacheSizeMB=2048 s.IoDispatcherBufferMemoryMB=512 s.IoDispatcherBufferSizeKB=32 s.IoDispatcherDecompressionWorkerCount=5 au.MaxConcurrentStreams=5 au.DisableParallelSourceProcessing=0 AudioCommand.FenceWaitTimeMs=0 AudioThread.BatchAsyncBatchSize=10 r.CreateShadersOnLoad=1 fx.ForceCompileOnLoad=1 niagara.CreateShadersOnLoad=1 r.D3D.ForceDXC=1 r.Shaders.FastMath=0 D3D12.PSO.DiskCache=1 --> Limited efficiency. Remove to release workload (see notes below) D3D12.PSO.DriverOptimizedDiskCache=1 --> Works well. Can be included (see notes below) r.ShaderPipelineCache.PreOptimizeEnabled=1 r.ShaderPipelineCache.BatchTime=2 r.ShaderPipelineCache.PrecompileBatchTime=2 r.ShaderPipelineCache.BackgroundBatchTime=0 r.ShaderPipelineCache.BatchSize=100 r.ShaderPipelineCache.PrecompileBatchSize=100 r.ShaderPipelineCache.BackgroundBatchSize=0 gc.TimeBetweenPurgingPendingKillObjects=300 gc.NumRetriesBeforeForcingGC=0 gc.MinDesiredObjectsPerSubTask=25 s.ForceGCAfterLevelStreamedOut=0 s.ContinuouslyIncrementalGCWhileLevelsPendingPurge=0 s.AsyncLoadingUseFullTimeLimit=1 s.AsyncLoadingTimeLimit=2 s.PriorityAsyncLoadingExtraTime=1 s.UnregisterComponentsTimeLimit=2 s.LevelStreamingActorsUpdateTimeLimit=2 s.PriorityLevelStreamingActorsUpdateExtraTime=1 s.LevelStreamingComponentsUnregistrationGranularity=100 s.LevelStreamingComponentsRegistrationGranularity=100 r.Streaming.NumStaticComponentsProcessedPerFrame=200 The next blocks are optional but still recommended. They are mainly intended to improve quality but some help performance as well (e.g: streaming caches). Read the guidelines below to understand what you need to consider for your system: r.Streaming.FramesForFullUpdate=2 r.Streaming.Boost=3 r.Streaming.HLODStrategy=2 r.Streaming.PoolSize=18432 r.Streaming.MaxTempMemoryAllowed=12288 r.Shadow.WholeSceneShadowCacheMb=4096 D3D12.ZeroBufferSizeInMB=32 r.ViewDistanceScale=4 foliage.LODDistanceScale=5 grass.densityScale=2 r.SkeletalMeshLODBias=-3 r.StaticMeshLODDistanceScale=0.1 r.HLOD.DistanceOverrideScale=6 r.DFDistanceScale=8 r.DFFarTransitionScale=0.05 r.Shadow.MaxCSMResolution=4096 r.Shadow.CSM.TransitionScale=2 r.Shadow.CSMShadowDistanceFadeoutMultiplier=0.05 r.Shadow.MaxResolution=4096 r.Shadow.DistanceScale=2 r.Shadow.TransitionScale=2 r.Shadow.RadiusThreshold=0.005 r.LightMaxDrawDistanceScale=10 r.MinScreenRadiusForLights=0.005 au.Concurrency.MinVolumeScale=0.00001 au.SoundDistanceOptimizationLength=0.5 au.VirtualLoops.PerfDistance=500 au.VirtualLoops.UpdateRate.Max=1 au.VirtualLoops.UpdateRate.Min=0.5 You can also modify the following variables on GameUserSettings.ini file: SFXSoundVolume=1.5 (it will increase train and main sounds to 150% volume) AmbienceSoundVolume=2.5 (it will increase ambient sounds to 250% volume) This allows to configure sounds beyond 100% so that they are better noticeable in game. Please note that this is a different configuration file and those variables already exist there. This change, as well as the previous sounds variables, is still optional. I assume you have master game volume set at 100%. Tune those volumes in accordance to your own preferences. Any change in volumes via game menu sliders later on will override those changes and they should be pasted in the file again. Very important: don´t change default variable AudioQualityLevel=0. It´s already set to the max possible sound quality and amount of sound channels and will also enable surround speakers. Increasing it to 1, 2, 3, etc will NOT increase sound quality, as wrongly proposed at many forums and posts, but will force game to initialize using any of the lower quality presets instead and disable surround speakers. Presets are pre-defined at game project and can only be changed there. Forcing a lower quality preset will result in some train/cabview sounds not to be played or ambient sounds to prevail over player train sounds. To tune those sounds separatelly you shoud just modify their volumes as described in the pink lines above. Customization guidelines for other systems Basic adjustments for your particular systems in case you have a less powerful machine or you see any impact on performance: The blue and black portions are the absolute minimums you need to include to see any performance improvements. The rest of the config portions are optional and if you decide to use them they will need to be adjusted according to your system to balance quality vs performance Lock FPS in game to a value your system can handle in case you are not using G-sync D3D12.MaximumFrameLatency is optional and limits queued frames (default value is 3). This setting helps with G-sync. Change VRAM pool sizes for texture streaming as they are intended for my 24GB card Set original Streaming.Boost=2 (current one will increase textures quality by 1 additional Mip) Enable partial HLOD texture streaming (r.Streaming.HLODStrategy=1) Use viewdistance scale 2 or lower to lever the overall sceney render distance Reduce SkeletalMesh to -2 or -1 when displaying too many trains (current value increases the quality of trains to reduce LOD/texture transitions) Reduce StaticMeshLOD to values higher than 0.25 (current value increases the quality of buildings and static objects to reduce LOD/texture transitions) Reduce r.HLOD.DistanceOverrideScale to values closer to 1 Reduce foliage viewdistance scale (current values increase the quality of vegetation to reduce LOD/texture and shadows transitions when too many trees are present) Reduce grass density scale (current value only increases density not quality and it´s not needed for optimiazations) r.LightMaxDrawDistanceScale and r.MinScreenRadiusForLights are optional. First one increases locomotive headlights distance a bit (10 is the max effective value in most cases). The second on prevents too small lights to be omitted from rendering, which is usefull to fully display distant building or platform lights for instance Tune shadows according to your own preferences or add other graphical enhancements you have Important notes If you experience frequent crashes to desktop do to memory access violations check that you have set a big enough virtual memory pagefile in Windows, or just leave it in auto D3D variables are related to DirectX. In particular D3D12 variables are only valid for DX12 mode r.D3D.ForceDXC=1 will force the DirectX shaders compiler instead of default one. This will generate shaders that are only compatible with DX12. Don´t use this option if you plan to use DX11 or change between both modes. It's advised to delete existing shaders before enabling this option for the first time, or when changing shaders related settings, to clear old shaders garbage. Compiler will anyway create the required files again if they are missing DX12 PSO is not yet fully set in game, which limits the efficiency of those parameters. This feature is only available on DX12 mode. Anyway GPU drivers can still generate their own user cache (managed by GPU drivers directly) and this is working even if PSO is not implemented in game. It will create and update cache files at "\Documents\My Games\TrainSimWorld4\Saved". GPU will attempt to collect and save any missing PSOs to those local user cache files on demand, and later on game could load those user cache files on start, and even merge their contents with the files eventually shipped with game when PSOs are fully implemented on a later stage. Take into account that generation of a single new PSO on demand can take up to 100ms in some systems according to Unreal docs, so don´t increase batch sizes too much if you still notice too much hitching when using PSOs. As currently there´s no need to keep both DX12 PSO user cache files I recommend to include in config only the variable D3D12.PSO.DriverOptimizedDiskCache so that we can prevent some unnecesary extra workload but still help performance under DX12. First time generation of shaders will still result in frequent hitching. That´s the normal behaviour in any game that uses shaders creation on demand and will happen anytime you play new routes or content for the first time. Newly generated shaders won´t have any effect until you reload the route and they are loaded again. However in the particular case of DX12 PSO user cache, files are only partially updated after playing new content for the first time, so reloading route is not enough and you will need to close game for cache files to be fully updated. This would only happen during first time generations of cache content, so closing game is not always required Take into account that generation of a relevant portion of the needed shaders can take up to 15 min in a regular route, as they are generated at intervals instead all together in one go. However some shaders are still generated short after loading so you can also spawn as passenser at several locations along the route to avoid starting from a situation with no shaders existing at all and then drive a service or travel as passenger on the whole route once to make sure most of the required shaders are generated. That first run will benefit from the existing shaders you created while spawning on foot before Even after a full first run on a new route some additional shaders may be still generated on demand during the following runs, in particular to cover other sections or branches of the route not used during the first run. Stored shaders, as well as any cache in general, are meant to improve performance over the time, although benefits will start to be noticeable after a relevant amount of the needed shaders or files are already stored on your disk In case you face out of memory crashes or high memory usages reduce the VRAM pool sizes to better match your GPU available memory or reduce garbage collector frequency below 300 seconds In case you see a huge performance drop at sunrise/sunset you may need to either reduce shadows resolution or the amount of cascaded shadows (r.Shadow.CSM.MaxCascades) to prevent it. This setting is not included in my pack and its default value is 10. The lower values will result in a noticeable shadow quality reduction in the close and mid distances. The performance drop effect appears to be caused by the new detailed trees which have very high details even on their lowest detail LODs. The vegetation quality, configured via foliage.LODDistanceScale variable, can have a significant performance impact in combination with high detail trees and shadows. Dense forests and tree groups inside cities can cast a big amount of detailed shadows to other objects near them, therefore values above foliage.LODDistanceScale=5 shouldn´t be used The variable r.Shadow.RadiusThreshold (min object size that can cast shadows) may cause shadows flickering in the event of when clouds edges, very small objects or smoke particles being between sun and player (e.g: Riesa "Special Delivery scenerio start). I included a very small value to improve shadows quality, but even default game value (0.03) reproduces this issue. In case you see the effect too frequently it´s advised to use r.Shadow.RadiusThreshold=0.05 or higher instead of my proposed value but that will also bring a significant shadows quality reduction as less smaller objects will be able to cast shadows Sound fading over distance is configured with au.Concurrency.MinVolumeScale and default value is already really low to maximize the distance for sounds to be audible. I reduced it even more but you will just gain very few extra distance. Most sounds will fade in game at around 200-300m for performance purposes as game can´t play an infinite amount of sounds at once If you want to reduce the frequency of looped ambient sounds you can au.VirtualLoops.PerfDistance=500 and the two variables below. They define at which additional distance from max audible distance of the sound game will start to check if player is nearby in advance to repeat the sound loop. Most sounds anyway will fade at less than 300m so this variable is already set to limit the amount of sounds to the map tile player currently is, which is still bigger than that In case you use the optional sound settings don´t change default variable AudioQualityLevel=0. Using other values like 1 or 2 will prevent some sounds to be reproduced or even surround speakers to work. This variable is used to initialize game using any of the sound presets already configured at game project Add other settings only if you are sure about what they do, as they could invalidate some of my proposed tweaks Relevant Unreal Engine references: https://docs.unrealengine.com/4.26/en-US/SharingAndReleasing/LowLatencyFrameSyncing/ https://docs.unrealengine.com/4.26/en-US/ProgrammingAndScripting/Rendering/ParallelRendering/ https://docs.unrealengine.com/4.26/en-US/SharingAndReleasing/PSOCaching/ https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/Textures/Streaming/Config/ Cheers
Something in those settings have resulted in some very lo-res textures on the locos, track and non-grass ground.
Thanks a ton geloxo. Works for me!!! My Rig: AMD Ryzen 9 5900X 12-Core CPU; ASUS Cross Hair VIII Formula Mobo; Win 11 Pro (64 bit); 32GB RAM; 2TB Corsair Force Series MP600 Pro 2TB PCIe Gen 4.0 M.2 NVMe SSD. 1TB SAMSUNG 960 EVO M.2 NVME SSD; MSI GeForce RTX 3090 VENTUS 3X 24G OC; Dell G-Sync 144Hz Monitor.
That´s most likely texture streaming related. Maybe r.Streaming.Boost=3 is too high in your case and system is not able to update so many high resolution textures in time. You can try two things, in the following order: - Use r.Streaming.FramesForFullUpdate=2 (texture updates are done in two frames instead of in one) - Use the old lower value r.Streaming.Boost=2 (will increase textures quality by 2 Mips only). Cheers
Funny that the stutters even occur when you're crawling along the line at 5 mph, or in FreeRoam with your train being the only one in the world. -> not the assets streaming ? -> not the physics What exactly happens in these moments? Have to say it's not unbearable on my system, but noticeable.
