[gpz]

I was glad to see the new car vibration feature introduced in r1478, this is exactly the way that tends to a more realistic train movement representation. However I think this feature needs some more polishing.

First of all, the outside camera views 2 and 3 would need to be unbundled from this vibration. Rather these cameras should act like we watch the train from an airplane that flies smoothly.

The other problem is the way how this vibration increases with train speed. I think in reality at larger speeds the small vibrations get invisible, only the larger ones can be noticed. The current implementation just simply does it in a way that the higher the speed the more the vibration. And in reality there are not just up-down and left-right movements of the cars, but also small turns around their longitudinal axis. There is also some vibration need to be implemented for inside views, but that might be even more difficult to do in a proper way. That should be done in a way if a person was sitting on a suspended chair, with also some side movement at entering and leaving a rail bend.

But I think this initial implementation is really a good start, thanks for working on this!

[_o_OOOO_oo-Kanawha]

The latest experimental release from openrails.org is X 1477, right?
So in the source code branch car vibration is intoduced?

Again referring to Railworks, the independent movement of locomotives and train cars is linked to a "track uneveness" parameter in the track rule master configuration file. I.e. the movements are controlled by a track parameter which you can set for various types of track. I don't think all axis of freedom are used, like in ships and aeroplanes, which can rock, sway, roll and stamp in a nauseating manner. In Railworks, the trains sort of wobble, but setting the "track uneveness" too high does lead to derailments eventually.

How has the Openrails team implemented this feature?

In prototype, track-train dynamics controls the ride of a vehicle over the rails. I believe this is a very complicated branch of mathematical modeling and for most railroads it involves lots of experimentation to validate the model and work out design flaws.

My own personal opinion comes from travelling to work by train 125 km and back at speeds up to 140 km/h. All of our DMU/EMU trains have bolsterless trucks using air bag suspension, locomotive hauled carriages usually steel coil springs and dampers between the bolsterless truck and carbody. Generally, while a passenger train gathers speed, it will start to vibrate or even oscillate when there is something wrong with the dampers. Track is generally very good, smooth and even, all welded rail on concrete ties, so I attribute any discomfort to rolling stock malfunction or maintenance. The older trains which had bolsters in their trucks rode perceptably rougher and were more noisy as well.

Of course, in US railroad practice it is freight only trains for 99% of all miles delivered. Passenger comfort is of little importance, lading damage might be a problem still without tightlock couplers or cushion underframes and load restrainers in boxcars and some flatcars.

I agree with the original poster, it should only be the internal views that must give the illusion of rolling stock movement/vibration/cabsway. In all external views the viewpoint must remain solidly fixed. In Railworks you can actually see the train wobble when you watch is from the locomotive or EOT camera.

Will superelevation eventually be implemented in Openrails as well?

[conductorchris]

This is a very exciting development. Thanks to the Open Rails team.
I'd agree, the person on the ground or air (the camera) doesn't vibrate, but the train does.
Christopher

[BB25187]

All,

First, I would like to warmly congratulate the OpenRails team: they do a great job, and as saif before, this a true enjoyment to dive into the sources and understand how things are done.
As for the vibration, I also think that this is a very good starting point.
At the moment, the vibration is modelled with a random variation of wheel position x and y. This means that from one step to the other, the car will make small, sharp jumps around the "normal" position refined by the geometry of the track. In real life, suspensions make things smoother. My first feeling, is that a very simple improvement could be implement by adding some kind of "low pass filtering" to the vibrations. The final "amount" value would be the sliding average of:
- The random value calculated for the current step
- The sum of former "amount" values, multiplied by some kind of coefficients.
Something looking like the code below:

            if (Program.Simulator.CarVibrating == true && speed > 3)//adding random vibration to axles
            {
                var damping = 0.01f;
                if (speed > 30) speed = 30;
                damping = (float)Math.Pow(speed + 10, 2) / 50000f;
                var amount = (float)(0.5d - Program.Random.NextDouble()) * damping;

                amount = (float)((4f*(amount + amount_prev[0])) + (2f*amount_prev[1]) + amount_prev[2]) / 11f;
                amount_prev[2] = amount_prev[1];
                amount_prev[1] = amount_prev[0];
                amount_prev[0] = amount;

                y += amount;
                x += amount / 2;
            }

The amount_prev array is to be declared as a private member of the TrainCarPart class. It is initialized to 0 in the constructor.

Regards

PS: I just noticed that the implementation was modified at revision #1482. I will check the result. Maybe the filtering remains relevant with this new implementation.

This post has been edited by BB25187: 10 March 2013 - 08:42 AM

[_o_OOOO_oo-Kanawha]

Users without the ability to compile the source code will have to wait for a future experimental release, right?

What about performance degradation, with all these extra calculations? I already notice the Openrails simulation engine gets overloaded sometimes, leading to "rubber banding" and fluttering speedometers with random wheelslip indications when the next tile is being loaded.

Solid and dependable funtionallity comes before eyecandy IMO, we don't want OR to go the same way as Railworks. There are still more basic and imporant issues to solve, given the number of warnings in the logs.

[cjakeman]

_o_OOOO_oo-Kanawha, on 10 March 2013 - 10:50 AM, said:

There are still more basic and important issues to solve, given the number of warnings in the logs.

Don't disagree that performance is more important than eye-candy, but more warnings in the logs means more quality, not less.

Warnings usually indicate anomalies in the model data, where OR is far, far more helpful than MSTS. MSTS features not implemented in OR also lead to log messages; these usually begin "Information: Skipped . . . "

E.g.
Information: Skipped unknown notch type TrainBrakesControllerContinousServiceStart in D:\play\MSTS\trains\trainset\H-Start_5341_Flirt\H-Start_5341-004_A.eng:line 565

[_o_OOOO_oo-Kanawha]

Yes, OR's logs and runactivity process window are very helpful, when reporting anomalies, errors and missing parts. Unlike the totaly useless Railwors, OR actually helps us users in finding and correcting any small or major error.

As long as cabsway or vibration can be switched off in the options window I will gladly play around with it in one of the next experimental releases.
There are actually people not on the dev team that compile the nightly builds? I am not a programmer or developer, rather a player, and think OR has come a long way since.

Full marks to Chris Jakeman and his colleagues!!! :bigboss:

[BB25187]

Hi,

_o_OOOO_oo-Kanawha, on 10 March 2013 - 01:32 PM, said:

There are actually people not on the dev team that compile the nightly builds?

From the OR website, you can access the "Developers Resources" page. From there, you will find a link to the page which explains how you can access the public part of the source repository, thanks to the Tortoise tool. This is sufficient to run the very last version committed to the trunk. The explanations to install Visual Studio C# and recompile/debug the code are also provided on this page. It is very interresting to read (and sometimes, understand) the modifications of the code which are committed to the repository. I am really impressed by the work already done!

Regards

[JTang]

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.

[captain_bazza]

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

[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