[RTP]

A max number of frames can be 16, but that is not sure.

Regards.

[captain_bazza]

On reflection, the "jiggle" factor might have something to do with tension on the panto' unit caused by the tensioning springs you see at the base of the four arms, more detailed on some good quality electric locos an EMU models. The springs tension the panto' crosshead pickup bar against the power cable and cantenary support structure.

The release of physical energy while raising the heavy panto' unit, and the sudden stop, would expend some energy back to the spring tensioners, hence the apparent "bounce" effect.

CB.

[Eldorado.Railroad]

RTP, on 15 November 2017 - 05:44 PM, said:

A max number of frames can be 16, but that is not sure.

A bit more than that:
Are we ready yet? Animating things independent of locomotive movement

[ErickC]

captain_bazza, on 13 November 2017 - 07:49 PM, said:

There is a method to control the speed to make the sequence playback slower by an edit in the ENG file, however, it sets the playback speed for every animated part in the ENG file.

Cheers Bazza.

Would you mind elaborating? OR has a nasty bug where the doors and wipers in the cab have to cycle through the entire number of keyframes, but the only way to get smooth brake lever animations is to use a lot of frames, which means that, if you use 100 frames, for example, a single cycle of the door or wipers takes about a minute and a half (100 seconds). If I could just specify a 100-frame cycle for doors and wipers, then speed the cycle up, that would solve the problem nicely.

[captain_bazza]

"....slower by an edit in the ENG file...."

Sorry, my mistake, I meant the S (SHAPE) file.

However, I always manually processed the .3DS (model format) file to uncompressed .S file. An uncompressed .S is in unicode text, thus can be edited in a suitable unicode capable text edit, such as conTXT Editor.

The animation section is the last section of the shape file.

An uncompressed unicode text shape file will work okay in MSTS and used to in OR (still does?). This is useful for testing in the sim.

You must be very careful when working at editing the shape file, so keep a spare original copy away from your work folder.

Another however, some exporters from program format to shape format might automatically produce a compressed binary shape file, unless there is the option to export in uncompressed format........

[captain_bazza]

.....No one has written a comprehensive Manual for MSTS and OR Modelling.

You require:

A good understanding of reading 2d plans and translating that into 3d space.

A good understanding of 3d modeling and your particular 3d modeling software.

A good understanding of graphic texture, producing them and applying them in the modeling program. Also, then converting them to a format for MSTS and/or OR.

......

[ErickC]

We have to uncompress our shapes and edit our part names to get the controls working, so I'm pretty familiar with the basic format of the shape; but I have no idea how to change the framerates at all. As it stands, I can make a wiper or door that opens at the rate I want, but then stays open until the entire 100 frame animation cycles - which can take as long as three minutes - or use the full 100 frames I need for my brake levers and have animations that are painfully slow. At the present, it seems like the best compromise might be to leave my wipers fixed (which could probably save on a drawcall or two in the meantime, I suppose).

[ErickC]

Anyone? Bueller? Bueller?

[captain_bazza]

Great movie!

CB.

[Jovet]

I've never made an engine/locomotive, but if all of the continuous animation is linked to the same framerate, it seems to me that the best solution which can be done right now is to "scale" the number of frames to the thing that needs the most, and have the lesser items just repeat their keyframes as needed to fill in.

[captain_bazza]

RTP, on 14 November 2017 - 04:34 PM, said:

I disagree.
For instance, the upper arm of a pantograph moves and rotates simultaneously.
In my experience, three frames animates a door with correct speed, but six allows for a panto, with some overshoot, like the real ones.

Regards.

Re panto. Correct, but the 'up & down' movement is happening because the panto' arms are "rotating (x° degrees). Thus the scissor like open and shut movement raises and lowers the panto' as a limited or partial rotation.

Cheers Bazza.

[diceros]

Hi

I spent hours of testing various values in the „animations/ animation“ section of the s.file and I came to the conclusion that OR seems to ignore the frame rate as defined there. My problem is that animations of pantographs and doors are unrealistically slow when using the default values (16 60). In MSTS increasing the frame rate in the shape file made all animations faster in the simulation including the wheels. To correct wheel speed I changed the value „wheelradius“ in the .eng- file which of course is a rather dirty method (but with the simple physical model of MSTS I did not notice any side effects).

So I wonder if there is an easy way to individually accelerate or slow down animations within a complex shape file.

Any help would be appreciated

Thanks

Stefan

[RTP]

To do it, include-exclude frames.
For a door a good number is three (four for a complex mouvements)
For a panto, three-four to nine; a modern, pneumatic panto is usually slover than a older, spring actuated one.

Regards.

[diceros]

Thanks for your reply.

I thought I was doing just this (excluding frames), but probably not right... My original animation setup (uncompressed shape file) was as follows (4 frames for the door animation):


----------------------------------------------
animations ( 1
animation ( 16 60
anim_nodes ( 24
anim_node MAIN (
controllers ( 0 )
)
...

anim_node DOOR_A (
controllers ( 2
tcb_rot ( 4
tcb_key ( 0 0 0 0 1 0 0 0 0 0 )
tcb_key ( 1 0 0 0 1 0 0 0 0 0 )
tcb_key ( 2 0 0 0 1 0 0 0 0 0 )
tcb_key ( 4 0 0 0 1 0 0 0 0 0 )
)
linear_pos ( 4
linear_key ( 0 0 0.04 -0.25 )
linear_key ( 1 0.0399998 0.04 -0.269085 )
linear_key ( 2 0.0404456 0.04 -0.393085 )
linear_key ( 4 0.0399998 0.04 -0.957116 )
)
)
)

----------------------------------------------

Changing the frame numbers as in the following example did not change anything


----------------------------------------------
anim_node DOOR_A (
controllers ( 2
tcb_rot ( 4
tcb_key ( 0 0 0 0 1 0 0 0 0 0 )
tcb_key ( 4 0 0 0 1 0 0 0 0 0 )
tcb_key ( 8 0 0 0 1 0 0 0 0 0 )
tcb_key ( 16 0 0 0 1 0 0 0 0 0 )
)
linear_pos ( 4
linear_key ( 0 0 0.04 -0.25 )
linear_key ( 4 0.0399998 0.04 -0.269085 )
linear_key ( 8 0.0404456 0.04 -0.393085 )
linear_key ( 16 0.0399998 0.04 -0.957116 )
)
)
)

----------------------------------------------

In MSTS following parameters double animation speed as expected:

----------------------------------------------
animations ( 1
animation ( 16 120
anim_nodes ( 24
....

anim_node DOOR_A (
controllers ( 2
tcb_rot ( 4
tcb_key ( 0 0 0 0 1 0 0 0 0 0 )
tcb_key ( 1 0 0 0 1 0 0 0 0 0 )
tcb_key ( 2 0 0 0 1 0 0 0 0 0 )
tcb_key ( 4 0 0 0 1 0 0 0 0 0 )
)
linear_pos ( 4
linear_key ( 0 0 0.04 -0.25 )
linear_key ( 1 0.04 0.04 -0.23 )
linear_key ( 2 0.04 0.04 -0.105314 )
linear_key ( 4 0.04 0.04 0.456686 )
)
)
)


----------------------------------------------

but in OR the speed stays the same. In all of the above examples the door Animation takes about 4 seconds.

Another problem I also encountered in MSTS when using less frames seems to be that sometimes there is a pause before the animation starts when the animation is played reverse (e.g. closing doors).

Kind Regards

Stefan