At this point are metro cars supported?

  • TLDR; Are metro cars supported at this point by LOTUS?


    In the script variables lexicon article, V_ThirdRailCollector_{b}_{L/R} variables are mentioned. Also if I remember correctly, in the map editor, third rails can be set to tracks. However I don't find contact pad options in the content tool, no at the pantographs, no other "hidden" option for it in the general settings...etc.


    Also since the opensource DIorama has not been updated with the third rails, what's the method for installing third rails? I see in the CT there's an option for third rails. But where should these be positioned, what should they contain? Eg. I have an object like this (yes, at the moment it's a spline, I'll create a new one as third rail):



    It's positioned so it can be placed exactly at the track (it's origin is at let's say X= -1,8m). Is that a correct manner or should it be positioned to the center, and in the track settings it must be positioned? Can it contain all additional parts (fittings, base, cover...etc)?

  • I was fooling around on Diorama and discovered that actually the third rails do work. I guess on every Subway typed vehicle the game thinks every boogie has a contact pad on each side.


    On the other hand...


    I don't know who had this idea in the development team, that such a high detailed third rail mounting is a good idea, but I think you all should forget this. It's not even really visible from the cab, but at least it's tonns of polygons on every part. Sure, in another program this would be OK or even too simple, but in LOTUS, that's a very bad idea (on the almost fully empty Diorama U-bahn part I have less fps than on my almost fully built map...)

  • Thank you for your opinion on the power rail. They were built by me.


    On the subject of performance:

    In order to investigate the influence of power rails on the performance, I have already tested this in advance. I equipped a map once with all 3 power rails available in the base content, once with overhead power lines and once without any power supply. Obviously, the performance was highest without power supply. However, when looking at the FPS, the conductor rails performed better than when using the overhead line. For Lotus, the number of polygons is less important than the number of individual objects (such as catenary poles).

    Due to the technique of the map editor, the conductor rails are packed together with the tracks and sleepers into a fixed mesh. In terms of polygons, they belong together. Therefore, there is no problem here.

    If you have noticed a problem regarding the performance in comparison to one of your maps, you are welcome to send it to me so that I can understand this problem myself.


    On the subject of the model:

    In Berlin, where these conductor rails are used, there are places in the network where the corresponding faces are needed in order not to look into the void. For example, viaducts or certain turnarounds on the line. It is also planned to be able to walk around in the first-person perspective later on, where you can see the conductor rail from a different perspective.

    All in all, a holder of the conductor rail has less than 100 polygons and a piece of the conductor rail itself less than 75 polygons. In today's world, however, this is perfectly tolerable. Other factors have a much greater influence on performance, such as the textures.


    Finally, no one is forced to use my conductor rail. Especially since it is only used in the Berlin underground in this design. (As far as I know)

    If you don't like this variant, feel free to build your own and use it.

    Ja äh, hier irgendwas mit Dingen und so...

    Einmal editiert, zuletzt von Pandemist ()

  • Finally, no one is forced to use my conductor rail. Especially since it is only used in the Berlin underground in this design. (As far as I know)

    If you don't like this variant, feel free to build your own and use it.

    Bzmot even mentioned his experience how it affects the performace, so I don't think it's about using it in his own map (because as you see he's making his own 3rd rail), rather the fact that many of us are concerned if Berlin would run smoothly when it's released, while having these seemingly unnecessary details.

  • I am only commenting here because reference was made to my conductor rails. Since Florian has already answered the core question of the topic, I have not dealt with the main issue any further.

    Nevertheless, I have already dispelled the concerns that the conductor rails represent a particular burden on performance.


    So there shouldn't be any further problem here, should there?

    Ja äh, hier irgendwas mit Dingen und so...

  • Zitat

    All in all, a holder of the conductor rail has less than 100 polygons and a piece of the conductor rail itself less than 75 polygons. In today's world, however, this is perfectly tolerable.

    You are right, in today's world, this is perfectly OK, and in any other game they would be great. But not with a game engine which is that bad. There's a reason why I'm optimizing things like wall cables in tunnels and third rails, why I don't use 3D sleepers/ties never. LOTUS has terrible performance and things like these don't help. Especially I don't know why objects used in tunnels need to have such high fidelity (also the lower parts of the rails are not seen from almost any direction).


    Very detailed tracks, ballasts, sleepers, third rails are "bad", because every little spline is merged into the terrain, no matter how unimportant it is. Sure, once it's painfully generated (which usually leaves errors in LOTUS...), it's in the mesh. But that's mesh is stored in files, so a different sleeper on a 10-15km map can mean by itself at least 1-2GB space (I experienced that myself the hard way), and that's the same wit everything else. Also the bigger the tile file, the slower it can be loaded. Don't tell me I'm the only one who experiences lags at tile loading or who's game runs for a few seconds in the void, because the tile could not be loaded ingame. Edit: I almost forgot: the slow loading is even worse on faster lines like an U-bahn/S-bahn, because the station distance is bigger, the trains move faster, tiles need to be loaded more frequently.


    Of course I'm not forced to use them, I modelled my own ones (our soviet built metro uses a slightly different version, but even if it didn't I would have modelled them). But I'm 100% sure in one thing: my map on the underground part won't lag and should run at least OK on the weakest PCs LOTUS can run on, however I would not say that about the Berlin map, even in advance.

  • In addition to that I find it very hard for us "external" modders to decide which level of detail on our own objects is suitable for Lotus. Normally you would look at the stuff that comes with the game and try to match that quality as the game would be designed to run best with these objects. However, the Lotus BaseContent is pretty inconsistent in terms of detail and quality, and so are written statements of BaseContent-Developers. When a picture of my 3d-sleepers was first shown, Florian got a verbal heart attack, pointing out it was essential for track-objects to save as many polygons as possible. This strategy seems to also have been applied to Oriolus' S49-Track, which has even fewer details as in Omsi, to the point that the polygons at the bottom of the head of the rail miss completely. But here I am seeing the other extrem, whilst reading that more polygons in track objects do not really matter that much and can easily be handled by the Game. Consider me confused.

  • In addition to that I find it very hard for us "external" modders to decide which level of detail on our own objects is suitable for Lotus.

    This is also hard to decide for everyone. As some of us "internal" modders have already made some bad decisions, which led to performance issues, we want to prevent others from making such experiences on their own. The decision making is also very complicated, so I can tell you some factors:

    • freeware / payware: When creating payware you should make sure, that every LOTUS user can play your add-on, it is not mandatory for freeware.
    • size of the map: Disk space is no problem at all until you get to the point, where small maps have 5 GB.
    • Does polygons matter?: Not at all, unless they are baked into the terrain. In this case the limiting factor is the map size.
    • How often do they occur?: The standard setting for sleepers are 60 cm between two of them. A holder is placed every seventh sleeper. If you have a sleeper with 80 polygons and a holder with 80 polygons, what's worse?

    In fact the sleepers and the holders are not quite equal compared to each other. I still would reduce polygons on sleepers, meanwhile I've got no problem with the third rail having the doubled amount of polygons.


    Greets

  • Please don't tell me LOTUS doesn't support gradual LOD blending. Because LODs solve these problems for you...

    Every spline element (so tracks and sleepers/ties) is baked/generated into the terrain, so I don't think that it can be LOD-ed. Scenery objects sure (though I don't know if it makes any difference - I mean sure in the distance they don't cost that much, but than it has to be replaced with the more detailed and that since LOTUS does lag very often, that may be not very desired either).

  • I found the metro to be kind of a good compromise, because if it's built correctly, it lacks of highly detailed modells and runs OK. But surface maps....yeah. There's a reason why I stopped working on mine as well.

  • @ Bzmot332 I really like your metro map and train, its only a short line with a couple of stations. But ist fun to drive and the sounds etc. are not bad. Also the performence is pretty good compared to other maps in the workshop.

    Of course you cannot compare a small map with larger maps like "Düsseldorf 1981" wich are bigger and therefore also have more tiles and objects.

    Its difficult for developers to decide how detailled their models should be. On the one hand you want to build it as realistic as you can. On the other side there is the (not very good) performence of the game wich limits everything.


    The main problem here is not the question how much details or polys you should use for objects/maps etc. Its the game engine and performence that basically sets limitations for what is possible.

    This problem is not new and if you have played games like Omsi 2 you know thats the game engine what is the main problem.

    Its rediclues that the Lotus engine does not support LODs for some objects. The whole terrain building/editing system seems like its not optimized at all.


    I dont want to blame the Lotus devs or anything. But if a game like Lotus only runs smooth without high polys and with reduced details, then you can ask yourself if that is acceptable for todays standarts.

    Lotus has many good features and also unique features/functions wich other games do not have. But in the end, the performence is very important. Whats the matter of driving a vehicle very every system is simulated just like the real thing but with bad performence?

    Its just sad that a game what could be really good is limeted by a poor engine and performence.

  • Neu erstellte Beiträge unterliegen der Moderation und werden erst sichtbar, wenn sie durch einen Moderator geprüft und freigeschaltet wurden.

    Die letzte Antwort auf dieses Thema liegt mehr als 60 Tage zurück. Das Thema ist womöglich bereits veraltet. Bitte erstellen Sie ggf. ein neues Thema.

    Maximale Anzahl an Dateianhängen: 5
    Maximale Dateigröße: 500 kB
    Erlaubte Dateiendungen: bmp, cfg, ini, jpeg, jpg, lct, ldl, llg, lob, log, lpmtl, lptmt, ltx, pas, pdf, png, railtrack, rar, txt, veh, wav