Hello. I removed r.ForceAllCoresForShaderCompiling=1 from the config because I detected it was creating short freezes on some situations where other tasks are CPU intensive (e.g: texture and level streaming active as well as shaders compilation), even if global CPU usage is still not high. I detected it during some specific tests and then I noticed game´s default project settings are configured to use only a few CPU cores for shaders compilation and that task is also set to run on -1 priority. Therefore the variable is just making CPU less efficient as it books all cores for longer periods of times but task is still taking some time to complete. The booked frame time for shaders compilation is configured to 10ms in the project settings, which is in the range (and in many cases even worse) of the threads latency we can get with my optimized settings. Therefore we don´t want to add such a high frame latency for shaders compilation and use all cores at the same time with a task that takes so much to complete, as it can clearly delay the whole simulation during noticeable periods of time and invalidate many of the gains we had thanks to the other optimizations I added. Usage of that variable would be optimal in case default project settings are changed, so that compiler priority is set to normal or high and compilation could be then resolved faster, using only 1ms or 2ms per frame. As that can´t be changed via our standard variables configuration it´s better to remove that variable for the time being. If you already included in your configs please remove it. I also made some additional adjustments and now we should have a smoother first time shader generation and no freezes on CPU demanding scenarios. Cheers
foliage.LODDistanceScale=5. You can increase it but performance will start to drop on routes using the new detailed trees. Cheers
Im not a Unreal Expert in that level of detail, but after reading this, i would like to know why an entire simulator with known performance issues gets released with a not optimized code. 1. Did DTG simply not have the knowledge / werent not familiar enough with the engine? 2. Is it because the platform variety 3. (The DTG usual: lets release it for now and maybe update later..) My PC is now 14 years old. Back then when i built the rig, it was ultra high end. The asus p6t and the i7 3.65ghz processors are still original. I changed the ram to 64GB, replaced 2 drives with ssd, and upgraded the graphics. Also i did a service on the processors (new vents / thermal paste etc). Beside the usual stutters, TSW is running very smooth on very high settings (textures ultra, shadow medium and v sync off). I noticed the frequent small stutters occur in combination with rolling stock, which gets blurry somerimes. I think everybody saw that phenomen at least once. Like a loco in the distance is visible very blurry until you are basicly infront of it. (Doesnt happen always). Somehow my stutters occure when this phenomen with the blurry consists / wagons happen. Maybe a vehicle loading problem. Beside that its running very smooth. Some routes like rsd get a bit more stutters, than for example bro. Cant tell why, bro has more static stock on tracks. Anyway im planning now to build a new rig with Win10 (mine runs still with win7, which wont work anymore soon)
Those problems exist since TSW1 and have not been adressed efficiently because we basically have the same engine version and even same project settings since TSW2. I don´t mean there were no improvements but they were clearly not enough. Blurryness is caused by texture streaming. It adjusts texture resolution with distance to lower graphical load. Stuttering (hitching indeed) is mainly caused by level streaming (next map tile loading and previous map tile unloading) and is meant to lower memory load. Yes, game may be using the lowest possible HW resources and that may be one of the targets in the early years, but as a result it runs really bad in terms of performance nowadays, even in high end systems. Anyway both issues are addressed in my proposed configuration. In addition to this we now have the problem of real time shaders compilation that also generates extra hitching on first run with new routes/content, because game does not implement shaders compilation in advance (for instance during loading), even if that´s possible for Unreal, and they need to be compiled by users on demand as they travel along the routes. I mitigated this a bit in my config but that process is still resource hungry and has a noticeable impact. For that reason is should never be required on demand during gameplay, as everyone who is a bit familiar with games knows. However DTG has implemented some custom features on top of Unreal engine core and many are hardcoded, so we can´t change them easily. For that reason you can still see how empty tiles loading (details set to 0 so that nothing is visible) still generates hitching and moving AI trains inside a tile, where player is at standstill, still generates hitching too. That´s the same residual hitching and at the same places in each route you will notice even after using my config with max details and it happens on both DX11 and DX12, no matter the shaders type you use or if you use default settings or custom ones. I presume that´s caused by custom weather, AI trains dispatching, AI trains path finding or routes updating, which may be running either on a single thread (instead of async) or coexisting all together on a thread which is already under heavy load, containing a lot of frame latency or not being optimized so that some tasks create bottlenecks for the following as it happened with the core Unreal features I fixed. So it may be possible for DTG to take similar solutions for their hardcoded portion too, if that´s really what is causing the residual hitching, and eventually fix it. After my fixes Unreal threads are now running much better (even below 5ms latencies under DX12, which is a superb result) so they have extra room to eventually run DTG code if they wanted. But someone needs to take the time to analyze things, test them and tune them. Cheers
There is something in the following set of variable that make either the shaders really low quality or they take a very long time to load properly. Do you know which line it is? Thanks. r.Streaming.FramesForFullUpdate=2 r.Streaming.Boost=3 r.Streaming.HLODStrategy=2 r.Streaming.UseFixedPoolSize=1 r.Streaming.PoolSize=18432 r.Streaming.MaxTempMemoryAllowed=12288 r.Shadow.WholeSceneShadowCacheMb=4096 D3D12.ZeroBufferSizeInMB=32
The lines above deal with texture streaming, not with shaders. But you can try to reduce r.Streaming.Boost to 2, 1 or 0. This will reduce the overall textures quality as you reduce the value but will also release some workload on your GPU. That may be the reason behind your problem. Cheers
Thanks geloxo. Its definitley streamingboost that is causing it. I have a rtx 3080ti im not sure what the best setting to use is. It still does it when it is set to 2.
I had that card before and you can´t push it too much in this game, even if it´s a good card. Try reducing quality a bit, in particular the LODs and viewdistance settings. Stay with streaming boost 2 as below that the textures degradation is noticeable in my opinion. You can follow the guidelines at the end on my settings post to adjust quality settings. Cheers
that card has 12gb vram these numbers are too high r.Streaming.PoolSize=18432 r.Streaming.MaxTempMemoryAllowed=12288 try r.Streaming.PoolSize=10000 r.Streaming.MaxTempMemoryAllowed=5000 a nice manual by Jetwash about those values https://www.trainsimcommunity.com/m...ancement-version-32/f7333-tod4-manual-v11.pdf
Also double check that you have enabled a big enough virtual memory pagefile in Windows, or simply leave it on auto. Recent Windows update this week started to produce constant CTDs in my system when using DX12 mode. I had it originally disabled and even with 64GB RAM and 24GB RAM I had to set it back as in the early years of TSW2 as this is still needed to swap data. I have used 16GB for the time being. I added a note in my post for other users to be aware of that. Cheers
Well the excuse is that if they do use URE 5 that they will have to rebuild every route in TSW, but instead of releasing a new TSW why not spend that time doing that. Plus I thought TSW 4 was gonna be a big upgrade like URE 5, guard mode ETC. Edit: But this is the standard now 4 new game features, new game, but no core engine upgrade.
I’ve been using your settings geloxo (minus the ones in red - need to tweak for my 3080 first), and it has much improved things for me. I probably should do a little bit more tweaking in general to suit my card a bit better. On a side note, the WRC game is in early access, and looks like there’s a lot of UE stuttering issues happening there.
Unreal 5 is reported as still reproducing hitching, which is not good at all as it was supposed to address this issue. To make things worse today Nvidia released the third driver in a row during this month, so all shaders for all routes need to be generated in real time again. Puff... Cheers
I have to say, I’m not seeing any noticeable hitching at all on any route with DX12. DX11 is a dogs dinner though
Agreed, even on vanilla Engine.ini DX12 makes a huge difference and after a first full run I don't have noticeable stutter any more. Probably users with a magnetic hard disk can experience troubles if the shader cache is fragmented?
That’s a good point, but then surely people aren’t sim gaming (or any gaming for that matter) on an HDD these days are they? If so then it goes without saying that it ain’t the game’s fault! No amount of tweaking settings is going to overcome the laws of physics. FWIW I’m seeing virtually nothing on first run through either. Sorry to the ‘that’ guy.
I adjusted settings during this week but there´s still some. In particular there are some cases that produce hitching, and it´s not caused by tile loading nor texture streaming, so you can notice them while being stopped or when streaming is disabled: AI cars moving inside a tile can reproduce hitching while moving trains inside that tile don´t produce it (you can clearly notice it on cars travelling across bridges when you drive under the bridge) AI trains moving inside player´s tile can reproduce hitching even if player is stopped and camera is also stopped, so when no new scenery is being streamed in or out, neither due to camera angle changes nor due to player movements Mouse movents to relocate free camera can produce hitching when just adjusting very small camera angles Moving free camera along a platform can produce hitching, when no significant streaming should happen there do to the small size of the 3D objects/textures used at platform areas and because you are still in the same tile so everything is already on memory. Indeed at so close distance everything is already loaded at max LOD and texture Mip too. The problem is more complex that it initially appeared to be and may be propagating to other core features, not only to rendering. Those cases can be also reproduced on default settings and DX11. The clearing of the other rendering and sound related hitching is what just revealed them to me. I really think DTG needs to take a look to this, just in case, to be sure no development or debug option was left active by mistake in the latest public build or any of their custom processes is eating more frame time/cpu than it should. Whatever is causing this is adding a lot of extra latency and causing relevant fps drops, as if something heavy or single threaded was running on every single frame or few frames. You can see how fps don´t stop to oscilate like crazy at Trenton station for instance, even if you are just alone in the tile and shaders were already generated. That shouldn´t happen as scenery rendering is basically static and fps maybe could change by 1 or 2 fps in such case due to small animations and ambient sound. Sun changes every few seconds only but this alone is not justifying 10 fps drops on every frame, even despite of the required light/shadows updates. However you can get high fps there, which confuses me a bit. So the other portions of the main processes seem to be running optimally in the threads as you can still reach the high fps peak. Cheers
I’m only using the ones in the lighting mod but am literally seeing next to zero hitching or pausing. There is a tiny tiny bit on first run through but only on a couple (again, literally) of routes.
1. For me (GTX 1660 Ti) and my boyfriend's (GTX 1070 Ti) PC, setting TOD4's Volumetric Cloud Render Target Mode to 0 (which is 1 by default) boosts performance A LOT in lightly cloudy to very cloudy weather with only slight quality differences (almost unnoticeable). 2. Please do not touch variables that contain GC (garbage collection), or anything to do with memory, pipelines and loading/caching, unless you really know what they are, what they do and how they affect the game and it's performance, because this can REALLY affect performance more or flat out make your game crash or unplayable.
I posted this in a similar thread but I just wanted to add it here, too. I’m a little late to the party here but I can’t recommend this mod enough. I have virtually no stutters now. It is silky smooth running with everything set on ultra pretty much. And the graphics look lightyears better now. Funny how TSW4 runs so much better with these settings vs. a vanilla game right out of the box. Again, I can’t recommend this enough. Awesome job! Thank you so much.
I don't believe I've EVER made it through all my Routes before nVidia changes drivers again. And that does not sound good on UE5. PC/Steam/Ryzen7/RTX3060
I mean, you don’t have to update every time Nvidia release an update. If you have a driver that is working well for you then stick with it. Personally, I’d only update if there was a notified improvement to a game I played or a strongly recommended security patch.
I'm making use of your settings, having toned them down a bit for my PC, but I'm finding on some routes such as Vorarlberg that I'm getting a bit of an FPS drop when there's multiple Talent units in the area. What settings most effect the FPS with trains in the area, and what's the lowest you'd recommend without noticeable issues?
I've tried r.Shadow.CSM.MaxCascades=5 and I don't see any changes in visuals(maybe a little bit transperent shadows, or maybe it's just my immagination) and no changes in performance. Is there any other methods to optimize massive drops at forest areas at sunrise/sunset(except waiting for a miracle from DTG, which will never happen)?
I’ve been working like crazy (way too hard if I’m honest) at this very issue for v3.3 of my lighting/graphics overhaul and think I’ve found an acceptable solution. It’s never going to be perfect as there is clearly something awry with the way the game is set up, in that the swing in performance between all other times of day and dawn/dusk is absolutely ridiculous. I believe Gelaxo is absolutely correct, in that the foliage is casting detailed cascaded shadows way earlier than it needs to and this is exacerbated hugely when the sun is low in the sky. I’ve also found that all the DLC seem to have different shadow setups, and what works just fine on one route looks damn awful on another. I’ve spent a long time tuning these settings on a route-by-route basis to hit an acceptable balance between performance and quality. I’m aiming to get v3.3 out not long after Blackpool-Preston is released. One thing I have done, I’m afraid to say, is remove all these streaming and garbage collection tweaks from my files. There are many of them floating around the net and no matter what I did I was finding I was having issues that I just couldn’t get rid of. Removing the changes solved the problems. I was also surprised to find no difference of any description in performance and the game is just as smooth without the streaming parameters as it is with them. I’ve had others test this too and they’re finding the same thing so even though I can’t speak for DX11, with DX12 I believe they’re simply not required. I have retained Gelaxo’s suggested fastmath and DX12 shader tweaks as these are definitely beneficial.
Sorry for the stupid question - where exactly a new .ini will be posted? Cause I'm using your config from the message on the first page of this topic and maybe it's outdated and whole party is elsewhere.
It’ll be on Train Sim Community. v3.2 is currently available there. v3.3 has quite a significant number of changes and I hope (really hope) it’s a noticeable improvement. It’ll also have something that I think is really cool that Foobian has very kindly added to GodMode for me.
Those supposed "tweaks" on garbage collection and memory management were always unnecessary and more harmful overall than just leaving it as it is if you have no knowledge whatsoever about memory management in general and UEs memory management
I don't use any of these. Tweaked the LOD distances plus running in DX12 is doing it for me, I'm also a bit skeptical about the other tweaks and feel better leaving them on defaults.
I concur, any "r.streaming..." settings were burning up my RTX3060 without any noticeable benefit. Removing them actually improved things.
The final thing to do is always to sort out what you actually do not need. Don't get me wrong, this thread is brilliant!
That’s exactly what I found too & I have to say, I think it’s all placebo. These (or similar) settings are listed for a number of UE4 games all over the net as magic bullet improvements and I’d blindly trusted there must be some worth in them given the case is made so strongly. It’s not the case and as you say, they were causing unnecessary work for the GPU.
Shadows, shaders, and probably a lot of other UE elements as well. I had just got my shadow bubble out to an acceptable distance when Linke Rheinstrecke was released and there it was 50 meters in front of the train again.
I loaded up TSW4 last night since downloading the latest patch, and I think there is a noticeable improvement to the game without tweaking settings files (which I've never done, but admire the people here trying these things, figuring out what works). SEHS seemed far smoother after DTG's patch. I'll try some different routes, though...
Dresden and LGV are traditionally the most stuttery for me; I have not tried them yet but on several other Routes it seems noticeably smoother.
Just out of curiosity, when using these settings, specifically the all in one graphics mod tied in with God Mode, what is people’s hardware usage like? Mainly utilization and such. I use an RTX 2080 Super and while it may be a little outdated now with what’s been released since, it’s still a fantastic GPU and runs my main games (ATS, TSC, TSW4, and MSFS) extremely well. I’ve got an i9-9900K CPU @ 4.7GHz to go with it. I run my TSW4 settings (all of those games for that matter) at pretty much all ultra settings with a few on high settings and get around a constant 60fps plus. CPU utilization is 10-15% GPU utilization is 18-35% and around 80-86C Performance is flawless and silky smooth on DX12 with the mod.
So. I'm asking a question to the wizards. Has anyone considered that TSW is using a highly criticised and questionable DRM middleware called "Denuvo" which is reported to have impact on performance (Denuvo denies that but of course they say so). I've just read that there was a comparison between the retail and a cracked version, with the crack that removed Denuvo running noticeable better. I'm a bit appalled, I've purchased a game on Steam that has its own DRM and still it contains another DRM. Is the honest customer being punished? Is that the reason why NYT ran worse on PC than on Xbox? Thoughts?
I mean, part of the reason is the same reason MOST UE4 games run worse on PC than on XBox or PS5. Sackboy, Dead Space, Callisto, Jedi Survivor, Gears 5, with only a handful of outliers like Hi Fi Rush managing to nail smooth performance. It can be done, but clearly it takes actually anticipating it and doing something to prevent it. There are options. But yeah, speaking generally, Denuvo clearly doesn't help in that regard, as it introduces an extra layer of potential performance issues, regardless of the engine being used. Just like with UE4's internal issues, we know Denuvo impact CAN be mitigated, but again, the devs need to proactively work to accomplish that.
Just to clarify, game is using streaming features for several main purposes: progressive texture loading, progressive 3D meshes loading, progressive terrain loading and allow playing more than 32 sound sources simultaneously. The main reason why streaming is needed is because loading and keeping in memory full resolution textures is too expensive. On the other hand as engine can only play 32 sounds at a time most of the sounds need to be streamed, as in regular situations you need to play typically more than 100 at a time, including ambience ones. When tunning the streaming features you need to use the correct settings (see my guidelines notes) as most of the tweaks have an impact on RAM and VRAM usage, so not all settings are valid for all cards. Anyway DTG has implemented its own memory cleaning in TSW4, most likely to get rid of garbage collector problems too. For sure you can skip those tweaks, in particular if you see adverse results, and it´s fine to do so. Anyway main bottlenecks so far are the following: real time shaders compilation and assets loading from .pak files (affected by Denuvo protection). Until DTG solves those two main bottlenecks no further improvements are possible. Those two factors are going to limit everything else. This is just my personal opinion, which does not mean it´s the correct one. Cheers
Why the heck are they even using Denuvo for a Steam game? Stuff like that eventually backfires. If anyone still remembers the StarForce or SafeDisc LOVE users were forced onto their systems in the CD-ROM/DVD age (and they all got cracked, everyone's used their NoCD.exes). Punishing the paying customers while the ones using cracks had the better experience. I'll quote Gabe Newell (Steam): The easiest way to stop piracy is not by putting antipiracy technology to work. It's by giving those people a service that's better than what they're receiving from the pirates. So far I'm not aware of any performance issues with Steam's own DRM system. I do know how the system in TSC works, but I'm not sure if it was a co-development of DTG and Steam. Anyway it's not affecting performance, as it's happening on loading a scenario and decrypting GeoPcDx model vertex coordinates. Copying the keyfile won't help if the DLC is not associated to your Steam account. (Easy to see the effect by just removing an _.sbn file from TSC assets)
I remember one studio messing with pirates by having the game's guns fire chickens if it was detected as a pirated copy. Maybe DTG could go within the game for anti-piracy rather than going without to third-party software.
There's lots of alternatives. Denuvo is highly questionable - and I think it's the piece of code responsible for microstutters (not 1st run shader compilation stutters - that's ). They happen even if you just walk around, no matter if you're going 1mph or 200mph. I have more demanding games that do not show this effect (and do not use Denuvo), and I'm coming to believe it's not UE related at all. You can minimize the effect through various tweaks featured here - but there is something happening at runtime which just shouldn't be happening using clean code. DTG Matt Maybe you could consider alternatives. Denuvo might become a developer you do not want to be associated with sooner or later. It's already got a bad reputation as I see it. Why not use a system like in TSC, that's working on preprocess level?
That´s exactly my opinion as well. If it was Unreal related or frame related you would be able to see a difference with speed. Lower travelling speeds would mean more frames to process the same amount of work for a given time interval (1 second for instance), so you should therefore see an improvement at low speeds. On the other hand those microfreezes happen even inside an already loaded tile (for instance every few meters while walking along a platform) or a map where there´s no AI traffic (e.g: quick play). It´s clear that this is not caused by Unreal. Cheers
I think they know but they have made contracts. You can test it but I won't tell you how to in here. If DTG don't respond here, they're giving you the answer
