[wellsburg]

Hi,
My bell animation is 8 positions over a 16 step animation. Overall loco animation is 16 60. It works fine.

The pull rope is a separate animation also named ORTSBELL.
Bell sound is from an unknown source and labeled HeislerBell44 and XHeislerBell44. Matches animation well.
Thanks for adding this neat feature to MG 22.

Mike

[Csantucci]

Good to read that the feature draws interest and works.
Blueprint created at https://blueprints.l.../bell-animation .

[mrmosky]

Hi Carlo,

Is it ok for me to use the bell sound that you used for another model?

Geoff

[Csantucci]

Hi Geoff,
no problem from my side. However I derived such sound by cutting part of the bell file included in pack upsteam.zip, downloadable from Trainsim. Therefore maybe you should also ask the original author(s). In the readme of the pack you find some names.
Or, if you have another bell sound where you have or get copyrights, I can see if it can be adapted.

[mrmosky]

Thanks Carlo.

[scottb613]

Hi Folks,

OK - yes - very cool addition and adds a great deal of additional visual interest - I like it...

My bell is a tad too fast and I tried to slow it down - I couldn't get it work and when I attempted Carlo's fix really strange things happened - I'm probably changing the wrong values...

I animated the entire locomotive at 16 Key Frames - as I always do - including the bell... In order to get the drivers to rotate correctly - I run it through Shape Fixer to correct the animation speed...

Here is the animation setting after my export - the bell looks right but the drivers are way too slow:

	animations ( 1
		animation ( 16 30
			anim_nodes ( 33
				anim_node MAIN (
					controllers ( 0
					)
				)

Here is the animation setting after Shape Fixer - the drivers rotate correctly but the bell is too fast:

	animations ( 1
		animation ( 16 60
			anim_nodes ( 33
				anim_node MAIN (
					controllers ( 0 )
				)

Here is the bell setting - I tried multiplying the first value (second column parameter) by 4 - and that messed it up big time:

				anim_node ORTSBELL (
					controllers ( 1
						tcb_rot ( 17
							slerp_rot ( 0 0 0 0 1 )
							slerp_rot ( 1 0.1132503 2.103091E-09 0 0.9935665 )
							slerp_rot ( 2 0.225038 8.467846E-09 0 0.97435 )
							slerp_rot ( 3 0.3339289 1.927337E-08 0 0.9425983 )
							slerp_rot ( 4 0.4380681 3.477986E-08 0 0.8989418 )
							slerp_rot ( 5 0.3339349 1.92741E-08 0 0.9425961 )
							slerp_rot ( 6 0.2250526 8.468976E-09 0 0.9743466 )
							slerp_rot ( 7 0.1127874 2.085827E-09 0 0.9936191 )
							slerp_rot ( 8 0 0 0 1 )
							slerp_rot ( 9 -0.1132338 2.102473E-09 0 0.9935684 )
							slerp_rot ( 10 -0.2245316 8.42877E-09 0 0.9744668 )
							slerp_rot ( 11 -0.3339042 1.927034E-08 0 0.942607 )
							slerp_rot ( 12 -0.4380317 3.477341E-08 0 0.8989595 )
							slerp_rot ( 13 -0.3338864 1.926815E-08 0 0.9426134 )
							slerp_rot ( 14 -0.2250109 8.465758E-09 0 0.9743562 )
							slerp_rot ( 15 -0.1132259 2.102181E-09 0 0.9935693 )
							slerp_rot ( 16 0 0 0 1 )
						)
					)
				)

Are these the correct values ?

How would I slow this down a bit ?

Thanks...

Regards,
Scott

[scottb613]

Hi Folks,

Disregard - DOH - it was late while I was working on it - when Carlo said the first value - he meant the first value - for some reason I was thinking he meant the second column where the animation positions are defined...

For my model - multiplying the FIRST column (key frame number) by 2 - setting them at a total of 32 - seems spot on...

All better now...
:)

Bell code that works for me:

				anim_node ORTSBELL (
					controllers ( 1
						tcb_rot ( 17
							slerp_rot ( 0 0 0 0 1 )
							slerp_rot ( 2 0.1132503 2.103091E-09 0 0.9935665 )
							slerp_rot ( 4 0.225038 8.467846E-09 0 0.97435 )
							slerp_rot ( 6 0.3339289 1.927337E-08 0 0.9425983 )
							slerp_rot ( 8 0.4380681 3.477986E-08 0 0.8989418 )
							slerp_rot ( 10 0.3339349 1.92741E-08 0 0.9425961 )
							slerp_rot ( 12 0.2250526 8.468976E-09 0 0.9743466 )
							slerp_rot ( 14 0.1127874 2.085827E-09 0 0.9936191 )
							slerp_rot ( 16 0 0 0 1 )
							slerp_rot ( 18 -0.1132338 2.102473E-09 0 0.9935684 )
							slerp_rot ( 20 -0.2245316 8.42877E-09 0 0.9744668 )
							slerp_rot ( 22 -0.3339042 1.927034E-08 0 0.942607 )
							slerp_rot ( 24 -0.4380317 3.477341E-08 0 0.8989595 )
							slerp_rot ( 26 -0.3338864 1.926815E-08 0 0.9426134 )
							slerp_rot ( 28 -0.2250109 8.465758E-09 0 0.9743562 )
							slerp_rot ( 30 -0.1132259 2.102181E-09 0 0.9935693 )
							slerp_rot ( 32 0 0 0 1 )
						)
					)
				)

Regards,
Soctt

[James Ross]

Csantucci, on 23 May 2019 - 12:35 AM, said:

Re Jared's request to make available the possibility of setting the bell oscillation frequency in the .eng file, I see its rationale, but from an architectural point of view I don't like that parameter in the .eng file; therefore I'd prefer to read a word of James about this. Implementing it would be simple, because the parameter already exists in the code, where it is hardcoded; when the parameter in the .eng file would be absent, a default value would apply. Adding the management of .eng parameter can also be developed in a second phase.

I'm not entirely sure if we still need this parameter for the bell, and I would agree that it is not really an engine (.eng) parameter but more of a shape one. The Shape Description (.sd) file might make sense but be harder to code? If the SD file isn't easy, let's do this feature with a fixed speed first and then figure it out.

Csantucci, on 24 May 2019 - 11:33 PM, said:

Good to read that the feature draws interest and works.
Blueprint created at https://blueprints.l.../bell-animation .

Blueprint and road-map linked and approved for 1.4.

[jared2982]

James Ross, on 26 May 2019 - 12:24 PM, said:

I'm not entirely sure if we still need this parameter for the bell, and I would agree that it is not really an engine (.eng) parameter but more of a shape one. The Shape Description (.sd) file might make sense but be harder to code? If the SD file isn't easy, let's do this feature with a fixed speed first and then figure it out.

It is indeed a nice feature and hope that in the future it can added as a parameter in some file other than the shape file for adjusting the speed. While most of us modelers are familiar with editing the shape file in some instances there are those that are not. It might also be useful for a more advanced end user to be able to adjust the speed of this animation when changing to a different sound file for the bell when they are not comfortable editing a .s file.

[Csantucci]

I have now created a GitHub PR, and have added to the .sd file the optional parameter ESD_ORTSBellAnimationFPS, that allows to define the FPS for the bell animation. If the parameter is missing, 8 FPS are used.

[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!