Are long consists impossible?

[MikeK]

I played with the min and max values tonight, and they (almost) do what we want. After a few hours of testing I was able to get settings that do exactly what I imagine real slack to be like.

Here is how it appears to work in the sim:

The min and max values in the coupler bin file control how far in and out the coupler will go BEFORE the damped spring settings take effect. This is important, because I think the problem all along is that the couplers should be mild springs first, but have limits on how far they can travel. Instead, the couplers stretch out, then when they reach their limit, the spring effect kicks in and they stretch further. Because a spring will always stretch (or compress) further the higher the force applied to it, this means that there really is no limit to how far the couplers can go. The more locos at the head end of the train, the further all the couplers will stretch.

Here are the results of some tests with 1 loco and 1 freight car:

Test 1: no spring, all slack:

MinDistance: 0
MaxDistance: 10
TargetDistance: 5
SpringCoeffiecient:1000000
Damping:1000000

In this test, the spring values are so high that there is basically no spring any more. The couplers can just go in and out a distance of 10 (I have no idea what the units are, probably metres - the default value for maxdistance was 0.1). By changing it to 10, the loco moves until the coupler is stretched, then the car starts moving. If I flip the reverser with the throttle still on, the car keeps going until the slack is gone then bangs into the loco. Here is a pic:

2011-11-23_00003.jpg

Test 2: No slack, all spring:

MinDistance: 0
MaxDistance: 0
TargetDistance: 0
SpringCoeffiecient:10
Damping:10

This time as soon as the loco starts moving, the car starts moving as well, but the coupler is continuously stretching. If I go quite fast in reverse then flip the reverser to forward, the freight car ends up hundreds of feet behind the loco before it starts catching up again. To me this highlights the problem. The limits are applied first, then the spring. This is just wrong, there has to be a physical limit on how far the couplers can stretch or compress, and adding more force shouldn't stretch them further.

An article I read in trains magazine years ago talked about slack. The things that stand out in my mind are the fact that the engineer must ease the slack out of the train when starting ... but once the train is stretched it is OK to just increase the throttle as far as you want. The train cannot stretch any further since it is already stretched at that point. This is impossible to do when the couplers are a spring, since the train will just stretch more as soon as you add more force. It will never be "fully stretched". Another scenario was slowing the train by just reducing the throttle miles in advance of the slow section instead of using the brake. The benefit was that that a low throttle setting would let the drag of the train slow it down, but the low power setting would also keep the train stretched. Again, impossible to do with spring couplers, since the train bunches up a bit every time the force at the head end is decreased.

Because of these reasons I do not believe we need the spring effect at all. I ended up trying out these values:

MinDistance: 0
MaxDistance: .3
TargetDistance: .15
SpringCoeffiecient:1000000
Damping:1000000

That is triple the original amount of slack to compensate for the fact that the spring effect is gone. I have no idea how much slack there really is in a coupler, but watching the joined as I went from forward to reverse and back looked reasonable to me compared to what I have seen in reality.

With these settings when you add power you can watch the speed closely and really see the effect of the slack running out, but once it is stretched you can power up all you want. Similarly, when you switch to DBs you can see and "feel" the slack running in, but once the train is bunched you can add all the dynamics you want.

Oh, and switching with long cuts of cars feels a lot more realistic now too. Definitely more along the lines of the slack run out show in the youtube vids posted earlier.

It is definitely still possible to mismanage the slack and break something. This was the result of getting a 100 car train up to 10 mph then flipping the reverser switch (I have no idea why trains take off like this when something goes wrong but I am starting to realise that in the TS2012 world this usually means "max coupler force exceeded"):

2011-11-23_00002.jpg

Now when this happens it feels like it is because the game is simulating reality, not because we broke some fake rule.

Here is my coupling file for anyone that doesn't want to edit stuff:

buckeye_type_e_coupling.zip

[Kali]

If that's actually in metres you're giving each coupler about a foot of slack, which seems a little much for knuckle couplers even compensating for the solid spring - but good lateral thinking. I'm not sure if a totally solid spring and that amount of slack might make the physics engine a bit upset ( there are issues with jitter and energy being stored in couplers/buffers you have to watch for somewhat ). You have actually modelled a british 3-link "loose" coupling. There will be some slack in the knuckles - which I presume is what the min/max was originally for, then the springs to damp the buffing shocks so you don't get fatigue in the frame, and then the limits of that travel. Who knows if those springs ever reach their limit of travel though?

The amount of force to stretch a spring a certain distance is constant, and usually linear - 20x bigger spring coefficient means 20x the force to stretch it the same amount. With the right spring force the spring will stretch a little way and then not stretch any further - the problem we have is that point is rather dependent on consist length ( too many things are ).

[MikeK]

I agree, with the current implementation, how is it possible to find a spring coefficient that always works when one person runs 10 car trains and another runs 100+ car trains? You have to err on the side of too stiff. Otherwise the train flies into the air the first time someone tries dynamic braking on a long train :)

I send RS an email with the issue, hopefully they will address the real problem one day and we won't need these hacks.

[Kali]

I'd like to know what units the strength parameter is in - it's a bit pointless having the spring stiffer than the couplers ( also might be a bit confusing for the physics engine ). I will try & dig out some likely laws they used involving the damping, it's probably something basic about spring oscillations; that might be helpful in terms of setting up slack.

[simer4]

Here is my input:
A couple of months ago, whilst at Union Station downtown, a CN grain train was slowing to a stop. This caused the couplers to slacken up a bit, but not to much. The train stops for five minutes. Upon moving, the engineer seemed to have gunned it in a way I have never seen before. You couldn't here the front loco's, but you sure could hear the slack in the couplers be removed (dadadadadada).
During this removal of slack, the couplers slammed out an extra 5-7in. Looking at draft gear and scale drawings, there is about 10in of movement from the minimum point in the flat bar opening (closest point of opening of flat bar opening to the main draft gear) to the maximum point (farthest).
http://www.sergentengineering.com/image ... ftGear.gif

[RiscIt]

This doesn't add anything new to the discussion, but it's relevent so I'll post it here as well. I originally posted it to the RSC facebook page.

http://www.youtube.com/watch?v=b4jGo6Kewyo

[Machinist]

This doesn't add anything new to the discussion, but it's relevent so I'll post it here as well. I originally posted it to the RSC facebook page.
http://www.youtube.com/watch?v=b4jGo6Kewyo

For sure, it's a relevant warning!

It was just what was missing: flying saucers and aliens abducting not only the crew but the whole train. Out of caution I won't buy this route nor drive out there...

[Kali]

While you're still rendering the scene in realtime with the game paused, you're not doing any asset culling or any other work to decide what's in the next frame. Out of bounds physics might well be an fps hit, but I don't think you can just reach that conclusion from pausing.

[micaelcorleone]

This doesn't add anything new to the discussion, but it's relevent so I'll post it here as well. I originally posted it to the RSC facebook page.

http://www.youtube.com/watch?v=b4jGo6Kewyo

An interesting video, especially the description text where it reads:

Pressing escape to pause the simulator can increase framerates to very acceptable ranges. During this time the scene is still rendered in real time as the camera is still manipulable. This suggests that, since no trains are moving while the simulator is paused, that the framerate issue is from a bottleneck in the physics code pipeline.

I've also recognized this. It was the same in Railworks 2.
If you shortly pause the game, framerates get slightly better for a short time.

Your explanation sounds feasible, but I want to add that texture/object loading migth also have an effect here.
If you pause, scenery is still loading.

[RiscIt]

Kali - It's also deduced based on the fact that you can move the camera around. That *does* affect what is in the next frame. The only difference is that light sources are not moving (aside from the ambient light around the camera, which I suspect is really an area of negative black fog) and physics aren't being calculated.

I can fly around in paused mode wherever I like, loading new tile assets as I go, at 50 fps and up, but as soon as I un-pause and the sim is calculating the physics of 130 cars.... it's back to 8-10 fps.

At this point I have to believe it isn't a graphics issue, because it is still present with *everything* turned down, and really - the graphics in RW3 aren't *that* complicated and shouldn't be particularly taxing.

I almost wouldn't mind if it didn't slow down time when it dips under 14 fps. A 6 hour drive at 8 fps takes much longer... It's like driving in slow motion (the opening shot of that video with the entire train passing by had to be sped up considerably so that the time of the clock in the simulator ran at real time). I suspect it has to, however, or the dropped physics frames which are taking forever to update would be too erroneous.

This is all very off topic, however... Perhaps a new thread is in order.

[Kali]

Risc: mm; I did post a video quite some time ago from the cab on my version of BoQ - every time there was a really big lurch the game would practically pause. However there definitely is something related to scenery too, because I can drive light engine around HSC and get slowdowns in the same spots.

[Chacal]

This suggests that, since no trains are moving while the simulator is paused, that the framerate issue is from a bottleneck in the physics code pipeline.

This should be easy to test with 2 Nvidia GPUs. In the Nvidia control panel, it is possible to assign one GPU to 3D rendering and the other one to Physx. I'll test that as soon as I can.

[RiscIt]

Everything I had heard (which is admittedly limited) is that NVidia folks with PhysX acceleration don't have a problem (which supported my hypothesis).... I'll be interested in seeing the results.

It's very disheartening to know that we have to do RSCs testing for them, however. Their lack of communication is obnoxious. I've yet to see an RSC representative even admit that there is a problem... They just link to the graphics tweak guides whenever people complain.

[NDORFN]

Everything I had heard (which is admittedly limited) is that NVidia folks with PhysX acceleration don't have a problem (which supported my hypothesis).... I'll be interested in seeing the results.

It's very disheartening to know that we have to do RSCs testing for them, however. Their lack of communication is obnoxious. I've yet to see an RSC representative even admit that there is a problem... They just link to the graphics tweak guides whenever people complain.

I've got an Nvidia GT320, not exactly the gruntiest card, and I have no graphics or frame-rate problems at all.

[Hawk]

I've yet to see an RSC representative even admit that there is a problem...

I take it you haven't seen this post?

viewtopic.php?f=6&t=4153