Tutorials & help
In difference to most other games, the newest and most powerful graphics card will not help you much with the performance. Omsi needs a fast CPU, ideally a dual core or more, with at least 3GHz (for AMD, for Intel it might be a bit less). If you want to improve the performance, you need to improve the CPU usage. In Omsi the CPU does also prepare nearly the whole graphic, so that the graphics card is just there for the final rendering. That mean, that the amount of objects, as well as the amount of AI (cars, busses and humans) needs to be set according to the power of your CPU
If you get less than 7-10 FPS (frames-per-second), the physics-engine starts to glitch out and your bus starts to jump.
The "4GB Patch"
If you search for help for performance-problems you might often read “use the 4GB patch”, but for what reason? Omsi, as a 32bit application, cannot use more than 4GB of RAM. 2 of the 4GB are reserved for the System, so Omsi normally only can use 2GB RAM, but, within the exe, you can set a marking that allow 32bit application to use the whole 4GB.
This helps in Omsi with very big maps that require much RAM. This patch technically only helps you when you have problems with white textures.
Just the very important things:
Every time you stop the bus, Omsi saves the current Situation. This may cause a short freeze especially when your performance is already low. If it annoys you, and Omsi runs quite stable you can deactivate this here, but note that you manually need to save the situation when you close Omsi, otherwise you cannot continue at this point and can only start new situations.
- Reduced Multithreading
This option is more or less a leftover from the early Omsi 2 era, when the new Multithreading (means the usage of multiple CPU-cores) caused some problems. It decreases the performance quite heavily; if you do not have problems deactivate this option.
- Load whole map at start
Only use this if your PC has problems with loading new tiles. With this option, the loading time for new tiles is decreased, but your overall performance may also decrease a bit and big maps needs very much time to load. Very big maps could fail to load because auf the 32bit limitation of RAM usage.
- Target Framerate
Limits the maximum amount of FPS
- Neighbour Tiles Count
Amount of tiles in each direction. 1 means that 9 tiles are loaded, with 2 your get 25 tiles around you. This option has a quite big influence in performance. An interesting fact is that Omsi has a dynamic tile count reduction. More to this in Graphics (advanced).
- Max. Obj. Visibility Distance
Is the distance between you and an object bigger than the value (in meters), than it will not be shown. Reducing this value can improve the performance, is it too low you can see the object spawn in front of you and you might miss traffic signs an traffic lights.
- Min. Obj. Size (% Screensize)
Is an object smaller than this value, it will not be shown. This option is supposed to prevent too small object to be rendered. I have not much experience how big the influence on the performance is.
- ...for Reflexions
Is an object smaller than this value, his reflections will not be shown. The reflections are mostly just some textures, so this option should not be very important.
- Real Time Reflexions
-->None: The mirrors are deactivated
-->Economy: The mirrors are rendered in a lower frame rate if needed. Originally, it meant that the mirrors get rendered after each other, so with 3 mirrors every mirror would run at 1/3 the frame rate of the game, but (I think) version 1.6 not visible mirrors are not rendered anyways. That mean you can get the mirrors usually do not stutter that much in this setting
-->Full: Every visible mirror is rendered with the same frame rate like the game. I do not recommend this setting, since it can dramatically decrease the performance.
- Particle Systems
After my experience, they do not have a big influence on the performance, but they add some nice details. Particle systems are the exhausts from cars, busses and chimneys as same as the splash water on wet lanes. You should only chance the settings if the other settings did not helped enough. In this case start with reducing the “Max.Particles per Emitter”.
-->Only User Vehicle: Only your bus creates particle effects
-->No P.S. in Reflextions = No particle effects in mirrors
- Max Object Complexitiy
Means how much details are shown on the map. May have limited functionality with freeware content (because the priority of the object is set by the creator of the object). This option can help increase the performance or can help if you get white textures.
- Max. Map. Complexitiy
Sets, how far away from the main area objects are shown. Since the priorities are set in the Map editor by the creator, it may also have limited functionality. Decreasing this setting should improve the performance bit.
-->Shadows: Always deactivate this option. It costs much more performance than it improves the graphic. The shadows can reduce your frame rate down to a third or even a half .
-->Rain reflexions: Means wet streets. It adds a quite much to the graphic, only deactivate it if you have a big frame rate drop with wet streets.
-->Humans visible in rain reflections: I have no experience with this option, I never activated it. Try on your own.
- Forced Refl. Economy Mode
Only active if the real time reflections are set on “Full”. This option sets the real time reflections on economy when your frame rate drops below the upper value and set in to Full again when your framerate gets over the lower value. Setting both values to close together can cause big framerate fluctuations when omsi oscillate between both settings
- Dynamic Tile Count Reduction
That is a very useful option. It automatically reduces the neighbour tile count when your FPS drops below the upper value and increases it when your FPS goes over the lower value. With this, you can have a good framerate in the city and a good visual range on county site maps.
-->The two options can help with old graphics cars with little VRAM. The downside is that Omsi looks like a N64/Playstation 1 game with these Options activated.
-->Max. Tex. Mem. for high.res Tex load ( “Maximum Texture-Memory for high-resolution Textures”: It is said that you should set this value so that it is a bit less than the amount of your VRAM (but I am not sure if this is true because Omsi always fills my VRAM completely)
-->Real Time Reflections Texture Size: Means the resolution of the mirrors, f.e. 512 means the mirrors have a resolution of 512x512. A value between 256 to 512 is just fine, if you have a 4K display than probably 1024 is better. Never set this value to high (higher than you screen resolution), otherwise the mirrors glitch out and do not work.
Here most important: Max. Sound Count
A too small value leads to missing sounds, silent passengers etc. A too high value could decrease the performance, because the sounds need to be decoded by the CPU.
- Road Traffic Max. Count: Unscheduled
Sets how many Vehicles (Cars, Trucks ...) drive around on the map. This is one of the most important settings because the AI-Vehicles need much CPU-power. For a good performance, keep the value low. Here you need to find a good compromise between the amount of traffic around you and a good performance.
- Road traffic factor
Omsi has a daytime-dependent traffic-density, with this option you can influence the traffic-density. A lower value leads to a better performance, but also to emptier streets.
- Parked Cars
Omsi has fixed parking spaces. This value set how many of them are used. Parked cars are not as performing-decreasing as the driving cars, but they add to the amount of objects, which need to be rendered.
- Humans Max. Count
Sets how many Humans are on the map. It also limits the max. Amount of passengers you can have. They also need much CPU power (not as much as the Vehicles, but still quite much). For good performance, do not set this value to high.
- Factor Passengers at Stations
Depending on the daytime, more or less passengers wait for the bus. With this value you can take influence in this.
- Road Traffic Max. Count: Scheduled
Sets how many busses, trams, trains etc. drive around on the map. For a good performance keep this value low, at 10 or less.
- Schedule priority
Different bus-lines have different priorities. While the main bus-lines have a very high priority, other, AI-only lines, are less important. If you set this lower, you will see less and lesser other busses, trams, trains, etc. For a good variety keep this at 4 and reduce the “Road Traffic Max. Count: Scheduled” instead.
- Use reduced AI list
I am not sure if this option really has any advantage. Try for your own...
How to improve the Performance (summary of most important things)
- Reduce amount of neighbouring tiles (1-2)
- Deactivate the shadows
- Set Road Traffic Max. Count: Unscheduled below 100
- Set Road Traffic Max. Count: Scheduled below 10
- Set Humans Max. Count below 150
- Reduce the Road traffic factor
- Set Max. Sound Count between 250 and 400
- Reduce Max Object- and Map Complexity
- Reduce Max. Obj. Visibility Distance
Afterward, try the other settings. Finding the best setting takes some time. Since every PC is a bit different, there is no general solution.
Fleet numbering logic
All of our buses in OMSI have fleet numbers assignes using following logic:
10xx - small citybus
12xx - standard citybus
15xx - tri-axle citybus
18xx - arcticulated citybus
20xx - arcticulated citybus XL (20m+ or tri-articulated)
22xx - double-decker citybus
Intercity/coaches use same schema but +100 (so standard intercity buses are 13xx and tri-axle 16xx etc)
Wrong side of the road buses use same schema also, but instead have +4000 to their numers (so standard would be 52xx and double decker 62xx)
xx is the first unused number in that available section
And the beginning numbers for main categories from our current system come actually avg length of the buses in that category. 10xx = 10m, 12xx = 12m, 15xx = 15m, 18xx = 18m etc
Special IBIS Codes
The following tables explain what the MAN SD200/202 matrix readouts display based on line/course inputs. The table assumes that the value 123## is inputted in IBIS as “Line/Course”, where ## is to be replaced with the respective “Code.”:
All In/All Out Switch