Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Agent specs: clarify maxsteeringforce meaning (doc) #15

Open
netgusto opened this issue Nov 22, 2017 · 9 comments
Open

Agent specs: clarify maxsteeringforce meaning (doc) #15

netgusto opened this issue Nov 22, 2017 · 9 comments
Assignees
Labels

Comments

@netgusto
Copy link
Member

The steering limit is how much the agent velocity can change from one tick to the other.
Corresponds to the max length from the tip of the current velocity vector to the tip of the new velocity vector.

=> defines maximum acceleration between ticks, whatever it's direction (forward acceleration, braking, or turning).
=> also means that, depending on the limit value, one could not turn as fast as required when at full speed.

@netgusto netgusto self-assigned this Nov 22, 2017
@johnsudaar
Copy link

Not sure if i understand that correctly, you're saying that the maxsteeringforce is the max acceptable euclidian distance between our current speed vector and our next tick speed vector?

So maxsteeringforce = max(||vc - vn||) (where vc is the current speed vector and vn is the next tick speed vector?)

@johnsudaar
Copy link

And if true what are you doing if we send actions that does not respect these conditions ? Will you only cap the magnitude of the acceleration vector that we sent to you on this tick ? Will you ignore our acceleration vector? Something else ?

@netgusto
Copy link
Member Author

yes

Given A the current velocity vector and B the next (desired) velocity vector, the steering force vector is equal to B-A, and it's magnitude is bound to [0,maxsteeringforce].

@netgusto
Copy link
Member Author

As for every actions taken by the agent, if directives max out the specs, the directives are capped to the max available for the action.

@johnsudaar
Copy link

johnsudaar commented Nov 24, 2017

How are those caps applied? Will you only cap the vector magnitude or can you also do things on the vector components directly.

(Will our acc. vector direction always be respected by the game engine or can you also change our acc. vector direction?)

@xtuc
Copy link
Member

xtuc commented Nov 24, 2017

Btw please feel free to PR the documentation to clarify this here: https://github.com/ByteArena/docs

@netgusto
Copy link
Member Author

netgusto commented Nov 25, 2017

How are those caps applied? Will you only cap the vector magnitude or can you also do things on the vector components directly.
(Will our acc. vector direction always be respected by the game engine or can you also change our acc. vector direction?)

One point I'd like to make first to clarify things up: a physical acceleration (as we're speaking about here) is not necessarily an increase of the "speed" of the agent, but any change in the agent velocity; so, what we call a change of direction (even while keeping constant forward speed) is in fact an acceleration; and in fact even what we commonly call a deceleration (reduction of speed) is concretized by a physical acceleration pointing towards the back of the agent.

Building on this, any change of the agent velocity (being forward, backwards of sidewards during turns) is constrained by this max steering force (could be named "max change of velocity" for that matter).

It can be perceived in these situations :

  • linear accelerations of the agents are bound to constraint (ie, they cannot go from 0 to full speed in a tick, and vice versa)

  • independently of their maximum angular velocity contraint, agents going fast (ie having a velocity vector of great magnitude) might see their rotation rate reduced by the constraint of maximum steering force; the faster you go, the slower you can turn

So to answer your question now : when capping, we keep the orientation of the desired (new) velocity vector, and set it's magnitude to the maximum it can be to respect the constraint (can in fact reverse the desired velocity vector if needed.

@netgusto
Copy link
Member Author

netgusto commented Nov 25, 2017

Thinking about this :

when capping, we keep the orientation of the desired (new) velocity vector, and set it's magnitude to the maximum it can be to respect the constraint (can in fact reverse the desired velocity vector if needed.)

It might not be the best solution though, because it will "decelerate" agents that make over-specs turns rather than just reducing the rotation angle.

In the case of changes of direction, we could maybe try first to find a rotation of the desired velocity that respects the constraint ?

@johnsudaar
Copy link

johnsudaar commented Nov 27, 2017

Well, no it wont decelerate them, it will, as you want, reduce the angle speed:
Let's say that you'll only permit a anglurar velocity of pi/8 per tick and i'm going at a velocity of (1, 0). If i make an acceleration of (0, 1) (thus trying to have an agular velocity of pi/4, you will change my vector amplitude from 1 to 0.5, so the applied acceleration will be (0, .5) thus my new velocity will be: (1, .5) and my angular velocity will be pi/8.
I wont decelerate. (in fact i've accelerated with a rate of .25/t).

@netgusto netgusto modified the milestone: v0.0.11 Jan 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants