[Csantucci]

The feature is now available also in the official OR release x1.3.1-66.

[ErickC]

Excellent. Is there any chance we can get a similarparameter for the doors and wipers in the 3D cab?

[Csantucci]

While I may see the need for the wipers, I'm not able to see the need for the doors, that haven't a periodic animation.
Re wipers, you may create a Trello box and we'll see the feedback from community and OR management team.

[ErickC]

The reason for the doors, as I've outlined before, is that to get a smooth brake lever animation, we need to use a lot of frames - around 100. The problem is, the door needs to cycle through the entire animation before it will close, which can take upwards of 3 minutes at 1 FPS, which makes it impossible to synchronize the doors with the audio. Wipers have the same problem. This is why I don't animate wipers or doors in my 3D cabs. If I have to choose between operating controls and eye candy, I choose the controls.

[Traindude]

Sorry to bump the thread but I have some ideas on how bell animation in OR can be improved.

1) In the demonstration video posted earlier in this thread, the bell moves between keyframes at an even rate of speed. In reality, the bell would need to accelerate at the start of its stroke (in either direction), and decelerate as it nears the end of the stroke. The same can be said when the bell moves into or out of its rest position. Therefore, there needs to be a way for OR to treat the animation timing so that the bell "slows Out" and "slows in" (which by the way, is animators' speak for "acceleration" and "deceleration", respectively) between keyframes.

2) Someone in an earlier post mentioned that in low-framerate conditions, the bell animation appears out of sync when used with an existing "looped" .wav file. One potential way to compensate for this is to modify the way the bell stream works in the SMS so that instead of using a pair of discrete triggers to start and stop a looped .wav file, a new set of discrete triggers is established, corresponding to the "extreme forward" and "extreme backward" keyframes. These would be used in conjunction with a .wav file comprising of a single "ding" sound that would be played "in one shot" every time the bell reaches the extreme forward or backward key frames, theoretically making it impossible for the animation and sound to go out of sync, regardless of frame rates.

I think before we start thinking of animation for stationary bells with internal clapper-type pneumatic ringers (a la diesels), we need to get swinging bells working convincingly. I hope my logic makes sense...I just wish I knew how to code!

[markus_GE]

Some thoughts that came to my mind reading the following snippets:

 Traindude, on 16 September 2020 - 06:15 PM, said:

1) In the demonstration video posted earlier in this thread, the bell moves between keyframes at an even rate of speed. In reality, the bell would need to accelerate at the start of its stroke (in either direction), and decelerate as it nears the end of the stroke. The same can be said when the bell moves into or out of its rest position. Therefore, there needs to be a way for OR to treat the animation timing so that the bell "slows Out" and "slows in" (which by the way, is animators' speak for "acceleration" and "deceleration", respectively) between keyframes.

IOW, you'd like to see it work like a pendulum, which, in a very simplified way, is how bells actually work (of course, the "swinging-and-dinging" action of the clapper will disturb the purely-pendulum-like motion of the bell's body, but that should be negligible).

 Traindude, on 16 September 2020 - 06:15 PM, said:

2) Someone in an earlier post mentioned that in low-framerate conditions, the bell animation appears out of sync when used with an existing "looped" .wav file. One potential way to compensate for this is to modify the way the bell stream works in the SMS so that instead of using a pair of discrete triggers to start and stop a looped .wav file, a new set of discrete triggers is established, corresponding to the "extreme forward" and "extreme backward" keyframes. These would be used in conjunction with a .wav file comprising of a single "ding" sound that would be played "in one shot" every time the bell reaches the extreme forward or backward key frames, theoretically making it impossible for the animation and sound to go out of sync, regardless of frame rates.

I don't really know much about sound programming, but I got some experience in messing with SMS files. Specifically, if you trigger a sound on a stream before the previously triggered sound on the same stream has finished playing (IE, when sounds overlap on one stream), two things can happen: Either, the previously played sound is aborted and the new one played, which would make the intended bell sound more akin to wood chopping than a bell, in my imagination. Or, the sounds are queued, and newly triggered one is only played when the previous WAV file has "timed out". The latter would again translate into a slower ding-dong cycle than the animation would dictate, but therefore i would also continue playin once the animation has stopped, for as long as it takes to "remove" the queue. IDK which one is true for ORTS nowadays, sine my messing with SMS files has taken place a few years back already, when I was still using both MSTS and ORTS at the same time. Somebody else will likely be able to clarify on this.

Just some points to be considered.

Cheers, Markus

[Csantucci]

Re point 1): the angular speed of the bell depends on how its animation is defined in the .s file. It is possible to define such animation in the .s file so that the angular speed is higher in the central part of the swing and lower in the extremes. So there's no need to change things in OR here.
Re point 2): adding two new triggers (only one triggering at both extremes is indeed enough) is a possibility; however this requires always modifying the .sms file and modifying the .wav file when it contains more than one ding. So it's not so much different, in terms of time needed, from modifying only the .wav file so that it has a duration that is in sync with the visual animation.

[Traindude]

Okay, I've done some tests with a test model, but I am unsure how the keyframes for the bell are supposed to be created--I know I need a center, forward and backward positions, but, how do I adjust the keyframes for to get the bell to animate correctly.

Here is my setup:

Frame 0:Center Position
Frames 1-7: Center to Forward for a pendulum effect
Frame 8: Forward Position
Frames 9-15: Forward to Backward for a pendulum effect
Frame 16: Backward Position
Frames 17-23: Backward to Center for a pendulum effect
Frame 24: Center Position

However, when I tested this arrangement in-game, I get an exact loop of Frames 0-24, which makes it look like the bell is stopping in its center position even though the bell hasn't been turned off.

What am I doing wrong?

[scottb613]

 Traindude, on 23 September 2021 - 10:04 PM, said:

Okay, I've done some tests with a test model, but I am unsure how the keyframes for the bell are supposed to be created--I know I need a center, forward and backward positions, but, how do I adjust the keyframes for to get the bell to animate correctly.

Here is my setup:

Frame 0:Center Position
Frames 1-7: Center to Forward for a pendulum effect
Frame 8: Forward Position
Frames 9-15: Forward to Backward for a pendulum effect
Frame 16: Backward Position
Frames 17-23: Backward to Center for a pendulum effect
Frame 24: Center Position

However, when I tested this arrangement in-game, I get an exact loop of Frames 0-24, which makes it look like the bell is stopping in its center position even though the bell hasn't been turned off.

What am I doing wrong?

Hi...

I'm not sure why you need so many frames - I'm doing mine at 16.

Position 0, 8, and 16 are in the neutral position as shown. Smooth as silk.

The animation panel is on the bottom with each little blue dot representing a key frame.

Use the SD file to control timings with your audio.



Regards,
Scott

[Traindude]

 scottb613, on 24 September 2021 - 06:08 AM, said:

Hi...

I'm not sure why you need so many frames - I'm doing mine at 16.

Position 0, 8, and 16 are in the neutral position as shown. Smooth as silk.

The animation panel is on the bottom with each little blue dot representing a key frame.

Use the SD file to control timings with your audio.

Image1.jpg

Regards,
Scott

Thanks. I reduced the number of keyframes and I retested it, but then I found what was causing the unusual movement.

Originally, I wanted to show the bell accellerating from mid-position when the bell was first turned on, and decelerating to mid-position when the bell was turned off, but then I realized that OR doesn't work that way. So I modified the action curve using Blender's graph editor, eliminating the acceleration from and deceleration from mid-position, but keeping the acceleration and deceleration at the forward and backward positions.



Here's the Blender curve editor showing the result of my experiments. It would be nice if OR had a way of showing the acceleration and deceleration of the bell around mid-position when it's turned on and off, but that's a lot more work that needs to be done.