[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