[Eldorado.Railroad]

pschlik, on 20 January 2025 - 08:33 AM, said:

One of my goals for 2025 is to add a completely new electrical simulation for DC motors,..

What we would not like to do is put the "cart before the horse here". Yes, the minutiae can be exquisitely complex and interesting to simulate. I am a big fan of precise and correct simulations. I know that from a physics(as in the study of) background that what happens in the real world varies widely. That is where engineers come in, with all of our rules of thumb and fudge factors and margins for error.

But Carlo (from what I read) here is looking for an expedited way to implement the animations. If we go "into the weeds" with a ton of expectations and electro-mechanical formulae this aspect is going to become stillborn. I have already cited that certain aspects right now are ersatz, BUT with time those can be refined. I vote to get the animations working FIRST, then with all things OR, progressively move towards "authentic/realistic" simulation. Doing it in that way will assure that the animation code gets implemented as opposed to getting choked off with a multitude of parameters that a only a handful of people here understand, let alone would know what to plug into an .eng file to perform EXACTLY what is seen in the real world.

Things can/will get REALLY messy and complicated when we start calculating thermo-dynamics, copper losses, IR losses, semiconductor losses, etc. We just at this time want get some fans turning.

Thanks,
Steve

[Weter]

Thanks, Cesar.
So it can't be applied to EMUs now.

Hello, Steve.
Sounds very reasonable. But without adequate power consumption model (that's how I understand Phillip's phrase, quoted by You) - we couldn't get adequate fan's behaviour. It might be simple for beginning, certainly.

[vapor3D]

Regarding the fans, does what is explained in the Manual work for anyone?:

15.1.21. Cab controls for generic items

"The default animation speed for stopped/moving type animations is 8 FPS. It may be modified with following parameter in the .sd file:"

ESD_CustomAnimationSpeed ( 8 )

Even if you change that number, in the case of a part named:

ORTS_ITEM1CONTINUOUS:0:3 for example, even if you change this ESD parameter, the speed is always the same... What am I doing wrong? Thank you...

[Csantucci]

There is an error in the manual, sorry. The correct entry is

ESD_ORTSCustomAnimationFPS ( 8 )

I've created a PR with the correction of the manual.

[vapor3D]

Csantucci, on 27 January 2025 - 01:32 AM, said:

There is an error in the manual, sorry. The correct entry is

ESD_ORTSCustomAnimationFPS ( 8 )

I've created a PR with the correction of the manual.

Thank you very much Carlo. The thing is that I have changed it to both (64) and (2) and nothing, the speed remains exactly the same. There is something else I must not be doing right...

[Csantucci]

OK, I see. At the moment the possibility of having a custom animation speed is available only for locomotive shape items, and not for locomotive 3Dcab shape items.

[Jonatan]

Oh so that's why I can't adjust the speed of the water hatch on my tenders... :rofl2:

[vapor3D]

Csantucci, on 28 January 2025 - 02:06 AM, said:

OK, I see. At the moment the possibility of having a custom animation speed is available only for locomotive shape items, and not for locomotive 3Dcab shape items.

Thanks again Carlo. At least, I am comforted to know that the "problem" was not my mistake. Let's see if someday it will be possible to achieve this...

[gpz]

Eldorado.Railroad, on 19 January 2025 - 07:29 AM, said:

I would not try to conflate the two. AFAIK MSTS animations will continue to function and gITF animations are a separate issue. When and where gITF animations are implemented remains to be seen, "hope springs eternal". I would not want to see MSTS animations deleted. As of this writing freight animations have been working in OR for some years now, and work perfectly. Throwing the MSTS freight animations away and even the MSTS shape file away in OR would be a fools errand. Not to mention all the support files which explicitly site ".s" references to the MSTS shape file.

It is clear that legacy MSTS shape/animations have to remain. UNLESS there is a fool proof method of translating MSTS shape/animations to gITF a symbiotic relationship will have to be added to OR to effectively allow BOTH types of shapes/animations. With this in mind the full implementation of gITF has for the mean time stalled. We would all like to see the upgrade to this format, but only if all of the "old" content is NOT trashed in the process. Something that OR can ill afford to do.

The gltf and msts animations can happily live together. The implemented gltf animations just gently settle onto the existing animation actuator, with a possibility to assign existing msts names to gltf animations. If I understand correctly, this is exactly what others may not like about it, they would like to see more breaking changes, this is why the whole thing stalls for three years.

[Weter]

Hello.
Having many instances, where some parts (shafts, sheaves, belts, fans, etc.) are being driven by prime mover and visible on interior or even exterior views, that would be good improvement, have we an animation's class, with frame rate, tied to current motor's speed. So, it can be seen properly, when motor is stopped, idling, or running on full throttle.

What devs can answer?
Waiting we for glitf support, at least this idea could be recorded for reference, or even added to Trello, in case that's still actual.

[rfranzosa]

Weter, on 19 April 2025 - 09:22 AM, said:

Hello.
Having many instances, where some parts (shafts, sheaves, belts, fans, etc.) are being driven by prime mover and visible on interior or even exterior views, that would be good improvement, have we an animation's class, with frame rate, tied to current motor's speed. So, it can be seen properly, when motor is stopped, idling, or running on full throttle.

What devs can answer?
Waiting we for glitf support, at least this idea could be recorded for reference, or even added to Trello, in case that's still actual.

That would be great. We have had diesel locomotive fans that rotate since MSTS, but they move at the speed of the wheels.

[pschlik]

I'll be giving diesel engines some attention soon ish (but probably not before 1.6), and I already figured a diesel 'crankshaft' animation (doesn't have to be the crankshaft itself, just anything attached to the crankshaft) would be very easy to implement and helpful in a lot of situations. There's a lot more I want to do as well, like a much better cooling system simulation with the ability to animate fans and shutters individually based on the state of the simulated components (animations matching simulation is always fun).

Honestly, I don't know what's up with gltf and animations other than something (what this 'something' is I haven't a clue) needs to be decided, so I am fully willing to wing it and throw more animations in (I have already done this before, it is too late to stop me doing it again).

[gpz]

pschlik, on 21 April 2025 - 09:52 AM, said:

Honestly, I don't know what's up with gltf and animations other than something (what this 'something' is I haven't a clue) needs to be decided

In my opinion nothing is up with it, it is ready to be merged. I honestly don't understand the concern about specifically the animation implemented in gltf. If I'd be the reviewer, I'd focus more on the lighting/shader part, since that one is a much bigger change with a much bigger impact. (@mention ORMT here)

[Weter]

Hello, Phillip.
I like Your approach! Thanks for that.

[Jonatan]

Diesel animations that move when the engine is turned on and running would be very nice additions, such as radiator fans and exhaust cover flaps for industrial locos.
Or anything that moves on a prime mover in general.

The more animation features, the better.