nEditor - new omsi2 map editor

Since i heard the editor will be paid, how much in € would you sell it for? Will there be an option to pre-order before the main release?

My wallet is waiting

Very affordable, can't wait!

Zitat von mmiki26

1. Geometry and materials

In OMSI, geometry alone is not the only issue. Of course, the more geometry an object has, the heavier it becomes—but the number of materials on an object can be just as problematic.

Here’s an example that demonstrates this clearly:

A simple house (76 triangles, 129 vertices, 5 .jpg textures).

The major problem with this house: it has 17 materials. //don’t ask how I managed to do that...

Wow, that’s definitely an exciting project! Your investigations regarding draw call performance show a very clear result - and confirm the perception of all users and content creators so far.

Indeed, in OMSI, all trees on a single tile are combined into one instanced object, meaning a single draw call. That also explains your 1.300 FPS with 5.000 trees (after all, that’s only 40.000 triangles—any graphics card can handle that effortlessly).

Unfortunately, the problem of too many draw calls can no longer be solved within OMSI itself, but it might be possible to modify the elements that OMSI reads for rendering.

An interesting thought experiment would be the following:

Let’s imagine there was a way to export all objects per tile - including their coordinates and rotations - as a single large o3d object, which would automatically be placed in the center of the tile during map export for OMSI. Now imagine further that the materials in this o3d object are arranged in a sorted manner, so that materials and textures used by multiple objects (e.g. roof textures) appear only once in this large object. The number of draw calls for this object would then correspond only to the number of textures and material nodes it contains.

Of course, it would still be necessary to group objects so that everything works correctly in OMSI:

• Object group for all “normal” objects
• Object group for transparency (which must be rendered last)
• Object group for “collision” (containing all bounding boxes and collision meshes of the included objects as one large, continuous collision mesh)

The fact that VFD (culling of objects outside the field of view) would no longer work with such a massive single object would likely be negligible, as the performance gain would probably outweigh this by far.

Now let’s go one step further and imagine that all splines (i.e. the visible geometry) are also combined into a single object per tile. Splines also consume performance and require additional draw calls for every segment. In this case, you would of course need a “dual setup” of splines: one with visible geometry and paths for the editor, and a stripped-down version for OMSI containing only the paths (since the geometry would come from the large spline object).

Fun fact: If splines were converted into objects, you could even increase tessellation (polygon density) on straight sections to fix the well-known artifacts with billowing headlights at night!

By merging “decorative splines” into large objects, a 15% FPS gain was already achieved in the Lichtentanne area on the Thüringer Wald map. One can only imagine what would be possible with a consistent, automated merging approach!

Only the terrain mesh would still be rendered in the usual way due to its multiple texture layers. Everything else would consist of just a few (3-5) large objects per tile.

Just a bit of inspiration from a developer’s perspective for the further advancement of your program!