omsi 2 调校

Measure performance of Omsi 2 and tune it for a modern computer. Playing with the settings Omsi 2 is an open software; there are DLCs from many contributors: maps, busses, vehicles and pedestrians, some transverse DLCs (Navigation, Auxi). The Omsi 2 software proper hasn't changed in years, however other things do change: hardware, graphical card, drivers. Some recent maps are more dense than the first ones. The Options dialog has a lot of settings. There are advices on many guides, forums, Internet sites, but I still did not understand how to best tune Omsi 2. Sometimes I was unable to drive on a map although I managed to drive previously, without me knowing what changed. I have played with the settings while looking at the FPS but I could achieve no satisfactory tuning. Then I looked for a way to get relevant measures that help tune. Measuring Performance Important measures are: processor usage for both CPU and GPU, memory allocation for both CPU and GPU. Process Explorer[learn.microsoft.com] yields: Virtual Size: the memory of the process (counts against the 4Gb). I/O History: the data read from disk. CPU (Usage), and CPU History: the load of CPU processor (counts against 100%). GPU (Usage), and GPU System Bytes: the load of the GPU processor (counts against 100%), and the allocated video memory (counts against the available/configured video memory).https://steamuserimages-a.akamaihd.net/ugc/26561914309350845/789CF5CA19FAC94569C45B8229D1CFCC63B3614A/?imw=256&&ima=fit&impolicy=Letterbox&imcolor=%23000000&letterbox=false You also get information about video memory through Omsi 2's HUD (Shift+Y thrice) or DXVK's HUD. Virtual Memory Map[learn.microsoft.com] explains how the Virtual Memory is allocated: Image: the program code of Omsi 2; always allocated. Private Data: memory allocated for the execution. Heap: memory allocated for the maps; depends on the maps, the number of vehicles, etc.https://steamuserimages-a.akamaihd.net/ugc/26561914309355589/EB87FD29CC3256F52E4F83488E41092A8A632388/?imw=256&&ima=fit&impolicy=Letterbox&imcolor=%23000000&letterbox=false Major Points The CPU usage is high, 75-80% overall, 50-60% for Omsi.exe, which is as high as most old software can get (the reminder of the time is spent waiting on the memory or on the disk). This is the limiting factor, it will balance with the FPS. The GPU Usage is quite low (I see ~25% on 1 GPU Engine out of 20). The Virtual Size is often in the range 1.5Gb-2.5Gb, quite under the limit of 4Gb. The GPU Memory is often in the range 1.5Gb-3.0Gb (though I have seen it go up to 5.5Gb, which still works out if there are 8Gb of GPU Memory). When playing around with Omsi 2's settings one should check on which figures it has an effect. One will want to reduce the CPU Usage because it is close to its limit; increasing CPU or GPU Memory is fine because it is far below its limit. Other Settings The wording "Max. Tex. Mem. for high-res Tex load" sounds misleading to me: to me this figure behaves like the limit on GPU Memory, whatever the other settings about Texture Resolution are. The default setting for "Max. Tex. Mem. for high-res Tex load" / Video Memory is very low (at 401.0Mb); one should set it much higher: one finds various advices on Internet: to the available GPU Memory, such as 8Gb=8000.0Mb, or 0.0Mb (meaning "no limit"), or 2/3 of the graphical memory. If Omsi 2 reaches the limit (it can reach 400Mb even with low resolution textures), it gets trapped in a loop (the screen stays black, sometimes flashing to show the Windows Desktop (background image, or Steam); with Process Explorer one sees the GPU Memory repeatedly going slowly up and abruptly down). With "Use Only Low-Res Textures" the GPU Memory is much lower, the GPU Usage is somewhat lower and the FPS is somewhat higher, but I experience quite long freezes (and obviously the images are more blurred). Conclusion With the 4Gb patch, and with Omsi 2 configured to use 8Gb of video memory, I can drive correctly on almost all maps. The driving experience is better with high-resolution textures (i.e. without checking "Use Only Low-Res Textures" and "Limit all textures (apart from own bus) to 256 pixels"). Other Points The wording "Reduced Multithreading" sounds misleading to me. When I play with "Deactivate multithreading for test" / Ctrl+F12 (as described in the Options / Keyboard tab) and look at the HUD Information Lines (Shift+Y thrice) I understand that "Deactivate..." switches multithreading off at start up, and Ctrl+F12 toggles it on and off during the game. After a crash or a forced termination Omsi 2 opens a dialog suggesting that crashes could be related to an issue with multithreading; as far as could test Omsi 2 has no issue with multithreading; multithreading should always be active. I can't find a clear advice about "Neighbour Tiles Count" and "Max. Obj. Visibility Distance". I think that both figures should be tuned to the same or an similar distance: if "Neighbour Tiles Count"*300 (=size of a tile in m) is much less than "Max. Obj. Visibility Distance", then each time a tile gets loaded, Omsi 2 will display many new objects and their textures at once, which freezes the game for some time. If "Neighbour Tiles Count"*300 is much more than "Max. Obj. Visibility Distance", then many objects are in memory but they are not displayed. I tested DXVK (version 2.5; https://steamcommunity.com/sharedfiles/filedetails/?id=2461019058). It somehow works and yields better FPS, but it induces delays (the simulation freezes for several seconds). DXVK has a limit on memory (on my system, the limit is about 6.6Gb; I don't know if it is absolute, or related to the 8Gb GPU Memory available); setting dxvk.conf / d3d9.maxAvailableMemory higher has no effect. At first I had it crash every 5min (the screen turns totally black and I have to reboot). It seemed to crash mostly after DXVK's HUD shows a long freeze. With "Neighbour Tiles Count" = 3 it seems not to crash. However DXVK's HUD reports much more video memory used than Omsi 2's HUD (about a factor 2); in some places on some maps DXVK's HUD reports 6.6Gb (99%) memory usage, then the simulation freezes and I have to reboot.