Is THIS OMSI 3? openOMSI rebuilds OMSI 2 with a modern engine!

What exactly is openOMSI?

openOMSI is not a mod that swaps out a few files from OMSI 2, nor is it a patch that retroactively extends the existing engine. The project is developing its own runtime environment from the ground up. It is written in Rust, a modern programming language, while the original OMSI code is not being adopted. Nevertheless, the goal is highly unusual: The new engine is intended to understand OMSI's existing file formats and behave as similarly as possible so that existing content continues to work.

That is precisely why openOMSI also requires an existing installation of OMSI 2. The project does not simply include Berlin-Spandau, Grundorf, the original MAN buses or commercial add-ons itself. Instead, the new engine uses content that the player legally owns. Maps, vehicles and other files therefore remain intact – what is replaced is the technical environment that loads and runs them. For example, anyone who owns a large mod map or an extensively scripted community bus should not eventually have to convert it to a completely new simulator format.

Is openOMSI really OMSI 3?

No. openOMSI is not an official OMSI 3. It is neither an official successor to OMSI 2 nor connected to the original developers. The name “OMSI 3?” therefore functions more as a comparison: openOMSI is attempting to implement many of the things players would want from a modern successor technically within a new engine.

And that is precisely the interesting difference from a conventional third installment. A completely new OMSI could be technically more modern, but it would first have to decide what happens to the huge stock of old content. OMSI 2 has existed for many years, and accordingly there is a vast selection of maps, buses, repaints, scenery objects, splines, timetables, sounds and scripts. A hard break could mean that a significant portion of it would no longer work.

openOMSI therefore pursues the opposite approach: The content is not supposed to be reinvented; instead, the technical foundation beneath it is.

Why openOMSI is rethinking OMSI 2 technically

This becomes clear at the latest when looking at the architecture. openOMSI is being developed as a 64-bit application and is multithreaded. While OMSI 2 technically comes from a completely different PC generation, the new engine can distribute work across multiple threads. Map data can be streamed and textures loaded via worker threads instead of having to process all tasks through the same old technical pathways.

For rendering, openOMSI uses wgpu. This allows modern graphics APIs such as Vulkan, DirectX 12 and Metal to be accessed. That does not automatically promise gigantic FPS gains or photorealistic graphics. It initially means that the technical foundation is built in a far more modern way and is not bound by the same old limitations. How noticeable this actually becomes with a specific OMSI map or a particular bus depends in turn on how fully that content is already supported.

openOMSI also goes beyond what classic OMSI 2 provided for in terms of materials. For example, the project documents support for normal maps, roughness, metalness and ambient occlusion. This allows surfaces to be displayed in more detail than with the previous material options. At the same time, existing content can continue to use its classic OMSI files. New possibilities are therefore intended to be added without necessarily introducing a completely new mod format.

Which OMSI 2 content works with openOMSI?

The project's ambition is very far-reaching. openOMSI does not merely want to load simple models or textures, but to interpret practically the entire structure of OMSI 2. This includes maps, buses and other vehicles, as well as splines, scenery objects, scripts, timetables, HOF files, fonts, sounds, weather, ticket systems, AI traffic and plugins.

With OMSI in particular, this is a huge task. After all, a bus consists of more than just a 3D model. Doors, gearbox, engine, matrix, IBIS, lighting and displays are partly controlled by highly complex scripts and dependencies. A map, in turn, consists of more than roads and buildings; it can use timetables, AI lists, intersections, traffic-light sequences, different Chrono states and numerous additional objects.

That is why the most important limitation at the current stage is also quite clear: The aim of achieving the most complete compatibility possible is a development goal, not a guarantee that every single OMSI mod already works flawlessly today. openOMSI is explicitly in an early development phase. Current error reports still show problems with individual vehicles, textures, dynamic materials, certain displays and other special functions, among other things. We will cover this topic in a separate article within this series later.

That does not change the fact that there is already much more than a theoretical technology project today. openOMSI has its own launcher, can detect an existing OMSI installation, and allows maps, buses and services to be selected. Mods can be integrated separately from the original installation. The project publishes builds for various operating systems and is continuously developing its compatibility.

64-bit, multiplayer and Android: What openOMSI wants to change

The new engine is not limited to a modern Windows PC. openOMSI is being developed for Windows, Linux and macOS and supports both x64 and ARM platforms. Android is particularly unusual: It does not simply stream video from a switched-on gaming PC; instead, the engine itself can run natively on an ARM device. Naturally, the existing OMSI files must be available on the device for this.

Also, multiplayer is part of the new architecture. OMSI 2 itself does not have a conventional integrated multiplayer mode. openOMSI, by contrast, is developing networking directly within the engine and also provides for dedicated servers that can host a simulation without full graphical rendering. In the long term, this could create possibilities that OMSI players have previously known only through indirect means or external systems. We will also examine separately how complete synchronization already is and where limitations still exist.

Mod management is similar. The dedicated launcher can integrate mods without permanently modifying the actual OMSI installation. In the long term, this could also change something about a very old OMSI ritual: opening a ZIP, checking all folders and manually copying files into Vehicles, Maps, Sceneryobjects or Splines. Here too, however, the following applies: A convenient installer does not automatically make an incompatible bus compatible and cannot simply conjure up missing dependencies.

Can openOMSI eventually replace OMSI 2?

This is precisely where the matter becomes more interesting than the question of whether openOMSI can simply be called “OMSI 3.” A conventional successor would presumably begin with new content, new vehicles and a new technical foundation. openOMSI, by contrast, is attempting to put the existing OMSI world on a new foundation.

Ideally, this could mean that an old favorite map continues to live on just like a modern community bus, while a 64-bit engine with multithreading, modern graphics APIs, multiplayer and new material options operates underneath. At the same time, the current state of development also shows how difficult precisely this ambition is. The more deeply an OMSI mod relies on scripts, special textures, plugins or unusual tricks, the more behavior the new engine has to reproduce correctly.

It would therefore be premature to describe openOMSI today as a complete replacement for OMSI 2. The project itself warns of errors and missing functions, and ongoing development shows that numerous edge cases still need to be found and fixed. That is precisely what makes the coming months interesting, though: You can observe fairly directly how individual interpreted OMSI systems are gradually intended to become a complete alternative runtime environment.

The perhaps decisive question, therefore, may eventually no longer simply be when an official OMSI 3 arrives. It may instead be whether a conventional third installment is even the only way to bring OMSI technically into the present day.

Link: https://turbo-devv.github.io/openOMSI/

Do you even still need a conventional third installment for OMSI if a project like openOMSI could technically modernize the existing world – or would a real OMSI 3 still have to start completely from scratch?