[Traindude]

Hi everybody. In an attempt to overcome the limitations of the MSTS-era models, I began thinking of an alternative method of defining wheels, axles and bogies/trucks for locomotives and rolling stock. Some of the goals I am trying to achieve include:

• Defining wheels and axles based on *.wag and *.eng data rather than shape file hierarchy, preventing ORTS from making false assumptions about a vehicle's wheel arrangement
  
• Specifying correct axle count by elimination of other animated parts that are treated as axles (example: diesel locomotive radiator cooling fans)
  
• Allow idler/non-powered axles to be parented directly to a vehicle frame, eliminating the need for "dummy" or "invisible" bogies/trucks
  
• Specifying rigid wheelbase parameters for each individual truck/bogie or group of axles
  
• Clarify uneven axle spacing within a group of 3 or more axles
  
• Allowing idler wheels of different diameters (example: steam locomotives)
  
• Clear distinction between individually driven and mechanically connected groups of axles for locomotives other than steam
  
• Distribution of weight on an axle-by-axle basis
  
• Braking parameters (brake force, shoe type, etc) applied on an axle-by-axle basis
  
• Allowance for lateral-motion axles and blind/flangeless wheels

So far, this is only a partial list of potential new parameters, there's obviously a whole lot more that can be explored. However, I am providing this as a jumping-off point of sorts for further expansion.

What do you guys think? Let me know!

Attached File(s)

•  ortswheelsaxles.pdf (1.77MB)
  Number of downloads: 132

[Laci1959]

Helló.

Quote

Allow idler/non-powered axles to be parented directly to a vehicle frame, eliminating the need for "dummy" or "invisible" bogies/trucks

If the OR accepts the one i.e. 1-axis bogie, where we can enter the pivot points of the bogies separately, then it will be good.
The steam locomotive shown in picture 1 has two Adam-Webb system one-axle bogies which are offset by 1650mm. It is clearly visible that the front and rear axles are not attached to the chassis.
https://kephost.net/p/MTI3MTgzNw.jpg

Quote

Clarify uneven axle spacing within a group of 3 or more axles

If it's optional, that's fine. See picture #2.
https://kephost.net/p/MTI3MTgzNg.png

[Traindude]

Laci1959, on 11 July 2024 - 12:30 AM, said:

Helló.
If the OR accepts the one i.e. 1-axis bogie, where we can enter the pivot points of the bogies separately, then it will be good.
The steam locomotive shown in picture 1 has two Adam-Webb system one-axle bogies which are offset by 1650mm. It is clearly visible that the front and rear axles are not attached to the chassis.
https://kephost.net/p/MTI3MTgzNw.jpg

Thanks for the suggestion!

Laci1959, on 11 July 2024 - 12:30 AM, said:

If it's optional, that's fine. See picture #2.
https://kephost.net/p/MTI3MTgzNg.png

Yes, it will be optional for the time being. However, when we get into more advanced stuff, then it will be critical.

Say, for example, we want to implement track joint and switch (points) sounds that synchronize with the axle count and spacing on the vehicle (a la TS20xx, which, incidentally, is how my proposal originated within a private conversation with some of the guys on this forum). If we want to synchronize the joint and switch sounds to the actual axle count, then it is critical that ORTS needs to know if the spacing between a group of 3 or more axles is even or uneven, as the spacing of the axles will affect the sound timing, especially at lower speeds.

Here's a GIF I made demonstrating the axle count-syncronized track joint sounds.

[Genma Saotome]

Interesting.

Sanjay, what is gained with this proposal? Will it fix the problem of having to break up a locomotive model that has several driving engines?

[Traindude]

Genma Saotome, on 11 July 2024 - 10:47 PM, said:

Interesting.

Sanjay, what is gained with this proposal? Will it fix the problem of having to break up a locomotive model that has several driving engines?

Yes. In my document, I give an example of a Northern Pacific Z8 Challenger. It's assuming the whole locomotive (minus the tender, of course) is a one-piece model. I've also given two non-steam articulated examples, both Pennsylvania Railroad electric locomotives -- the famous GG1, as well as the older DD1. Both are assumed to be one-piece models. Other articulated electric locomotives (example: Milwaukee Road's Box Cabs and Bi-Polars) would be treated similarly.

[Laci1959]

Genma Saotome, on 11 July 2024 - 10:47 PM, said:

Interesting.

Sanjay, what is gained with this proposal? Will it fix the problem of having to break up a locomotive model that has several driving engines?

This is an old problem. OR starts from the fact that each bogie has only two axes, and it does NOT read the pivot point from the shape file, but calculates it. This is already a problem with three-axis bogies. And there are plenty of vehicles using single-axle bogies. Another problem, for example, is the unrealistic appearance of vehicles with an A1 axle arrangement when grinding.
.
Perhaps this development will also provide a solution for the virtual bogie in the field of railway vehicles using the Jacobs bogie.

[Weter]

Hello.
By the way, some steam locomotive have idler wheels of 2 or even 3 different diameters.
MSTS/ORTS now support only one for drivers and one for all idlers, so animated rotation speed will be incorrect for the rest diameter wheels, except one.

More, though I don't know details, car (*.wag) can't contain animation of more, than 4 wheel pairs. So models of 8-axle tankers are defined through *.eng-files of zero power diesel locomotive.

[copperpen]

Weter, on 12 July 2024 - 09:25 PM, said:

More, though I don't know details, car (*.wag) can't contain animation of more, than 4 wheel pairs. So models of 8-axle tankers are defined through *.eng-files of zero power diesel locomotive.

That was/is the case for MSTS. Far as I know, OR can handle 4 axle per bogie and more than two bogies per vehicle.

[Laci1959]

copperpen, on 13 July 2024 - 02:52 AM, said:

That was/is the case for MSTS. Far as I know, OR can handle 4 axle per bogie and more than two bogies per vehicle.

Yes, that's true, he just doesn't handle it well. It does not take into account the pivot point specified by the modeler in the shape file, but calculates it, of course incorrectly. It still calculates well with two axes. It no longer calculates well with three or four axes. And, of course, there are swivel stools that do not have the pivot point in the middle, but are offset.

[Weter]

That's interesting: I would try and see, could it work right, using wag-file.

[Traindude]

I would also like to add that my proposal also facilitates alternate naming of wheels and axles (so we aren't bound by the current constraints). In the 1910s in the United States, there were some very...interesting to say the least...articulated locomotives with 10 or more driving axles...

Example # 1: Santa Fe 3000-class 2-10-10-2:
https://loco.skyrocket.de/img/atsf__3000__3000__1.jpg



Example # 2: Erie Triplex 2-8-8-8-2:
https://loco.skyrocket.de/img/erie_p1.jpg


You'll notice in both examples, I treated the 10th, 11th and 12th driving axles in a hexadecimal manner. So we could potentially have up to 16 drive axles if we wanted.

[cjakeman]

Traindude, on 10 July 2024 - 01:03 PM, said:

Hi everybody. In an attempt to overcome the limitations of the MSTS-era models, I began thinking of an alternative method of defining wheels, axles and bogies/trucks for locomotives and rolling stock. Some of the goals I am trying to achieve include:

Are there any objections to TrainDude's proposal?

Does it cover all cases we know of?

[Eldorado.Railroad]

cjakeman, on 20 July 2024 - 02:40 AM, said:

Are there any objections to TrainDude's proposal?

Does it cover all cases we know of?

From what I can see in the O/P, we are going to "wheels within wheels", as far as animation parlance is concerned!!

Whereas, in a cursory way I can see what this change is trying to accomplish, I can also see a huge mess of work for the modeller to get things to animate properly.

So three points here:

1) I have models that do use the builtin pre-animated names to animate things like fans. Are those animations going to be broken with these changes and why?

2) Given 1) I hope, really hope, that this new way of doing things is SEVERELY tested before we decide to put it in production, where bugs will break, what was already working..for well over a decade. It is tiresome to have new features added to OR that breaks what was working well after it has been decided that it was going to be included in the mainline code. I am sure I am not the only one holding back on using newer releases as it severely disrupts users workflows.

3) Also connected to 1), as an example cooling fans, if you are willing to put in all that work to simulate animations of bogies and wheels in the .eng file, why not add animations for cooling fans, dynamic brake fans, that are triggered ON/OFF etc by parameters in the .eng file?

I have a lot of model work that used the old ways of doing things, which I would not like to end up in the garbage with these changes. Some payware vendors are still having trouble with the old ways of doing things with the Blender exporter, so I have seen/noted! Getting them to do stuff in the new ways will be a bit of a stretch. A utility to streamline the entry of the NEW parameters in the .eng file will make life easier for the few payware modellers we have left. Hobbyists will struggle with these new parameters for a great deal of time.

thanks,
Steve

[Laci1959]

Hello.

I read the description once again (it has to be translated, and it goes slowly), and I add two Hungarian locomotives. What I can already see is that the definition of the pivot point of the bogies is missing. ORTSLengthBogieCentre is only acceptable if the vehicle has a perfectly symmetrical structure. I think that in some cases it is necessary to define the center of the bogies individually in the Bogie ( ) block. Let's not fall into OR's current mistake.
In Hungary, unfortunately, the minutes of the factory weighing are not available in all cases. In this case, if ORTSWheelWeight is missing, it uses the value of the currently used ORTSDriveWheelWeight ( ) and ORTSNumberDriveAxles ( ) line, if specified.

Sincerely, Laci 1959

[pschlik]

Eldorado.Railroad, on 20 July 2024 - 06:02 AM, said:

3) Also connected to 1), as an example cooling fans, if you are willing to put in all that work to simulate animations of bogies and wheels in the .eng file, why not add animations for cooling fans, dynamic brake fans, that are triggered ON/OFF etc by parameters in the .eng file?

I have some general improvements to the diesel engine model that are required before we start to consider things like electric motor simulation, and a rework of engine cooling would be part of that so there is sufficient information to trigger animated fans. This would come along with naming changes that would allow these to not be confused with wheels.

In terms of supporting older models which did define fans as wheels, we'd benefit from some .eng parameters to allow manipulating the shape file from the .eng file so users don't need to uncompress and manually edit shapes as much. Something like "ORTSReplaceHierarchy( "ROD01, RADIATORFAN1" )" to tell the shape file (in code, not in real life) to rename the relevant object, and the rest of the program will be none the wiser that the radiator fan was originally implemented as a connecting rod. (Similar could be done for shape textures to make reskins easier, I'm sure many people out there would much rather not do shape file editing for a pack of 20 reskins!)