nEditor - new omsi2 map editor

Willkommen in der OMSI-WebDisk!
Als Gast kannst du nur Inhalte in deiner ausgewählten Sprache sehen. Registrierte Nutzer können die Sichtbarkeit anderer Sprachen in ihrem Kontrollzentrum aktivieren, weitere Infos hier.
Alle Themen sind in den Foren mit einer Sprachflagge gekennzeichnet: = Englisch [EN], = Deutsch [DE], = Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch!
    • Neu
    Zitat von pabthespanish

    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 XD

    At most, up to €10 as a one-time payment for lifetime access to the program (future updates with additional modules will not require any extra payments—I think that’s a fair deal). I’m not planning any pre-order option.

    • Neu
    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! :)

    • Neu
    Zitat von Rüdiger Hülsmann

    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.

    Thanks! It’s great to hear that from one of the OMSI co-creators! 🙂

    Zitat von Rüdiger Hülsmann

    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)
    [...]

    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).

    As it happens, some time ago I worked on a PoC for an idea that partially touches on what you’re talking about (the difference being that it handled each object individually). Specifically, a program that:


    1. merges duplicated vertices at the same position into a single one
    2. combines all materials into one large texture atlas with a width that is a power-of-two multiple (of course, transparent textures would require a separate atlas [by the way, arranging textures in an atlas is a two-dimensional bin packing problem, and that was actually the topic of my master’s thesis :D])
    3. creates a new UV map for the object based on that atlas


    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


    Still, I think it’s a very good idea (once refined), and I believe this could become one of the future development branches of my editor, because within the scene I already have absolutely everything needed to create such a “merged object”.

    • Neu

    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.