[Eldorado.Railroad]

Preamble: I am sure many MSTS model veterans will roll their eyes at this post. So please keep in mind that this post is in the spirit of experimentation and not sane/spartan modeling practices. OR allows for more "abuse" of animations because of the use of the GPUs we currently have.

Perhaps at some future time OR will allow for scripting of animations such a those that are available for Trainz. Until such time and given what we have to work with as far as the Kuju shape files are concerned other more inventive, "stop gap", half-measures could be used.

So my question is just how many tcb_rot and/or slerp_rot positions are allowed in a shape files for OR? Currently I have tried up to 128 with animation ( 128 30...) in the animation section of the shape file. But those are long scripts to write without making any errors (yes I have done this and some of the resulting animations, at least as far as Paul Gausdens Shape Viewer are concerned are "unexpected" when an error is introduced!). I could write a bit of code to automatically generate the positions I want for tcb_rot and slerp_rot, but I do not know what the limit currently is in OR. Is it 128, 256,...65536? The MSTS reader is not part of the published source code so I cannot find what the limit is out without asking.

thanks for your help and time with this matter,

Eldorado

[James Ross]

OR sets no hard limit, but the implementation uses arrays and other data structures that will have a limit. I would expect 2^15-1 (32,767) is supported but beyond that is unclear.

Edit: Also worth noting that the more key frames your animations have, the more work has to be done to animate them. I doubt the code here is optimised for anything in the hundreds or thoursands.

[longiron]

The other point to make is why have 256 animation steps when most people have much fewer FPS? All those extra animations won't be seen on the screen. If you think about it, movie film uses 24 FPS to achieve the effect of smooth motion - so a target max ought to be something in that range. Why ask the OR software to do more work than necessary?

[Eldorado.Railroad]

longiron, on 06 August 2011 - 12:23 PM, said:

The other point to make is why have 256 animation steps when most people have much fewer FPS? All those extra animations won't be seen on the screen. If you think about it, movie film uses 24 FPS to achieve the effect of smooth motion - so a target max ought to be something in that range. Why ask the OR software to do more work than necessary?

While I will gladly accept that developers of OR are the masters of their domain for which I am more than grateful for, this is a topic that I have spent a little time on in MSTS because of animations (some payware) that were not working properly, at least to my eyes.

So what I hopefully understand and have observed is that the animation section of a shape file has an opening statement which is animation ( I, J,....) where I the is max number of steps and J is the number of steps per frame. A small value for J results in animations being slower, a large value has the opposite effect.

For a locomotive at least, all of the animations that use Wheelx and Rodxx definitions are synchronous and are determined by the track speed of the locomotive in the sim. Thus higher track speeds results in faster cycling of the animation. As the total number of steps increases and the number of steps per frame remains invariant, you can achieve very fine control of when and where an animation starts, stops, continues, etc. This is especially so if you would like an animation to occur in an intermittent way over a long period. The limitation of course is the synchronous constraint.

So when I inquired about the max number of positions allowed, it need not be said that the "fantasy" was to have 1000s of discrete positions, but rather it allow the modeler (given the current MSTS shape file constraints) to emulate some "ersatz" form of intermittent behaviour (behavior).

AFAIK this is perfectly "legal" in a shape file in OR and MSTS Bin:

animation ( 128 30
anim_nodes ( 1
anim_node ROD01 (
controllers ( 1
tcb_rot ( 5
slerp_rot ( 0 0 0 0 1 )
slerp_rot ( 32 0 -0.7071068 0 0.7071068 )
slerp_rot ( 64 0 -0.7071068 0 0.7071068 )
slerp_rot ( 96 0 0.7071068 0 0.7071068 )
slerp_rot ( 128 0 0 0 1 )
)
)
)
.
..
...

The second and third slerp_rot statements effectively stop the animation of that part for a number of frames that is dependent on the track speed of the locomotive. If OR allows for much larger max number of steps a modeler could extend that dead period for a much longer period. In my case, since I would like to simulate the duty cycle and spin up/down of cooling fans those larger number of steps are very handy. Again I have no plans to create an animation with 1000s of discrete key frames! Unless ORs code is doing something unexpected, waiting for the animation counter for the definition in question to reach a provided value should have no impact at all, because that animated object is not required to change position.

It is a given that the coding of the animation can really only be done by an edit of the animation section of the shape file in question. The modeling programs that I can afford do not provide an easy way of doing this!

If there is a much simpler way (with the same results and use of less resources) of doing this I am more than glad to learn something new.

thanks for all the hard work, which is greatly appreciated,

Eldorado

[Eldorado.Railroad]

James Ross, on 06 August 2011 - 12:08 PM, said:

OR sets no hard limit, but the implementation uses arrays and other data structures that will have a limit. I would expect 2^15-1 (32,767) is supported but beyond that is unclear.

Edit: Also worth noting that the more key frames your animations have, the more work has to be done to animate them. I doubt the code here is optimised for anything in the hundreds or thousands.

Understood. I will tread gently in this area by experimenting and noting what the limits are. It is not my intention to be creating 1000s of keyframes, but it is much more likely knowing that the total number of steps can be a large number, this can be used to advantage in an intermittent animation.

Thank you Mr. Ross,

Eldorado

[longiron]

Eldorado.Railroad, on 06 August 2011 - 02:17 PM, said:

For a locomotive at least, all of the animations that use Wheelx and Rodxx definitions are synchronous and are determined by the track speed of the locomotive in the sim. thanks for all the hard work, which is greatly appreciated,

Eldorado

You should experiment. The OR team is working on one more turn on the physics side. There's a lot of ideas that we're looking at implementing that would allow this kind of animation, and other cool things.

[captain_bazza]

MSTS/OR model animation always loops, except for scenery interactives.

For example:

A steam locomotive has 0 ~ 16 frames to complete a total 360 rotation of the drivers; with keyframe 0 being neutral and the full rotation taking place over the remaing 16 frames, advancing by 22.5 degrees (wheels) per frames for the whole rotation sequence.

The synchronisation of wheel (drivers) to rotational speed is governed by the wheel diameter data line in the ENG file. This of course requires the wheel diameter is correctly modeled to 1:1 scale.

The bogie wheels are automatically rotated by the sim(s) and their speed of rotation depends on the same parameters as the main drivers, the wheel diameter data in the relevant section of the ENG file - they, too, have to be correctly modeled to achieve synchronisation with forward speed.

Cheers Bazza

[captain_bazza]

Animation explanation:

There are three types of animation available in most modeling programs, linear, rotational, scaling. Scaling animation is not supported by MSTS or OR and must not be used.

Simplified explanation:

Scaling animation is where an object changes shape, or volume, (scale) between frames.

Linear animation is where an object moves in a sliding motion in the same plane between frames.

Rotational animation is where an object rotates by a number of degrees between frames.

Cheers Bazza

[captain_bazza]

In MSTS/OR:

An animated object may only have a single pivot point.

Only one type of animation, per frame, may be applied to any object, per frame.

Wheels, for obvious reason, should only use rotational animation, per frame.

Rods may use either rotational, or linear, animation, per frame.

A limited number of steam specific animated objects may be used for diesel and electric locomotives, but not vice versa.


I hope the above info, given in good faith, is of use to current modelers and prospective modelers.

Cheers Bazza