OMSI 2 Suddenly SO SMOOTH?! Our Practical Test with Thüringer Wald, Krefrath & Co.!

How much more smoothly does OMSI 2 run with openOMSI?

My practical impression while driving was quite clear: The overall picture felt calmer on the maps tested. Loading in new areas in particular bothered me considerably less than I was used to from many classic OMSI 2 sessions. The greater draw distance also made familiar routes feel more open. That does not mean that openOMSI automatically delivers more frames per second on every computer or that every single stutter has disappeared. But it shows quite well why pure FPS figures tell only part of the story in a simulation anyway.

For example, a map can run at 60 FPS and still feel unpleasant if loading a new part of the map suddenly inserts one noticeably longer frame. You often notice precisely these frame-time spikes more strongly while driving than the average frame rate. Textures have to be loaded, objects transferred to the graphics card, new areas of the map streamed and various background processes completed. If these tasks happen more evenly, a simulation can feel considerably smoother subjectively without the FPS counter suddenly being twice as high.

And precisely this smoother feeling was probably the biggest difference during my test.

Why does openOMSI feel different while driving?

The reason is also that openOMSI is not simply some performance patch for the old OMSI 2 engine. The project builds a new runtime environment from the ground up while continuing to load the existing OMSI content.

The new technical foundation operates as a 64-bit application and can therefore address a considerably larger memory space than classic OMSI 2. Tasks are also parallelized more extensively. Map data can be streamed, textures loaded via worker threads and various tasks processed in the background. Modern interfaces are available for rendering, including Vulkan and DirectX 12; depending on the platform or hardware, Metal and an OpenGL fallback are also available.

This explicitly does not mean that every CPU core would suddenly be utilized perfectly or that all technical limitations have disappeared. It does mean, however, that openOMSI can fundamentally approach many tasks differently from the old OMSI runtime.

Especially when driving across large maps, this is noticeable not only in a theoretical data sheet.

Performance is now a specific development focus

It is also interesting to see what has already changed in the past builds. openOMSI is currently being developed extremely quickly, and various performance problems have been specifically addressed within a short time.

One example was large mod maps where night textures could cause longer interruptions while driving. These textures are now loaded in the background more extensively together with the respective map section. In a documented extreme case on Novi Sad, a particularly slow object upload dropped from approximately 1760 milliseconds to 24 milliseconds. This is explicitly not a benchmark for Thüringer Wald, Krefrath or Krummenaab and cannot simply be applied to other maps. But it shows where development is currently focusing.

Culling has also been improved further. Data about which objects are visible at all and need to be rendered can be retained more effectively between individual frames. This is intended to reduce stuttering, particularly when moving the camera. Additional upload, GPU and rendering problems have also been addressed.

That is precisely why the question of openOMSI performance is not currently a static topic. A problem that is noticeable today may already look different a few builds later.

How does Thüringer Wald run in openOMSI?

Thüringer Wald was one of the highlights for me so far.

I know this typical OMSI feeling quite well: You drive through a landscape, the map is visibly continuing to work in the background, and at some point you get this subtle feeling that the game constantly still has to load something behind or ahead of you. In openOMSI, I quickly got the impression on Thüringer Wald that precisely this aspect feels different.

Above all, the combination of greater draw distance and smoother loading made the map feel surprisingly fresh to me. The route itself is of course the same. Roads, houses, landscape, objects and textures are not magically replaced by new assets. Nevertheless, perception changes noticeably when you can look farther into the landscape and loading during the drive feels less present.

Thüringer Wald is a pretty good example of this because the map contains many open landscape areas. Where you might mainly see houses and intersections in a dense city center, such an interurban map relies heavily on how far the surrounding area remains visible.

It genuinely gave me the feeling, at least in part, of getting to know a familiar OMSI map all over again.

Krefrath really clicked for me

If I had to name one map from the tests so far where openOMSI particularly strongly clicked for me, then alongside Thüringer Wald it would clearly be Krefrath.

And that is deliberately meant as a personal assessment.

I simply really enjoyed driving there. The draw distance, loading and the overall driving experience felt remarkably well-rounded to me in this combination. Krefrath is not a new map that I am discovering for the first time. And yet, on this new technical foundation, it suddenly had something fresh about it again.

With Krefrath, I had this feeling for the first time: This is exactly how I would like to drive OMSI in the future.

Not because every problem had suddenly disappeared there. Not because Krefrath would objectively run twice as fast in openOMSI. But because the sum of many small things felt different to me while actually driving.

Movement through the world felt smoother, the surroundings remained visible farther away and the map felt less like something constantly struggling against an outdated technical foundation.

At the moment, I am really in the openOMSI flow myself. After Thüringer Wald and Krefrath, I immediately felt like installing or trying out the next map. This feeling of experiencing old favorite maps anew on a new technical foundation is surprisingly enjoyable right now.

And how does Krummenaab run?

Krummenaab was the third important practical check for me.

That was precisely why the map was interesting, because I did not want to look exclusively at my two personal highlights. If a positive impression had emerged on only one map, it would have been considerably less meaningful.

On Krummenaab too, driving felt smooth during my test. The greater draw distance was visible again, and loading did not constantly push itself to the foreground while driving. I did not notice any specific major problems during my run, which is why I do not want to artificially invent any here either.

For me, Krummenaab was therefore less of an emotional “wow” moment like Krefrath and more confirmation that my impression was not limited to a single map.

Three different maps are of course not yet a complete OMSI mod library. But they are enough to show that the new technical foundation can already be noticeable in practice across very different content.

Does 64-bit automatically mean more FPS?

No.

This is probably one of the biggest misunderstandings surrounding modern reimplementations of older games. A 64-bit application does not automatically produce a higher frame rate simply because “64-bit” appears somewhere.

The major advantage initially lies in being able to address considerably more memory. Classic OMSI comes from a technical era in which very tight memory limits were a real problem – especially with large maps, many high-resolution textures and extensive mods.

Thanks to its new architecture, openOMSI can handle such data in a significantly different way. Streaming, parallel processes and more modern rendering are added to this.

Whether this results in 45 instead of 35 FPS or 80 instead of 60 FPS on a specific computer depends on the hardware, map, bus, settings, AI traffic and many other factors.

That is why the question I currently find much more interesting is: How consistent does the game feel?

And there, my impression was much clearer.

Why frame times matter so much in OMSI

OMSI players probably know situations in which an FPS counter does not look dramatic at all, yet the game still does not really feel smooth.

This is often due to frame times.

If, for example, 59 frames are calculated very quickly within a certain period, but one individual frame suddenly takes considerably longer, you still notice that one hitch. This often happens when streaming large game worlds, loading textures or creating new objects.

That is why more even processing can subjectively be considerably more important than ten additional average FPS.

That is precisely why my impression of openOMSI was positive. I was not sitting there constantly watching an FPS counter. Rather, I noticed that the typical feeling of loading during the drive was less dominant.

And for a bus simulation, that is quite decisive.

Old maps are not automatically modernized – but still feel different

One thing must be clearly distinguished here: openOMSI does not automatically rebuild old OMSI maps.

Krefrath remains Krefrath. Thüringer Wald retains its existing roads, buildings, splines and textures. Krummenaab does not suddenly become a modern Unreal Engine project.

Nevertheless, the presentation can change.

A greater draw distance makes landscapes feel different. A modern renderer can display lighting and materials differently. Smoother streaming changes the journey through the map. Modern memory management can provide content differently. And when new map sections are loaded into view less noticeably, the world feels more cohesive.

Thüringer Wald and Krefrath in particular showed me how strong this effect can be.

It is not necessarily the individual spectacular graphics feature that makes the difference. Often, it is the sum of many small technical changes.

Is openOMSI already faster than OMSI 2?

I would not make such a sweeping claim after my test.

That would require a proper benchmark. Identical map, identical bus, identical time of day, identical traffic, identical draw distance and then comparable FPS and frame-time measurements on the same hardware.

We did not do precisely that here.

What I can certainly say, however, is this: The fact that openOMSI feels different during actual driving was clearly noticeable to me.

The loading in new areas, draw distance, streaming of the world and the general calmness of the gameplay experience made a difference during my drives.

This does not allow us to conclude that openOMSI delivers measurably more FPS on every computer and every map.

That a familiar OMSI map can feel noticeably smoother subjectively on the new engine, however, can be concluded.

openOMSI is still far from finished

Despite all the enthusiasm, one point must not be forgotten: openOMSI is still in Early Release.

The project is currently developing at an enormous pace, but that is precisely why new compatibility cases continue to appear. Different mods sometimes use OMSI functions in unusual ways, some buses have very specialized scripts and many maps use technical tricks that have developed over the years within the OMSI ecosystem.

There are still reports of individual missing or faulty textures and objects, specific script and material problems, differences in matrix displays, AI behavior and inputs, as well as graphics driver or GPU problems on certain systems.

At the same time, older errors should not simply be carried forward permanently if they have since been fixed. That is happening very quickly with openOMSI right now. Invisible collision objects that caused buses to jump on mod maps in some cases, for example, have already been specifically addressed. Problems with roads or invisible terrain beneath bridges have also been corrected. Various Thüringer Wald-specific display errors have also already been worked on.

A problem report from three days ago may therefore already be outdated in today’s build.

That makes openOMSI exciting at the moment, but also complicated to test.

OMSI 2 or openOMSI?

The two environments currently still fulfill different roles.

The classic OMSI 2 is the established original environment. A huge ecosystem has developed there over the years, and countless maps, buses and expansions were built and tested specifically for this runtime.

openOMSI on the other hand has the new technical foundation. 64-bit, modern rendering, multithreading and streaming open up possibilities that OMSI 2 will no longer receive in this form. At the same time, the project is still in the middle of development and therefore has not yet achieved the original’s mature compatibility in every special case.

Nevertheless, something has happened for me personally after the test drives of the past few days.

To be honest, I would be very reluctant to do without this new technical foundation again.

Krefrath and Thüringer Wald in particular have shown me that openOMSI is not merely an interesting technical project on GitHub. During actual driving, a familiar map can already feel surprisingly different.

And perhaps that is precisely what is most exciting about openOMSI at the moment: You do not need a completely new OMSI map to feel like simply setting off again.

Try openOMSI

Project page:
https://turbo-devv.github.io/openOMSI/

Current downloads:

Releases · openOMSI-Project/openOMSI

OMSI 2 recreated from scratch in Rust, compatible with every map and mod (requires the original OMSI 2) - openOMSI-Project/openOMSI

github.com

openOMSI still requires an original installation of OMSI 2 The project does not include the game content itself.

Have you already tried openOMSI yourself on a larger OMSI map – and which map feels the most different to you so far?