[pschlik]

Adding extra animation types proved to be smoother than I expected. I can imagine there will be more room to add simulation-driven animations in the future (engine radiator fans and dynamic brake fans come to mind). My very limited testing involved rewiring the mirror animation on an engine to act like brake animations, so I'm not sure these work exactly as expected when given an artistic touch but that's what I need test subjects for (I'm sure there's someone out there who wants to try animating the brakes on their train cars).

Here's the run down:

• Brake Cylinder Animation: Use an animation matrix with a name that begins with ORTSBRAKECYLINDER (if you need multiple animated brake cylinders, names like ORTSBRAKECYLINDER1, ORTSBRAKECYLINDER2, etc will work, this is true of all the shape animations)
• Handbrake Wheel Animation: Animation matrix name beginning with ORTSHANDBRAKE
• Brake Rigging and Brake Shoe Animation: Animation matrix name beginning with ORTSBRAKERIGGING

Use ORTSBRAKECYLINDER for any brake equipment that ONLY moves when the brake cylinder moves and does NOT move when the handbrake is applied (typically, this is the brake cylinder itself, but sometimes the brake cylinder is actuated by the handbrake!)
Conversely, use ORTSHANDBRAKE for any brake equipment that ONLY moves when the handbrake is applied but does NOT move when the brake cylinder moves (typically, this would be the handbrake wheel because the handbrake wheel does not spin when the train brakes apply...looking at you, TSW).
Finally, ORTSBRAKERIGGING is for all the other brake equipment-the things that can be moved by BOTH a handbrake application and automatic brake application (typically, this is the brake levers and brake shoes, but sometimes the brake cylinders fit into this category).

On equipment with disc brakes, you can use these animations to animate brake applied/released indicators too!


There are a few things to consider setting up these animations. For the animations driven by brake cylinder travel (that is, ORTSBRAKECYLINDER and ORTSBRAKERIGGING), the selected animation frame will depend on the simulated brake cylinder travel. This means that you really should use the advanced brake cylinder parameters ORTSBrakeCylinderDiameter and ORTSBrakeCylinderPistonTravel to give reasonable animation in response to the simulation. You can use the animations without the advanced brake cylinder simulation but it may not look as convincing. Now, the values assigned to the animation keys are vital, as the animation key itself represents the amount of brake cylinder travel. So a key value of "8" doesn't mean 8 seconds like in other animations, it means a brake cylinder travel of "8" (the value is normalized, so 8 doesn't actually have units, it isn't a number measured in inches or meters).

The animation values to consider are:

• 0 - brakes fully released, no brake cylinder motion
• 8 - the brakes are applied enough for all slack to be removed from the brake rigging; any brake shoe animation should set the brake shoes to touch the friction surface at the 8 keyframe (after this, the brake shoes should not move, but other components can still move due to flexibility in the rods and levers)
• 10 - the brake cylinder pressure is 50 psi/3.5 bar, this animation should represent the 'normal' amount of brake cylinder travel; note that the animation will run up to the 10 keyframe over 1 second whenever the brakes are applied on trains without advanced brake cylinder simulation (also, for ORTSBRAKERIGGING objects, the handbrake will set the animation to the 10 keyframe)
• 16 - the maximum possible brake cylinder travel allowed in the simulation, occurs around 200 psi brake cylinder pressure (ie: shouldn't ever happen); if your animation looks good up to the 16 keyframe you are good to go for everything the sim throws at your train car

Note that these rules do NOT apply to the ORTSHANDBRAKE animations. Those behave like a normal two-state animation where the keyframes represent time.
Also, there is no need to make an animation that covers the entire range of motion of the brake equipment. If you want something that just shows the brake cylinder extending enough to take up slack and nothing more, then simply don't define any keyframes greater than 8. If you don't think you need 8 individual animation frames, simply skip the keyframes that seem unneeded. OR is smart enough to smoothly animate in between missing keyframes, and will stop the animation when it reaches its maximum value.

[pschlik]

And what I hope is the final feature addition for this round of updates, I have added the ability for the relay valve ratio and inshot to change with freight animations so you can represent another type of load proportioning equipment.

Unlike other load/empty physics settings, it's not realistic for the relay valve ratio to change continuously with the load of the wagon (it's either on or off), so the switchover from empty mode to loaded mode happens automatically at 25% cargo capacity.

Here's an example for a random coal gondola I had. This one uses 50% brake cylinder pressure when empty.

    ORTSMaxBrakeShoeForce ( 31300lb )
    MaxHandbrakeForce ( 32000lb )

    ORTSFreightAnims (
        MSTSFreightAnimEnabled ( 0 )
        WagonEmptyWeight( 28.9t-us )
	
	Comment ( NEW PARAMETERS! )
        EmptyBrakeRelayValveRatio ( 0.5 )
        EmptyBrakeRelayValveInshot ( -15psi )

        ORTSDavis_A ( 87.35lbf )
        ORTSDavis_B ( 0.289lbf/mph )
        ORTSDavis_C ( 0.144lbf/mph^2 )
        ORTSWagonFrontalArea ( 120ft^2 )
        ORTSDavisDragConstant ( 0.0012 )
        EmptyCentreOfGravity_Y ( 1.377 )
        IsGondola( 1 )
        UnloadingStartDelay ( 5 )

        FreightAnimContinuous (
            IntakePoint ( 0.0 6.0 FreightCoal )
            Shape ( COAL_LOAD.s )
            MaxHeight ( 0.0 )
            MinHeight ( -2.2 )
            FreightWeightWhenFull ( 114.1t-us )
            FullAtStart ( 0 )

            Comment ( NEW PARAMETERS! )
            FullBrakeRelayValveRatio ( 1.0 )
            FullBrakeRelayValveInshot ( 0psi )

            FullORTSDavis_A ( 258.5lbf )
            FullORTSDavis_B ( 1.43lbf/mph )
            FullORTSDavis_C ( 0.0504lbf/mph^2 )
            ORTSWagonFrontalArea ( 120ft^2 )
            ORTSDavisDragConstant ( 0.00042 )
            FullCentreOfGravity_Y ( 2.251 ) 
        )
    ) 

Note how I defined the brake shoe force outside of the freight animation block; I don't want the brake force to change depending on the cargo load I want the brake pressure to change instead. Also note that -15 psi inshot, that's typical for American freight cars when empty (remember that "negative" inshot allows pressure to increase to the setting, but then stops increasing until the relay valve provides sufficient pressure to overcome the setting).

For static freight animations, the empty state will use whatever parameters have been set elsewhere in the wag file, but you can still use FullBrakeRelayValveRatio and FullBrakeRelayValveInshot in the FreightAnimStatic block.

[Traindude]

I like what I'm hearing so far, but as I started to retrofit the tender for my one-piece Challenger with the necessary parts, there's one issue that remains -- hierarchies.

Depending on the equipment in question, the levers and rods can be either attached to the vehicle main frame (MAIN) or to a truck (BOGIE). However, for levers and rods that connect a body-mounted component to a truck-mounted component, which part do you parent it to? The body or the truck?

[pschlik]

Whatever looks most convincing. I'm not about to implement inverse kinematics to handle flawlessly connecting rods and pins so there will be clipping or separation in some circumstances.

But I would figure the most visually appealing approach for the rigging components you are thinking of is to attach them to the main body. The thing to consider is that people are more likely to see a rod moving in a way that makes no sense (eg: rotating with the bogie and sticking out of the frame) than they are to notice a rod not moving when it should move.

[Traindude]

 pschlik, on 14 May 2024 - 05:40 AM, said:

Whatever looks most convincing. I'm not about to implement inverse kinematics to handle flawlessly connecting rods and pins so there will be clipping or separation in some circumstances.

But I would figure the most visually appealing approach for the rigging components you are thinking of is to attach them to the main body. The thing to consider is that people are more likely to see a rod moving in a way that makes no sense (eg: rotating with the bogie and sticking out of the frame) than they are to notice a rod not moving when it should move.

Understood. Maybe save the IK stuff for the new shape format discussion, but eventually it'll make animating our models a whole lot more realistic.

[ATW]

This new brake animation is great to have and am starting to like an slowly equip my stock with them. Brake Cylinder spring pressure also plays a good role in this animation. Instead of 4 animations I just use the 0 an 1 and still get smooth results. The higher the last number frame is the shorter the piston travel is. Have not tried the handbrake yet as I am trying to make a good 3d shape or texture for animating chains an latch.

Not big of a deal but multiple key animation for a smoother look don't animate well and decimal key animation don't work.

[pschlik]

ATW, on 04 June 2024 - 08:53 AM, said:

Not big of a deal but multiple key animation for a smoother look don't animate well and decimal key animation don't work.

I think there's some more I can do to make things smoother, and at the same time probably fix decimal keys (I think the current code treats the keys as if they were numbered 0, 1, 2, 3...etc regardless of what you actually typed in, which is why you are getting best results with just a 0 key and a 1 key). Probably something I would have noticed if I actually knew 3D art and animations.

[ATW]

pschlik, on 04 June 2024 - 10:21 AM, said:

I think there's some more I can do to make things smoother, and at the same time probably fix decimal keys (I think the current code treats the keys as if they were numbered 0, 1, 2, 3...etc regardless of what you actually typed in, which is why you are getting best results with just a 0 key and a 1 key). Probably something I would have noticed if I actually knew 3D art and animations.

Yea when I have a decimal as the final frame the Cylinders an Shoes on release is still set out instead of released. With 0 an 1 frames set it seams too much animation half out on a minimum set instead of say 1/4 travel but still smooth. But till then I'm stuck now on the physics side of Brake Cylinder pressures this railroad charts down in their books and am very close to the goal by few pressures.

I am using TSM an manually change the key frames eliminating 0-3 to 0-1 even though whole model has 8 frames for other animations. Later I plan to convert to Blender from scratch.

[pschlik]

Alright so MSTS shapes straight up didn't support decimal animation keyframes, entering in a decimal just rounds down to the nearest integer (in your case, I guess that was zero). Thanks for checking my assumption there, would not have known that didn't work. To account for that, the keyframe values used need to be multiplied, which will break any existing brake animations. I see that some 3D cab views have selected keyframe value 0 for 0% and keyframe value 8 for 100%, so I'll do something similar here. Keyframe 8 will represent the state where brake shoes touch the wheels, 10 will represent the travel at 50 psi, and 16 will be the true maximum (at 200 psi ish) (ie: multiply the numbers I previously said by 10).

This now means that keyframes at 0 and 8 (rather than 0 and 1) are the minimum you'd want to use. Additional keyframes can be added in between 0 and 8 for fine tuning, and between 8 and 16 if you want to show brake cylinder motion beyond a minimum application.

[pschlik]

Have you tried the brake animations again in the last week? I've got a long vacation coming up at the end of this week and I'd like to tie any loose ends with this change before then.

[ATW]

pschlik, on 16 June 2024 - 12:41 PM, said:

Have you tried the brake animations again in the last week? I've got a long vacation coming up at the end of this week and I'd like to tie any loose ends with this change before then.

I got some satisfying results an changes even in the most latest unstable. Using my original animation 0,1,2,3 rather then 0,1 keyframes I have changed it to read 0,8,9,10 and got what I was looking for in minimum BC 10psi then big differences at 10 pound reduction BC 25psi as the animation increases as intended.

Sofar things are looking great for animation. I am going to start trying out handbrake an chain animations and maybe later down the line reserved animations for angle cocks an retainers.

Thanks for your effort at this an all you do!!

[pschlik]

Cool, I might add anglecock animations since that should be pretty trivial two-frame animation where 0=closed and 1=open. Don't see as much value in retainers since those are small, would rather have animations for very visible things like the G/P/R selectors on european stuff...which isn't even simulated so there's nothing to animate.

[ATW]

Yes, retainers are not really important to see even though they have similar sizes as a angle cock.

I'm impressed with the new braking animations and have tried it on handbraking as the next step in my open time. Handbraking though applies shoes faster rather than in slow steps, they also won't be necessary on articulate cars as there are lots more steps an animation rounds to fully applying a handbrake in real life on articulate intermodal.
The more 3D involved the more polys but there is always the LOD options to vanish them 20 feet away from view or alpha blink a texture file for applied/release.

Brake_Rig_Test_Video

[pschlik]

Not bad on the animations! Good to see it working as I had once heard rumblings that some animations wouldn't work unless they were a child of the MAIN object.


Right now, there's not much that can be done about the handbrake animation not matching the brake shoe animation because under the hood the handbrakes instantly move from applied to released, so the animation is already faking it by showing you smooth motion. Wouldn't be too difficult to change the handbrake to take time to apply but that's a bit overkill for just some animations (though if it had gameplay consequences, maybe I would add it...one of my more devious ideas is making all 'manual' train car interactions take as long as they do in real life-have fun waiting an hour for the conductor to set retainers on the entire train!)

Now one animation thing I would want to try in the future, though I don't know if .s files can handle it, is having different animations for the handbrake applying and releasing. A lot of equipment has a lever to quickly release all tension in the handbrake chain instead of spinning the brake wheel in reverse. Maybe that can be done as a second animation type where the first half of the frames are for applying the handbrake, the second half for releasing.

[ATW]

There are certain tricks to the animations and bug cure I had dealt with. Now one animation bug in particular is Motion vs Rotation. I had TMB (Truck Mounted Brake) on this test unit and it doesn't like X (Right an Left motions) while attached child to a bogie so I don't think it's important to view TMB Cylinders unless one wants to stick head completely between bogies. Trick I did for the shoes while child to a bogie is fish for a good axes pivot location that makes it do a good rotation to look like a motion animation and it worked no crashes or glitches.

Handbrake animation for a quick lever release would maybe need a new code or separate trigger but doesn't seem too important but it may be needed some day and a different animation code for chains to reverse animation and handbrake wheel not to. But it's nice the way it is as most times the release lever is stuck for me i just turn the brake wheel in release position just as if it were how mid modern N/A locomotive handbrake wheels with no release lever except those painful older EMD ones that made you crank to so many rounds to apply the handbrake like 50 times like I did last night... good gym work out when to tie them down lol.

MS made a confusing parameter and never seen what it does but what exactly was MS thinking with "NumberOfHandbrakeLeverSteps( 100 )" and can it be finely put to use?