[Weter]

Hello, all
But yes. Yesterday, electric locomotives have "dug" too soon - like there were brakes applied, since throttle was off.
(used T1.5.1-464 version)

[pschlik]

I've done some more driving with the latest updates, seeing some changes.

Wheelslip isn't being detected any more while coasting, and there's 0 wheel creep, which makes sense when coasting. However, the reported wheel adhesion will often show high adhesion despite the lack of any applied force, and as previously will revert to sensible adhesion levels once some power is applied again.

Substep behavior is dramatically different now, and it is causing some visible issues with frame time pacing. Looks like the number of substeps will usually gradually drop over time then jump back up in an instant (the num of substeps plot on the debug HUD gains a sawtooth pattern), and that constant change in number of substeps results in constant change in framerate-not a pleasant experience. I wonder if something can be done to make the number of substeps more consistent?

[steamer_ctn]

pschlik, on 21 October 2023 - 12:26 PM, said:

Substep behavior is dramatically different now, and it is causing some visible issues with frame time pacing. Looks like the number of substeps will usually gradually drop over time then jump back up in an instant (the num of substeps plot on the debug HUD gains a sawtooth pattern), and that constant change in number of substeps results in constant change in framerate-not a pleasant experience. I wonder if something can be done to make the number of substeps more consistent?

Thanks for the feedback.

The low substep rate was causing the coasting issue as the slip speed was in error at low values of substep. When the rate jumps up it is taking the slip speed error out the the error zone.

This current patch eliminates the coasting (slip speed error), but at the cost of putting a heavier load on the CPU. Hence it will be a bit of a juggling act to get it to be the correct value.

I will ponder on it a bit more.

[cesarbl]

Quote

Substep behavior is dramatically different now, and it is causing some visible issues with frame time pacing. Looks like the number of substeps will usually gradually drop over time then jump back up in an instant (the num of substeps plot on the debug HUD gains a sawtooth pattern), and that constant change in number of substeps results in constant change in framerate-not a pleasant experience. I wonder if something can be done to make the number of substeps more consistent?

If there is a noticeable change in frame rate when increasing the number of substeps, then I think it's not something acceptable.

I was aware of all the potential issues that switching to Polach method would create, and unfortunately all my negative predictions have been confirmed one by one. It's really sad that after all our efforts to use a more realistic model have been in vain.

In my opinion, there's not too much that we can do to fix it. Even if we use an algorithm that selects the optimal number of substeps, the Polach formula will be demanding many substeps, and the frame rate will still be impacted. I think that the small advantages of this new model with respect to the old one do not justify a reduction in frame rates.

At most, we can make a decision on which model to use depending on elapsedClockSeconds: if frame rate is < 10 FPS, use simple adhesion; if frame rate < 80 FPS, use Bauer's model, else use Polach model.

[darwins]

Quote

I think that the small advantages of this new model with respect to the old one do not justify a reduction in frame rates.

If we abandon the Polach approach, hopefully it is still possible to keep the following positive developments:

Steam locos slipping relative to crank angle position.

The use of powered or unpowered axles on locomotives.

Powered axles being either linked together (e.g: B-B) or independent (e.g: Bo-Bo)

Difference of ac traction / dc anti-slip traction / conventional dc traction.

[cesarbl]

Yes, a potential withdrawal of Polach model would only change the % of wheel creep that happens before wheel slip, but the rest of features would still work. It's just that unfortunately we haven't enough CPU power to properly simulate the wheel-rail contact area, and therefore we need a simplified, not so realistic model for that.

[Weter]

Just for now, though...
Don't turn sad: your work is great.

[steamer_ctn]

pschlik, on 21 October 2023 - 12:26 PM, said:

Substep behavior is dramatically different now, and it is causing some visible issues with frame time pacing. Looks like the number of substeps will usually gradually drop over time then jump back up in an instant (the num of substeps plot on the debug HUD gains a sawtooth pattern), and that constant change in number of substeps results in constant change in framerate-not a pleasant experience. I wonder if something can be done to make the number of substeps more consistent?

I am reluctant to give up on the Polach model at the moment, until I have exhausted some more variations.

I have added another patch to try and remove (or alternatively make smaller) the sawtooth effect with the substeps. This should be more in line with the previous rate of change for the substeps.

Can you give it a go, and give me an indication whether this is improving the performance whilst still maintaining the "fixes" applied to coasting, etc?

If there is still an issue with the substep/framrate combination can you provide more detail around your testing scenario. I would be interested in knowing the before and after frame rates, etc.

Thanks

[steamer_ctn]

I have added a few further tweaks to try and lower the substep rate when higher values are not required, so please make sure that you update to 2023-10-23 0952.
2023-10-23 09:522023-10-232023-10-23 09:522023-10-23 09:522023-10-23 09:522023-10-23 09:52

[pschlik]

Had another moment to test today. Numbers of substeps are more tame now, and in combination with more gradual change frame time pacing is definitely more consistent now. Also remained fairly stable even at 300% sim speed so the algorithm seems to be running fast enough at the moment. Still seeing some unusual indications from the simulated wheel adhesion though, it will still get stuck at unreasonably high values (for example, the MSTS Dash 9 reading 33% ahdesion while at a complete standstill). That can't be doing anything good for the stability of the model and there has to be a simpler way to avoid that than just throwing more substeps at the system. Surely it would be obvious without substepping that a force of 0 should require and ahdesion of 0?

In any case, I did encounter a NaN error I can only guess is related to recent commits? Haven't had the time to chase this one down, but I have seen it multiple times after a few minutes of playtime.

Error: System.ArithmeticException: Function does not accept floating point Not-a-Number values.
   at System.Math.Sign(Single value)
   at Orts.Simulation.RollingStocks.MSTSLocomotive.UpdateAxleDriveForce() in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\Orts.Simulation\Simulation\RollingStocks\MSTSLocomotive.cs:line 2429
   at Orts.Simulation.RollingStocks.MSTSDieselLocomotive.UpdateAxleDriveForce() in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\Orts.Simulation\Simulation\RollingStocks\MSTSDieselLocomotive.cs:line 798
   at Orts.Simulation.RollingStocks.MSTSDieselLocomotive.UpdateTractiveForce(Single elapsedClockSeconds, Single t, Single AbsSpeedMpS, Single AbsWheelSpeedMpS) in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\Orts.Simulation\Simulation\RollingStocks\MSTSDieselLocomotive.cs:line 783
   at Orts.Simulation.RollingStocks.MSTSLocomotive.Update(Single elapsedClockSeconds) in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\Orts.Simulation\Simulation\RollingStocks\MSTSLocomotive.cs:line 1997
   at Orts.Simulation.RollingStocks.MSTSDieselLocomotive.Update(Single elapsedClockSeconds) in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\Orts.Simulation\Simulation\RollingStocks\MSTSDieselLocomotive.cs:line 573
   at Orts.Simulation.Physics.Train.physicsUpdate(Single elapsedClockSeconds) in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\Orts.Simulation\Simulation\Physics\Train.cs:line 1966
   at Orts.Simulation.Physics.Train.Update(Single elapsedClockSeconds, Boolean auxiliaryUpdate) in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\Orts.Simulation\Simulation\Physics\Train.cs:line 1849
   at Orts.Simulation.Simulator.Update(Single elapsedClockSeconds) in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\Orts.Simulation\Simulation\Simulator.cs:line 846
   at Orts.Viewer3D.Viewer.Update(RenderFrame frame, Single elapsedRealTime) in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\Viewer.cs:line 760
   at Orts.Viewer3D.Processes.GameStateViewer3D.Update(RenderFrame frame, Double totalRealSeconds) in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\Processes\GameStateViewer3D.cs:line 123
   at Orts.Viewer3D.Processes.UpdaterProcess.Update() in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\Processes\UpdaterProcess.cs:line 131
   at Orts.Viewer3D.Processes.UpdaterProcess.DoUpdate() in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\Processes\UpdaterProcess.cs:line 108
   at Orts.Viewer3D.Processes.UpdaterProcess.UpdaterThread() in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\Processes\UpdaterProcess.cs:line 74
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)   at System.Threading.ThreadHelper.ThreadStart()

And this might be related but whenever I apply power ammeters are reading NaN! (Dynamic braking is fine though?)
https://i.imgur.com/kDzsqXR.png
Then if I pause the game, the amperage indication reappears?

https://i.imgur.com/tFcxQVe.png

At this point, I'm not convinced that this model is a fool's errand but even after working through the weird stuff, it will clearly need more computing power than the previous model. Maybe some simplifying assumptions can be made, or the old model could be user-selected (though it could use some modifications to give more reasonable wheel creep), but I don't know the details and it's not the right time to worry about that anyway.