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!

Not every texture can be packed into atlas, as sometimes you really do need outside 0/1 tiling, For such usecases you could setup additional flag for every texture, that would specify if the texture should be tiled (no atlas), tiled only on U, V or both.

Zitat von mmiki26

And while I did manage to achieve a significant performance boost (in some places even up to 30-50%), the solution unfortunately had two major drawbacks:

* the atlases were often laid out inefficiently, which wasted quite a bit of memory (I’d need to work on that further)

* unfortunately, some creators used UVs that repeatedly tiled a very small texture (for example, a single roof tile). This can either be ignored (leaving such textures as they are — which negatively affects optimization potential) or solved through texture “baking,” but that would require more work with lighting and shadow settings to avoid changing the object’s appearance too much

I would actually guess that combining many textures into one large texture atlas doesn’t bring as many advantages as reducing draw calls by grouping objects - at least not considering the effort required (remapping etc.). It would therefore be interesting to know what FPS you would achieve in your house example if all 5.000 houses were combined into a single o3d object but still used all their original textures.

From my perspective, the mapping issue also speaks against using a texture atlas, since it feels like half of all OMSI objects use UV coordinates >1 or <0 - just think of all the road and sidewalk textures.

In the Lichtentanne area, about 650 textures are loaded at the same time. Just that alone would already be nearly impossible to fit as memory-efficiently as possible into one huge texture atlas. A texture atlas also carries a certain risk that, due to mipmapping from a distance, other areas will show through or colour borders will appear.

My suggestion would therefore be to actually pursue the idea of combining objects and splines further.

Road-hog 123's exporter does remove the extra materials. It also fixes the default off-white material color - https://github.com/Road-hog123/Blender-OMSI-Exporter

I'd say that by just converting splines to objects per tile, there could be a possible performance boost, significant enough to be noticable. I've did myself small experiment where I changed bushes from being standard object, to be a 'tree', and that itself made significant difference (as Rudiger pointed above). Things get complicated as soon as we're talking about combining objects that use textures with transparency or use textures in a somewhat repeating pattern, then ideas of texture pet tile atlases falls apart, because either we'd need huge textures to not lose detail, or end up with low resolution textures for objects.

Therefore - I'd focus solely on spline conversion itself (I cannot say that with 100% certainty, but afaik each spline segment & texture is a separate draw call), as this is easiest low risk & high reward thing to work on.

Zitat von Sobol

each spline segment & texture is a separate draw call

It is, indeed. And since splines often use the same textures, a significant number of draw calls can be saved there for sure.

So essentially splines are OMSI's main problem (no wonder Hamburg DLC is well optimized).

Do you think it's better to use 'combined splines' (sidewalk+two lanes+sidewalk or other combinations) or it doesn't matter whatsoever so if you have patience to manually build out roads from pieces (sidewalks, lanes, grass strips, markings) the result is the same regarding performance?

The main problem is 3rd party assets, which use dozens of materials per object because they are sketchfab exports.

Hello,

Is there a way you could integrate Google Maps into your editor to create maps?

I think the good idea would be to think of 'raw source maps' and 'compiled maps', the other one being the map with converted splines->objects and whatever other optimisiations could be done, this way at least it leaves the flexibility of being able to edit out splines if something popups for the map creator later on. Also the other thing that would be nice to see, is automatic map backups, and on top of that - converting maps ONLY to a new folder, so that neditor couldn't overwrite any 'source' map files, just to 'be safe'.

End user (player) most of the time don't care about editing splines afterwards, and map creators could release a separate 'source' map files for people who might want to edit them. Since spline -> object conversion is more or less one way process, it is good to think further, but after all this is just my small rant.

Zitat von mmiki26

After exporting with the merge option enabled, only splines that contain attachments or paths will remain as actual splines (to avoid additional complications with traffic cubes and to preserve their OMSI IDs — which is crucial for maintaining bus route numbering)

Why not add the option to automatically add the paths directly to the object as an option? I mean there is no reason to use AI cubes when you have the actual splines as object and when the user does this conversion before the AI tracks. The only reason I use splines is for the trains to be in the middle of it anyway. I'm way too lazy to make spline, place in editor, export, and then recreate the paths in the crossing editor based on the splines in map editor.

I don't think there is any need for crossing editor and adding simple AI cube generation from invis_street.sli would be simple thing to add