Skip to main content ↑ ↓
Topic: [patch] Overhauled physics model (Read 9900 times) previous topic - next topic

[patch] Overhauled physics model

Quote from: Bernd Gabriel – on
I will prepare 2 patches for simutrans standard: 1st patch for the graph and 2nd patch for the model.

This is the 2nd patch.

The overhauled physics model now:
- considers the different kinds of engines (at the moment at least the different land engines, ships and aircrafts can get own considerations easily).
- removes the violent speed changes. Your p****engers will thank you for the smoother travels.
- removes the weird results for larger delta_t.

Apply 'overhauled-calc_acceleration-2831.patch' to a pure revision 2831 or 2832 (without 1st patch).
It contains nearly the same changes to simconvoi.cc/.h like the 1st patch (but does not register speed records achieved while calculating the graph).
'acceleration-graph-for-overhauled-physics-2831.patch' contains the rest of the 1st patch.
The journey is the reward!

Re: [patch] Overhauled physics model

Reply #1 –
I don't know physics but acceleration is monotonous and it doesn't reduce speed even though at U carve. Landing of airplane is also monotonous.
And also some of them never reach their maximum speed limit, thus the max speed with min/max weight of full load on depot window in completely useless.

And plus, this is heavy. Some test games run only 4 fps on my PC. So, no advantage for me. But this is just my personal opinion

Re: [patch] Overhauled physics model

Reply #2 –
As written in the simutrans experimental thread, the current model in simutrans is correct for steam (there slightly wrong friction) engines, ships and airplanes (i.e. constant acceleration with quadratic drag). The only thing you add are acceleration for constant power (that is something that can be discussed) and several small stuff, which is not needed for the game world. Because I see no benefit in including friction factors for diferent waytypes. Especially since a sand road would have nearly a magnitude different one from a concrete highways.

One should keept in mind that there is not km/h in simutrans, at least not consistently. It is a game and using constant like g is completely useless (last time I checked the world was still flat in simutrans ... ;) )

About engines not reaching topspeed: WIth the old formular the topspeed was given by:
(total_power/total_weight+1)^0.5/2500

The new model it should be (if it is really like the wikipedia formula):
v=((sqrt(27*A*P^2+4*kr^3*m^3)+3^(3/2)*sqrt(A)*P)^(2/3)-2^(2/3)*kr*m)/(2^(1/3)*sqrt(3)*sqrt(A)*(sqrt(27*A*P^2+4*kr^3*m^3)+3^(3/2)*sqrt(A)*P)^(1/3))
with m: m****, kr:friction coefficent, A: air drag and P: power. (I love computer algebra systems ... ). These are two other solutions, but they are complex numberS (and thus make actually not much sense to me, since the speed should be a real number.)
So it can be done, but I am not sure, if this is really progress in the end.

Re: [patch] Overhauled physics model

Reply #3 –
A bug report.
During a steam locomotive climbing up very long hill, if its speed became zero, it will jump to the next stop.

Re: [patch] Overhauled physics model

Reply #5 –
Quote from: z9999+ – on
During a steam locomotive climbing up very long hill, if its speed became zero, it will jump to the next stop.

I saw this happening when I tested the impacts of slopes. It happens, when speed goes below zero. I though it was a kind of playability issue that prevents convoys from haning around.

But now I see that calling the the code that moves the convoi (vehikel_basis_t::fahre_basis(uint32 distance)) converts negative distances induced by negative speeds to extemely high distances. BTW: I should include the distance calculation in calc_acceleration() as simply multiplying delta_t and current speed is not correct in the new iterative approach.
The journey is the reward!

Re: [patch] Overhauled physics model

Reply #6 –
Quote from: prissi – on
The only thing you add are acceleration for constant power (that is something that can be discussed) and several small stuff, which is not needed for the game world.
It makes a difference pulling 1 40t carriage or 10 4t carriages due to 10 times more 'small' roll resistance.

Quote from: prissi – on
Because I see no benefit in including friction factors for diferent waytypes. Especially since a sand road would have nearly a magnitude different one from a concrete highways.
Could be a parameter of the way object then   ;D
But that won't be correct either, as it depends on the vehicle as well.

Quote from: prissi – on
[...] and using constant like g is completely useless (last time I checked the world was still flat in simutrans ... ;) )
The flat world is a myth! There are hills and mountains nearly everywhere...  :o
But g is present on earth, even if it were a flat one.

Quote from: prissi – on
About engines not reaching topspeed: WIth the old formular the topspeed was given by:
(total_power/total_weight+1)^0.5/2500

The new model it should be (if it is really like the wikipedia formula):
v=((sqrt(27*A*P^2+4*kr^3*m^3)+3^(3/2)*sqrt(A)*P)^(2/3)-2^(2/3)*kr*m)/(2^(1/3)*sqrt(3)*sqrt(A)*(sqrt(27*A*P^2+4*kr^3*m^3)+3^(3/2)*sqrt(A)*P)^(1/3))
with m: m****, kr:friction coefficent, A: air drag and P: power. (I love computer algebra systems ... ). These are two other solutions, but they are complex numberS (and thus make actually not much sense to me, since the speed should be a real number.)
So it can be done, but I am not sure, if this is really progress in the end.
That's the formula! But before I can use it I have to compensate the runtime with some optimization elsewhere  ;)
The implementation looks far easier, but square and cubic roots still need a lot of time. Therefore the old formula is used for an approximation.
The journey is the reward!

Re: [patch] Overhauled physics model

Reply #7 –
Simutrans currently has a minimum speed (about 1/32th of the max speed). No convoi will go slower than this, even if it has zero power. Engines dying at slopes are not inteded and add nothing to the fun, only more micromanagement.

That the max speed formula is expensive, is not a problem, since it is only called in depots. But it is a big problem that the maximum load of the engines are changed; actually it is a no-no, since it means that all packsets needs rebalancings.

Concerning the performance, the main problem is that many stuff is recalculated on the fly. As written before in the comments this routine is one of the most frequent called routines and thus the optimisation with the integers instead of floats. Some examples for improvement are immediately visible: The track type cannot change and also the friction factors are the same for all vehicles, since they will all have the same waytype. Also the force calculation can be (up to the actual speed divider) put into a pre-calculated number.