Ship Acceleration, Turning, Turning Acceleration and Turning Decel

[Remus]

Originally Posted by Georgiana Jennings Can we use SI units?

Radians?
You're cruel, you are!

Exactly what I believe to be the case--I can't test turning for 50ms because the time between the server receive the packets from the start and end of the turn will be greater than 50ms.

Look. I measure time by making sure I have a second hand on the Windows Sidebar clock and playing in windowed mode. 50 ms? I'm lucky if I can measure 5 seconds within 10%!

No you cannot test using time, so test using angle.
Do a turn using the keys and note down the lowest speed you reach. You have all the time in the world to note down the start and finish angles.
Now repeat using the rudder slider and attempt to end at the same angle (you might need to repeat a few times to get this right). Again, note down the lowest speed you reach. Is it any better?

In so many situations the actual time taken to complete a turn (which of course you have not measured) is less important than the amount of speed you have lost.

You could even be really clever and triangulate your position to reinforcement points, working out your before and after trajectories and knowing the start point of your turn (by noting the time) make a pretty good guess how long the turn took to complete.
Exactly how bored are you?

[MrTheOx]

a = A ( 1 - v^2 / V^2 ) is a way to describe acceleration at given time. As knts per second is velocity over time. With this formula we can describe a at a given fixed point in time, as speed is a function of time and acceleration.

In terms of game function you do not derive a through v, it's working it backwards but it is a fine way to describe a at a given time state and thus plot a range through a chart. There is a much simpler equation that most physics simulators use to determine a.

Newton tells us f = ma, therefore a = f/m. Since acceleration is the rate of change in velocity over time, and acceleration is force divided by mass, we can say that force divided by mass is the rate of change in velocity: dv/dt = a = F/m. Similarly, velocity is the rate of change in position over time: dp/dt = v

This means that if we know the current position and velocity of an object, and the forces that will be applied to it, we can integrate to find its position and velocity at some point in the future.

So lets talk about why you would take this approach. Well first off it's going to allow you to track and render each vessel in an x y coordinate system. In terms of designing a ship sim it would allow us to easily customize and edit our ships. We could give each ship specific mass and force. Each of which could be varied from ship to ship in order to give each ship a specific handling feel. If we wanted slightly more depth to our sim, each ship could be give a simple friction factor to the space the vessel moves in. You can also simulate a throttle effect, ie sail position, by allowing the user to vary the power setting. You can also vary power due to damage, in a much cleaner way than

a = A ( 1 - v^2 / (s d f(P) Vmax)^2 ) where a is acceleration at that moment A is ship stats sheet acceleration v is forward velocity at that moment s is sails slider percentage d is some function of sail damage f(P) is some function of the polar speed modifiers Vmax is ship stats sheet max speed

All sail damage and sail position would be a negative modifier to power, then in your next frame your dv/dt=a=f/m is reduced because f is less. This is a much simpler equations taking less processing power.

In fact the turning mechanics you have linked to do not really apply for sailing ships. The centripetal acceleration is so low and the sea resistance so high that it makes far more sense to consider the rudder as applying a turning force (moment) to the ship, changing the ship's direction, and the shape of the hull means the forces from the sails can only move the ship forwards, not sideways. I found a small child to draw a picture:

You assume that the sea resistance is high, in fact in a simulation we can model the resistance to what ever we like, in order to give our objects, the feel of ships. to paraphrase the words of Neo "you think thats water your ship is sitting in?" You dont need a complicated model to analyze hull friction through a fluid medium. You can generalize


Kind of rambling here but I think taking a look at this may help us. http://gafferongames.com/game-physic...ration-basics/
and this
http://gafferongames.com/game-physics/physics-in-3d/

[elessaria]

It was Morpheus, nub...

[MrTheOx]

Originally Posted by elessaria It was Morpheus, nub...

lol thanks

[Remus]

I really have no idea what you are trying to say, MrTheOx.

Yes, of course the game mechanics might use forces, but that is of little concern to me as in every situation I wish to consider masses are constant so I may as well use accelerations. It is acceleration that appears on the ship stats sheet, not mass or force.

I have already posted a free body diagram in post #12, the only area of uncertainty appears to the value of drag.

Originally Posted by MrTheOx You assume that the sea resistance is high, in fact in a simulation we can model the resistance to what ever we like, in order to give our objects, the feel of ships. to paraphrase the words of Neo "you think thats water your ship is sitting in?" You dont need a complicated model to analyze hull friction through a fluid medium. You can generalize

Yes, of course I assume that sea resistance is high, because it is. I know the devs could model it however they want, but why on earth would they use a centripetal model for turning when moments work so much better. Besides which we can see they have a model for turning moments about a centre of inertia from looking at how ships collide.

Kind of rambling here but I think taking a look at this may help us. http://gafferongames.com/game-physic...ration-basics/ and this http://gafferongames.com/game-physics/physics-in-3d/

I'll give you the rambling.

The first link merely describes how processors deal with differential equations. I did not know this, but it is of little importance. All we need to know is that game engines do process differential equations, and we know this already.
Incidentally, for most of my testing I cannot be bothered to work out the calculus for the integrations so I use Euler integration, typically with 0.1 second time intervals if I am trying out a model, or whopping 5 second (or, in this case, 10 degree) intervals if I am merely collecting data for analysis. I am well aware of the inaccuracies which bedevil this approach which is why I have focussed on turning at a steady speed, for this means no change over time and so no inaccaracy.

The second link says game processors use vectors. I am mightily pleased to see they do as it vindicates my post #12 sketch. I had thought you were arguing that calculations are done in cartesian geometry, which would be horribly complex.
I don't see anything in this article inconsistent with what I have posted, but if you want I'll add in the missing forces, and I'll change the rudder force into a moment, for this is surely how the game engine handles it (no need to add the ship half length into the calculation). I'll add in turning resistance too.

Now that I have split turning into two components, the turning moment is (probably) merely TA with a function of rudder position, probably nothing more than a straight lerp from 0 to 1 at full rudder. Turning drag is probably TA . ω^2 / Ω^2. As I have said, these are of little concern as in practice Ω is reached very quickly.
Lateral resistance is a function of lateral speed and is vary high indeed.

Incidentally from what I can see it is surely these lateral resistance forces that are the devil in ship collisions. I know the Arcadia's mass has been bandied around as a problem but my guess has long been this is only part of the issue.

Shall we do some algebra?
A warship with mass 10 Arcadias crashes into the side of an Arcadia.
Ship collisions probably do use conservation of inertia, therefore

M.V1 = M.V2 + m.v

There are a number of ways of resolving this. You could conserve energy as in a Newton's cradle, but more likely in PotBS would be that both ships end up at the same speed

M.V1 = M.V2 + m.v and
v = V2, therefore

M.V1 = V2 ( M + m )
V2 / V1 = M / (M + m)

If M = 10m then

V2 / V1 = 10 / 11 = 0.909

and the warship barely slows at all.

But we then have this lateral resistance force coming into play.
This is almost certainly some function of speed and now the Arcadia is hurtling sideways at a huge rate of knots. There is probably not a gread deal wrong with this as the Arcadia has such shallow draft and I expect draft is far more important than mass here.
However, in the game the Arcadia's lateral resistance force / acceleration is high like every other ship and so it rapidly stops moving sideways. As the warship's stem is hard up against the Arcadia's side, any forces on the Arcadia get transmitted directly to the warship and the warship's feeble acceleration from sails has no chance of overcoming the Arcadia's lateral resistance, and so the warship stops.

Of course, chances are the warship doesn't hit the Arcadia's centre of inertia directly, so it imparts some spin into the Arcadia. I think it would be as easy for the devs to lower the Arcadia's rotational inertia as it would be to lower the mass, but there will still be some lateral force imparted into the Arcadia, and so still you hit the lateral resistance. Furthermore, the arcadia will now be pushing sideways on the warship, meeting the warship's own lateral resistance force and therefore turning the warship away from the Arcadia, with all the linear deceleration that entails.

Collisions are a topic for another thread. By all means someone take it up.

[Kaede_Baq]

Math... We meet again, my old enemy...

[Georgiana Jennings]

I've never written a game physics engine, so it's interesting to see the tricks to model physics on a CPU. However, how does this change things for us?

Drag can be described as an acceleration, (-A/V^2)v^2 as Remus does, or (-2A/V^2)v in which case it is a jolt, or it can be a force in which case we're dividing by a constant. It could also be described directly as speed, (-A/3V^2)v^3 or as position (-A/12V^2)v^4. Obviously I mean differentiate and integrate over t, not v, I just got carried away because I don't do enough physics these days and it was fun.

If FLS were good boys and didn't stick in any constant offsets, we can biject the sets of values corresponding to each of these definitions, so at the end of the day all these approaches should be equivalent. We don't need to use (or even know, although I'd like to) how PotBS calculates its physics.

As Remus says, mass is a constant and working with forces, then dividing by a constant and integrating twice to get position would seem to include a superfluous step. In fact, the articles you linked are working in acceleration.

Also, Remus, shame on you--vectors are (IIRC) just a clever way of working with Cartesian geometry. I loved the Cartesian coordinate system mainly because it's what made geometry comprehensible to me, the Euclidean crap about polygons was just confusing.

[MrTheOx]

I'm not trying to argue one way or the other. If some one can work out a formula that describes turning, great. All I'm saying is, look at these approaches to how things are resolved, they may help.

Incidentally, I do not think anyone can work a formula which will accurately describe turning, turning speeds, accels or deccels over time. I don't think there is enough information displayed in the ship's stats to do so.

As for collisions, you don't have to do any conservation of mass calculations to determine position after collision has been detected by the physics engine. As collisions are typically handled by spring physics.


Arcadias can push most ship around, people use to complain about Red Devils pushing them into the wind for example. Therefore all a ship has to over come to push another ship around is it's damping force. And all we have to find is if the ship's force is greater than than the damping force and whether the point of impact is above or below the objects center of mass to determine which way it will rotate upon an impact. Most ships probably have the same damping force, which is why Arcadias can push so many ships around.

Originally Posted by Georgiana Jennings We don't need to use (or even know, although I'd like to) how PotBS calculates its physics. .

Actually we can get a pretty good bead on it. Potbs uses the Aeiga Physx engine and was built in C++. So if someone wanted they could try and use the Physx remote debugger to see what is what.

[Remus]

Originally Posted by Georgiana Jennings Drag can be described as an acceleration, (-A/V^2)v^2 as Remus does, or (-2A/V^2)v in which case it is a jolt, or it can be a force in which case we're dividing by a constant. It could also be described directly as speed, (-A/3V^2)v^3 or as position (-A/12V^2)v^4. Obviously I mean differentiate and integrate over t, not v, I just got carried away because I don't do enough physics these days and it was fun.

It looks like you are following in my shoes, Georgi

To save me hunting back through old textbooks, please someone remind me how you integrate dv/dt = v^2.

Also, Remus, shame on you--vectors are (IIRC) just a clever way of working with Cartesian geometry. I loved the Cartesian coordinate system mainly because it's what made geometry comprehensible to me, the Euclidean crap about polygons was just confusing.

I never really had to learn traditional Euclidean geometry.

But vectors do not need cartesian geometry. You do all those vector calcuations without reference to an extenal frame. It is only after completing the vector calculations that you need to convert back into cartesian co-ordinates. Vectors work just as well in an (r,θ) co-ordinate system or a spherical (ρ, θ, φ) system.

[Remus]

Originally Posted by MrTheOx I'm not trying to argue one way or the other. If some one can work out a formula that describes turning, great. All I'm saying is, look at these approaches to how things are resolved, they may help. Incidentally, I do not think anyone can work a formula which will accurately describe turning, turning speeds, accels or deccels over time. I don't think there is enough information displayed in the ship's stats to do so.

There probably isn't; Taelorn has said as much. But the thing is I don't entirely believe Taelorn.

As for collisions, you don't have to do any conservation of mass calculations to determine position after collision has been detected by the physics engine. As collisions are typically handled by spring physics.

Conservation of momentum. We have no exchange of mass in this game.
Yes, the actual collision probably is modelled as a spring; you need some means of converting momentum into force and springs are as good a way as any. But all the spring does is provide an additional equal force to each ship. Each ship still needs its usual model of external forces to calculate how to move.
Equal forces to each ship, so the spring by itself will not greatly slow down the warship which has 10 times the mass of the Arcadia; it is the Arcadia which moves the most.
The trouble is, it largely moves sideways and here it meets a huge resistive force (which might well be the same for all ships; this could be where the problem lies) which is some function of sideways speed.

I doubt that the spring rate k or damping coefficient b have much effect in themselves in respect of moving massive object poughing into stationary light object scenarios.