[Eldorado.Railroad]

 JTang, on 10 March 2013 - 02:46 PM, said:

You can turn on vibration by Ctrl-V. Hitting the key will rotate the vibration from no vib, to mid vib, to high vib.

The code has been changed so that outside cameras will not shake along with the cars.

Jijun,

Now this was an unexpected surprise!

I think you'll have to go back to the drawing board on this one. I don't know what your background is, so I will assume there is a little bit of mathematics in it, so please take a look at this: Damped Harmonic Oscillator

Take a good look at the graphic entitled "Underdamped Oscillator". If the mathematics is beyond you then look at the graphic, and notice that it is sinusoidal. This is VERY unlike what you have modeled which is mostly a rapid pulse, square wave. It should be easy to use the values of a low frequency sine wave as your jitter offset. Typically, the frequency is LESS than 5 Hz, this means 5 cycles per second. Your jitter is far higher than that! Since you are trying to accomplish this in real time I suggest a lookup table of pre-computed values (either as part of the constants or computed once and only once when runactivity.exe starts up) for the movement (X axis jitter in the sim) and damping. Damping just means that instead of steady state oscillations you can have a reduction in both the frequency (5Hz down to 0Hz) and amplitude going to zero. This would be far more realistic and less vertigo (dizziness!) inducing.

So instead of the abrupt, +/-1 changes along the X-axis, you would have progressive values as seen here:

http://www.grc.nasa.gov/WWW/k-12/airplane/Images/tablsin.gif

Note that you have a progressive change in values. To speed things up you can step through the table by 10 or 20 degrees (BUT, remember the faster the change, the more jitter you will have!). For negative values, just change the sign of what is in the table (starting from a zero angle). So in practice you index from 0 to 90 back to 0, etc. To lower the amplitude you would index from 0 to 90 to 0 but divide the values given for each angle by 2 (this is just an example) etc.

Again, since these values are pre-computed, you do not have to calculate them in real time and is therefore VERY fast. If anything it is simply a matter of indexing into the table/array and performing simple arithmetic to get the desired result. With this method the different jitter rates could be applied to each engine car, but I think it is important to go easy on the amplitude and frequency.

Your idea Jijun is a very good one and most practical and "realistic" if done with a little care.

Hope this helps a little,

Eldorado

[Eldorado.Railroad]

 captain_bazza, on 10 March 2013 - 04:20 PM, said:

The vibration needs to be dramatically dampened down. It is extremely hard visually at the current range of vibration speeds. It could possibly induce a fit in susceptible people, specially those affected by the flicker of fluorescent lights.

Good start though, but it needs the ability to detune or tune it to suit the individual.

Cheers Bazza

This coming from the man who "gave me a start{le}" when for the first time ever in MSTS/OR I noticed that the tender car of your Mogul was bouncing around! It took me a second to figure out that there was an animation in the shape file that was causing that. Since then I have been thinking about putting this effect in other models!

On a more serious note, the refresh rate of HD panels I use are 60 Hz. All that wild jitter (coupled with the long refresh time of the display) makes for an unpleasant ride. I tried it for exactly 10 seconds and I knew that I could not use it without losing my lunch. But I was eager in anticipation of what it would look like beforehand! With a little more work I think this would be a great addition.

Eldorado

[Genma Saotome]

FWIW, Car rocking is like a harmonic wave -- a long wave w/ many cars between the wave peaks and the wave appears at several speeds and then disappears when the train speed is not near those speeds. What we have in hand from a North American engineer is that in terms of gaining speed it's no rocking from 0 until the train is >10-12mph, with the wave action most pronounced at ~18mph, damping down a bit and then peaking again at 25mph, then damping down and staying down until the train speed is > 35 with the rocking peaking again between 40-45mph.

What is not known is whether those facts are unique to North American equipment only or not, and perhaps whether there is a marked difference that occurs per changes in average car lengths.

[captain_bazza]

Quote

This coming from the man who "gave me a start{le}" when for the first time ever in MSTS/OR I noticed that the tender car of your Mogul was bouncing around!

I can recommend 'adult diapers' for those sort of moments.

This 'vibration' is indeed an exciting new development, and one out of the blue, so to speak. Having it 'built in' to OR will save me a lot of work, although I can't promise that ((BM)) will completely disappear. You should see those Chinese C2's wobble about.

Cheers Bazza

[captain_bazza]

FYI: I am running an Asus LCD/LED 27" monitor, running at 120 Hz. The higher Hz rating is because it's 3D capable - 60Hz per eye. :whistling:

Cheers Bazza

[Eldorado.Railroad]

Jijun,

I like very much what you have done with "Vibration", personally I would call it "Oscillation", but you are the coder here!.

i) A few improvements that I can suggest is that I still find the magnitude of polar movement too large, especially when the camera (#5) is high up in the caboose. Since this is a matter of personal taste, perhaps it should be a variable in the registry, for what looks like the value of "Program.Simulator.CarVibrating"

ii) In the code there is no provision for damping. So once the oscillation starts it never stops, which is unlike what happens in reality. From TrainCar.cs:

            //small vibration (rotation to add on x,y,z axis)
            var sx1 = (float)Math.Sin(sx) * max; var sy1 = (float)Math.Sin(sy) * max; var sz1 = (float)Math.Sin(sz) * max;

The best example I can use is the shock absorber in a car. When you hit a bump, the oscillation stops at some point. For a much larger mass like a trains engine/car it will take a few seconds to stop, because it is like a bouncing ball.

To make that happen at some point the value of sx1, sy1, sz1 must actually go to zero AND STAY THERE, or very close to it. So a damping factor WRT to time is what is needed. I realize that this complicates the code a little because from what I can see once the oscillation is triggered by the user pressing Ctrl-V, there is no provision to modify the amplitude of the polar movement so that eventually the movement almost stops. I think that stopping it completely would make this oscillation look a bit too "fake".

As with a car, unless you are driving over a road that is full of holes, you will have periods where there is very little polar movement. So the best simulation would be to randomly trigger the oscillation and dampen the movement so there is almost none. At some point in time the oscillation is re-triggered. Best described as: smooth.....bump..dampen...smooth.......................bump..dampen...smooth..etc.

Thanks so much for taking my idea about using the sine function to calculate positions, that part really looks nice. I also can see that you opted not to use a lookup table, so maybe OpenRails is fast enough as is with C# code. I learn something new everyday.

iii) I doubt very much that at higher speed a large amplitude polar movement is likely to happen. This would make the train very unstable on the tracks and cause it to derail. So as a function of speed, because there is forward momentum (and the train weighs many tons!) the inertia of the train would dampen the amplitude of the oscillation. So as speed increases your train moves less. This is the reason why there are speed limits for certain areas which would be very bumpy, for example a train yard with many switches and tight curves in it.

iv) It would also be very realistic if the initial deflection is not always in the same direction. The oscillation as simulated right is now is fixed and always running the same circuit with small variations in amplitude. WRT to ii) described above, it is more realistic to have deflections that are random in the X,Y,Z directions. This means that you could use a random number generator to decide whether the initial deflection should be either in the +/- direction, adding or subtracting a value from the camera position. This would be visually more appealing and more realistic.

Take care and thanks for all you hard work,

Eldorado

[conductorchris]

One thing that is very noticeable in real life is the "random" oscillation starts at a fixed point on the track - a particular low joint or switch or other slightly imperfect section of track. You can see the oscillation go down the train like a wave as it passes over the point. I know nothing about the code, but perhaps that observation is helpful. Thank you for your work and contribution!
Christopher

[Genma Saotome]

IMO what we need is the long term solution: car bodies should not be the same model as couplers and/or trucks. That would allow all three to move independent of each other when it is correct for them to do so. That would let the car body rock w/o altering the position of the trucks and let each coupler move w/ changes in the slack w/o altering anything else. It would also allow reuse of the coupler & truck models across a variety of rolling stock.

As for the car body rocking, it's not random, it tends to occur at certain speeds and not at others. I don't recall now but doesn't the weight of the lading factor in as well (as in empty cars will rock more than a loaded car)?

[James Ross]

Technically, we could keep the wheels/bogies on the track and only vibrate the rest - no need for distinct models - but it's not going to be the easiest thing to do. I'd also be concerned about taking an experimental (and with no immediate plans to mark it otherwise) feature too far.