Vehicles in OMSI

A bus in Omsi consists of several files. The different files are necessary because they have different tasks. In this tutorial we will discuss what files are necessary and what these files are used for. Please also refer to the section: File Formats in OMSI. The same applies to all AI vehicles. For pure AI vehicles, which should not be controlled by the player, the scope is very limited and only refers to the essentials.

1. General principles

Basically all objects in Omsi consist of several files. Together they make up the objects visible in Omsi. This includes buses, trams, trains and the vehicles of individual traffic. In this tutorial I will refer to a bus. This also applies to all other objects, although sometimes not so extensive.

The file types for vehicles in Omsi are:

• 3D object files
• Image files (called textures)
• Audio files (vehicle noise only)
• Text files

These different types of files are located in different subfolders, which is only used for overview. Starting from the main folder of Omsi, all vehicles are located in the subfolder "Vehicles". The subfolders contained in this folder are, besides the central folder for announcements (Announcements for audio files) and the central folder for sign textures (Announcements for texture files), the vehicles for AI traffic (cars, trucks, trams, trains) and the buses that are drivable for the player. The display name of the busses in Omsi (vehicle selection) has nothing to do with the names of the respective vehicle subfolder and may therefore differ.

Furthermore, fonts are required for the character sets used in or on the bus, such as license plate fonts, display fonts or similar. However, these are not located in a bus folder, but are set centrally in the Omsi folder under Fonts.

1.1. 3D object files

Each bus consists of 3D objects. These 3D objects are the objects that are then displayed in the game. Together with the image files, they make up the objects visible in Omsi. These 3D objects are created by a 3D program.

3D programs:

• Dazzler
• SketchUp {Make or Free/Pro}
• zModeler
• autoCAD
• Sweet Home 3D
• Autodesk Maya

and many more

Some of these 3D programs are free of charge, while others are chargeable. Also the handling is quite difficult for beginners. But for many of these programs there are many tutorials on the internet. Also the range of functions is very different.

A 3D object consists of one or more polygons. A polygon is a triangular surface. At each corner is a vertices. Between the three vertices of a polygon, there are the edges, which represent the direct and shortest path and cannot be bent. Several corners of several polygons can have one vertices together. Several polygons then form a complex 3D object. This is used in Omsi as object file. The file contains the position of the object itself, the position of the polygons and their vertices, the used texture names of the image files, the size and the position of the object origin to the 3D object.

Thus a simple cube with 6 faces always consists of at least 12 polygons. A polygon is generally only visible from one side if you do not work with a transparent texture. If you want to make a 3D-object a bit more round, you have to use several polygons.

In the game, a vehicle can consist of a 3D object (parking vehicle) or several objects together. A vehicle can consist of a 3D object, in which case the vehicle cannot have any rotating or sliding parts. Every 3D object that should move in relation to the main object (animation) must be integrated as a separate object. So an AI-vehicle always consists of at least 5 single 3D-objects, like the vehicle body and the 4 single wheels. If further parts of a vehicle are to change their shape and appearance by animation (e.g. hood of a convertible, roof hatch, doors, flaps or hoods, roof superstructure), these objects must also be created as separate 3D objects. The corresponding animations are entered in the different text files.

In a 3D program the textures (image files) are assigned to the objects. This assignment is called mapping.

1.2. Texturen

Textures are image files containing images that are mapped on the surfaces of the polygons. A texture can contain several surfaces for one object or for several objects. In the same way you can also use several textures for one object.

Textures should always be in the format of a power of eight. That means that the edge length should be in the pixel numbers 2^n (1, 2, 4, 8, 16, 32, 64, 128, 256, 512 and 1024 pixels). The image sections should not be too small in relation to the object, otherwise the texture will be too piecemeal on the object. This does not apply if an object is to be solid, i.e. monochrome. Then the format 1x1 pixel is sufficient. For Omsi the image formats should not be too large either. Special texture sizes above 1024 pixels put a strain on the system for Omsi. Since Omsi is only a 32bit program, not too large texture formats can be used.

With textures you can make objects look more vivid. Especially with a polygon-saving construction of objects, you can simulate 3D structure effects optically with good textures on flat surfaces. But this is only possible up to a certain degree. Surfaces with a clear surface structure have to be modelled. Especially curves should be modelled.

Since the light effects in Omsi are limited, textures can also contain light effects or shadows, whereby objects in a 3D object look more alive. You can also create light textures for Omsi, which can then be changed by script.

1.3. Audio files

Audio files are sound files that give the vehicle its sound background. Since no engines have to be installed in vehicles, the simulated engine is made audible with sound files. Sounds are either individually recorded and incorporated, whereby Omsi then plays these sounds back via the script. Or a sound recording is split up into many small sound snippets. Omsi can play several sound files simultaneously. So you can play not only the sound of the engine but also the sound of the axles, gearboxes, tyres and many other sounds while driving.

Omsi can also play the sounds once, but also in loops. You can also use the script to control the origin of the sounds from the player's point of view, the volume and the fade in or fade out of sounds.

Sound files can be in mono and stereo.

1.4. Text files

All other files in a bus are actually text files and can be opened and edited with a text editor. These text files are divided into several subtypes. The difference serves the user for better differentiation.

1.4.1. Bus file

A bus file contains entries such as the name of the bus (this name then appears in the selection menu), the storage location (path) to the sound files, passenger files, path files, repaint subfolders, registration files, the model file, the script and other text files. In addition, the positions of the tickets, positions of the player as driver or passenger, mirror settings and basic physical data of the vehicle, such as the weight or special data of the axles are also defined there. The bus file must always be located in the main folder of the bus.

1.4.2. hof file

The hof file is a simple text file and serves the bus as a place of information, for the possible advertisements in and on the bus. It contains the IBIS codes for the termini, all stops and stops and the possible routes. Without a suitable yard file, a bus cannot output any information what it should display on a map as destination or other information. The yard file must be in the bus folder and serves the player bus as well as the AI bus (with timetable) as a basis for displaying the destination.

1.4.3. Registration files

Registry files are identification files that give each bus an individual distinction. Here you can find whole license plates or only the car numbers. Registration files have nothing to do with the registration of an add-on for Omsi.

1.4.4. Model files

The model file is the interface file between Omsi and the individual object files. This file is generally referred to only as "model.cfg". The model file contains the individual 3D objects as well as their specifications for Omsi, such as texture change to repaint textures, light textures, LOD objects, visibility settings, animations, affiliations to other objects, light points, halo, glass effects, bumps, reflections, dirt and rain textures and click points.

The order in which the mesh is entered in this list is not unimportant. This order also determines the order of visibility through other objects. This order is called rendering order, because they are displayed according to the order in the model file. Furthermore, the order is also important when it comes to registered objects that cannot get their own direct animation commands (example light points). If light points are to be moved along with an object, these light points must be entered directly below the animated object. If light points are under an animated object, although they should not move with it, these light points must be converted.

1.4.5. Passengercabin file

In the passenger cabin, the positions for seats, standing room, position of the cash desk (payment money, change, issued ticket), the entrances and exits, the validating position, as well as the position for transfer to another part of the vehicle (for example the trailer). The position of the driver's position is also entered here. For the seats, the assignment to the interior light is also set for the individual positions.

The respective inputs and outputs are indicated with the numbers of the path points. With the command [entry] an input is specified. Which path point this is, determines the position of the path point. These are entered in the path file. The same applies to the outputs [exit]. Here too, only the corresponding outputs of the path points are defined.

1.4.6. Path file

This file {paths.cfg} works directly with the Passengercabin file. In this file only the running sounds of the passengers are entered, the individual path points and the connections of the path points. Important is the order of the path points. The order is zero-based. Here the first point (point 0) can be used as entry point. The way to the cash desk is laid over further path points. Further points are entered bus-specific. For example from the 3rd point to the validator, further through the bus to the respective seats and standing room and to the exit, to the exits.

Here it is important not to be too economical with the individual path points. Too few path points in the bus create the unattractive and unrealistic effect that passengers walk to the next possible path point closest to their chosen seat. If the distance between the path point and the seat or standing room is too great, passengers "beam" to the seats. This means that in the mirror you can see the person disappearing in the bus. If the seated passenger position is covered by other objects or passengers, you will not see this person reappear (see buses from Hamburg T&N, 3Generationen, Hamburg Hafencity or Hamburger Buspaket). If many waypoints are set to the seats and standing places, the passengers seem to sit down or stand there very quickly. The same happens again when the passengers leave their position to walk to the exits. With too few path points, the passengers suddenly appear somewhere in the bus.

In the last part of this file, the individual path points are put together one after the other. There are always two path points combined (example 0-1, 1-2, 2-3, 4-5, 5-6, 6-7, 3-7, 7-8 etc). Furthermore, it is defined here whether this path connection is a "one-way street". The passengers then always walk the direct route from one path point to the next. Therefore the path points must always be led around objects.

1.4.7. Sound file

The sound file is usually located in the Sound subfolder. In this, the individual sound snippets and the parameters of the individual sounds are specified, how the sound should behave and with which variables it should be triggered. This file also gets the file extension cfg.

1.4.8. Script

The subfolder Script usually contains only normal text files. There are four types of text files, which differ in 2 file types.

• Script files (file extension cfg)
• Variable list (file extension txt)
• Constants (file extension txt)
• String variable list (file extension txt)

Strictly speaking, a bus only needs these 4 files.

• script.cfg
• Variables.txt
• Constants.txt
• String Variables.txt

But you use several of these files to keep track when modifying or adding improvements. Therefore the script subfolder contains several files that are divided into several bus-specific areas (brakes, engine, power, doors, cockpit, cash register, matrix, collisions, dirt, exhaust and many others). The file names are not defined here.

1.4.8.1. Script files

Script files are actually only simple text files. But unlike the other text files, variables and string variables are calculated here. Thereby the states of certain variables are read out and entered in stack containers. Depending on the operator or logical operations used, the results are then calculated and stored. These results are then triggered in Omsi. So if the state of the variable "lights_stand" equals one, the parking light is activated on the bus. String variables contain certain letter, number or character strings and are then represented by the fonts (example time {digital display}, temperatures, matrix, bus stop display etc.).

Omsi displays a certain number of images per second. How many images per second are displayed can be seen from the displayed fremerate per second in the game itself. So if the FPS is 30, then Omsi will display 30 frames per second. Omsi reads the scripts once in each fremerate and calculates them. So if the FPS is 30, the scripts are read and calculated 30 times.

Therefore it is important to keep scripts simple. Unnecessary queries or the constantly repeated query of variables can put a heavy load on the performance. Especially if the result is always the same, because this result will be overwritten several times in every fremerate. Even though there are many ways to create a calculation, you should, as far as possible, keep the calculations simple and summarize them as far as possible.

1.4.8.2. List of variables

All variables used in the scripts must be verified by Omsi, otherwise these variables become invalid. This error is also shown in the logfile. In this _varlist.txt the individual variable names are entered one below the other. Only variables which are entered in this list become valid and can be calculated.

1.4.8.3. Constants

In some calculations, not only variable variables but also fixed constants are queried. These constants can differ depending on the bus type, but are then always the same for a particular bus. These constants can be used directly in the calculation or can be entered in the text file _constfile.txt. This is especially useful if you want the user to change certain conditions or if the values are not exactly constant. This is the case, for example, when displays are not constant but have non-uniform scales. This is the case when a smaller scale section covers a larger range in which the values are normal and the range that is abnormal is then reduced. An example of this would be the temperature indication of the cooling water. For smaller diesel or petrol engines, for cars or trucks / buses, a temperature below the normal operating temperature is not dramatic. One should just not demand too much power. In the normal operating temperature range, one can then drive normally. If the temperature is too high, it doesn't really matter how much the temperature is above normal, something has to be done. Such volatile displays, where the display is not supposed to perform constant movements, i.e. movements of the same size, can then be entered with several constants, whereby the respective current values can then be included in the calculation.

Another example are doors. Electric doors change from one state {open} to the other state {closed} at a constant speed. Pneumatic doors change their speed depending on the pressure in the piston, whereby these doors can then, for example, start slowly and increase their speed during the course of the journey.

1.4.8.4. String variables

String variables are all those variables that consist of characters other than the calculated values. Such string variables must be read out and first converted into a format suitable for display. In Omsi the time is calculated according to the number of seconds after midnight. Since the time: 47340 o'clock is of little use, this number of seconds must be converted first. In the first conversion the seconds are converted to minutes and in the next step 60 minutes are combined to one hour. At the end the time 12:34 can be displayed.

Other string variables are read from other files. If you enter the code 123 in IBIS, the strings from the farm file that belong to this target are read out and the corresponding target is then saved as a string variable to be able to display it as a target in the matrix. String variables are therefore variable variables that cannot be displayed directly, but must first be changed to suit the display. All string variables must be entered in the _stringvarlist.txt to be valid in the script system.

2. Performance in bus construction

To build a bus in Omsi, it is important to look at the size. For example, a bus with 100,000 polygons is a low polygon model. A model with 300,000 polygons is extremely important. As a player vehicle, a bus with 300,000 polygons is not a big problem, because in Omsi there is only one player in the vehicle at a time. But when such a vehicle is used as AI traffic, the polygons multiply with the number of vehicles. At a big junction, 9 more buses in the visible area are an advantage, because it brings the scenery to life. However, Omis must not represent 300,000 polygons, but 3 million - for these 10 buses alone. But on a map these are not the only polygons. More polygon numbers are added for crossings, streets and surrounding scenery objects. So the number of visible polygons can multiply very quickly. A bus with 300,000 polygons, together with 3 million polygons for the surrounding area (houses, streets, bus stop signs, bushes, trees, grids, fences, signs etc.) are already a small load. Then it makes a difference whether ten more buses with one million or with 3 or more million polygons are added. It also enlivens a city much more, if not only 2 or 3 AI-vehicles are driving, but the number of a city and the time is appropriate. But each of these vehicles has a fixed number of polygons. These are then added to the total number of polygons.

There are two ways to reduce the number of polygons when building a bus. Either you build simplified objects with few polygons, which are set as AI-variant, or you remove these objects from AI-vehicles through the visibility (viewpoint-flags). The advantage of low-polygon vehicles is the greatly reduced number of polygons that can be achieved. The disadvantage is that you can take over these vehicles, but the quality of these vehicles or the functionality in the vehicle could be very limited.

The same is true for the scripts. Scripts should be kept as simple as possible. The more extensive and complex a script becomes, the more it burdens Omsi. The biggest and most noticeable load are nonsensical queries, for example when different calculations are done in several individual triggers or macros, but a result variable is overwritten again and again.

Script calculations work as follows. Omsi displays several images per second, several still images. Many still images in quick succession result in a moving image for the human brain. How many frames per second Omsi displays can be seen by the Fremerate per second (FPS). The FPS does not only show the number of pictures in Omsi, but also the individual calculations of all scripts. Per fremerate Omsi calculates all scripts, all single triggers and macros completely. This means that if Omsi is currently running at 30 fremerate per second, all scripts are completely computed thirty times per second. If you extrapolate the whole thing in one minute, at a constant 30 FPS all scripts are computed 1800 times. This does not only apply to the scripts of the player bus, but also to the scripts of all other AI vehicles and object scripts. For this reason you should avoid nonsensical and completely useless scripts. To give an example: In the busses from the add-ons Hamburg Tag&Nacht, 3 Generationen, Hamburg Hafencity, Hamburger Buspaket and Add-On Ruhrgebiet, there is a query of the yard file, respectively the map name. The reason is to make these buses show a special behaviour on a certain map. But this is a completely useless query of the yard file, which also consumes unnecessary resources.

Omsi is a 32-bit program (x86). This means that Omsi can use a maximum of 4 GB of RAM memory if the 4GB-Ptach is activated. The Windows operating system already requires about 1GB of RAM. Steam and other programs (driver programs, browser etc.) require additional memory resources. All programs that are started before Omsi use less than 4GB of memory. If Omsi is started now, there is not much memory left for Omsi. Especially Steam uses a lot of memory and graphics memory because the commercials are displayed with pictures while playing Omsi. As already mentioned, one bus alone does not make much difference. But several busses on a heavily built tile, then push the performance very hard.

Extensive complicated scripts, large graphics, many polygons and heavily built-up tiles, add up to a lot of data and push the performance down. All these things have to be considered when building a bus or map.