Title: **[patch] Overhauled physics model**

Post by:**Bernd Gabriel** on **October 31, 2009, 01:22:18 AM**

Post by:

Quote from: Bernd Gabriel on October 27, 2009, 11:26:57 PM

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 passengers 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.

Title: **Re: [patch] Overhauled physics model**

Post by:**z9999+** on **October 31, 2009, 04:30:04 PM**

Post by:

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

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

Title: **Re: [patch] Overhauled physics model**

Post by:**prissi** on **October 31, 2009, 08:42:01 PM**

Post by:

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: mass, 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.

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: mass, 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.

Title: **Re: [patch] Overhauled physics model**

Post by:**z9999+** on **November 01, 2009, 11:27:41 AM**

Post by:

A bug report.

During a steam locomotive climbing up very long hill, if its speed became zero, it will jump to the next stop.

During a steam locomotive climbing up very long hill, if its speed became zero, it will jump to the next stop.

Title: **Re: [patch] Overhauled physics model**

Post by:**wlindley** on **November 01, 2009, 01:18:10 PM**

Post by:

Quote from: z9999+ on November 01, 2009, 11:27:41 AM

During a steam locomotive climbing up very long hill, if its speed became zero, it will jump to the next stop.

Wormhole singularity? ;)

Title: **Re: [patch] Overhauled physics model**

Post by:**Bernd Gabriel** on **November 01, 2009, 04:32:00 PM**

Post by:

Quote from: z9999+ on November 01, 2009, 11:27:41 AM

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.

Title: **Re: [patch] Overhauled physics model**

Post by:**Bernd Gabriel** on **November 01, 2009, 05:16:30 PM**

Post by:

Quote from: prissi on October 31, 2009, 08:42:01 PMIt makes a difference pulling 1 40t carriage or 10 4t carriages due to 10 times more 'small' roll resistance.

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.

Quote from: prissi on October 31, 2009, 08:42:01 PMCould be a parameter of the way object then ;D

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.

But that won't be correct either, as it depends on the vehicle as well.

Quote from: prissi on October 31, 2009, 08:42:01 PMThe flat world is a myth! There are hills and mountains nearly everywhere... :o

[...] and using constant like g is completely useless (last time I checked the world was still flat in simutrans ... ;) )

But g is present on earth, even if it were a flat one.

Quote from: prissi on October 31, 2009, 08:42:01 PMThat's the formula! But before I can use it I have to compensate the runtime with some optimization elsewhere ;)

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: mass, 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.

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.

Title: **Re: [patch] Overhauled physics model**

Post by:**prissi** on **November 01, 2009, 08:50:05 PM**

Post by:

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.

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.