Comments on: Steering, are you doing it right? Can’t share much of the details as its part of my work on Golaem Path ( Ahh ok, that’s very similar to the method Mikko Mononen was talking ( I didn't try yet bearing angle derivative based methods but they seem interesting as they provide more information on the collision such as "will the other will pass before or after me ?". What I'm saying about sample costs is applicable to many approaches: all kind of VO (RVO, SVO, HRVO...) and more (I use a relative position derivative based method). All these method find the best corrected velocity from a bunch of velocity samples, choosing the cheapest sample. The way you compute each sample cost is up to you, in the RVOlib implementation the cost depends on the time to collision and the distance to the preferred velocity but you can add more parameters easily. ORCA is quite different as the cost function has to fulfill certains constraints, otherwise the solver won't work. I didn’t try yet bearing angle derivative based methods but they seem interesting as they provide more information on the collision such as “will the other will pass before or after me ?”.

What I’m saying about sample costs is applicable to many approaches: all kind of VO (RVO, SVO, HRVO…) and more (I use a relative position derivative based method). All these method find the best corrected velocity from a bunch of velocity samples, choosing the cheapest sample. The way you compute each sample cost is up to you, in the RVOlib implementation the cost depends on the time to collision and the distance to the preferred velocity but you can add more parameters easily.

ORCA is quite different as the cost function has to fulfill certains constraints, otherwise the solver won’t work.

]]>
By: Jesse Cluff/2011/04/14/steering-youre-doing-it-wrong/#comment-4215 Jesse Cluff Mon, 16 May 2011 16:26:42 +0000 Nice article ! I am just wondering why you think RVO (and this king of algorithms) as a black box ? There is two easy way to get a perfect control on the way collisions will be avoided: - The cost function for the samples (taking into account the time to collision, the distance to obstacles, the deviation from preferred velocity and whatever you like) ; - The velocity space from which samples are taken. using those two options you can control whatever you want, am I wrong ? Nice article !
I am just wondering why you think RVO (and this king of algorithms) as a black box ? There is two easy way to get a perfect control on the way collisions will be avoided:
– The cost function for the samples (taking into account the time to collision, the distance to obstacles, the deviation from preferred velocity and whatever you like) ;
– The velocity space from which samples are taken.

using those two options you can control whatever you want, am I wrong ?

]]>
By: Jesse Cluff/2011/04/14/steering-youre-doing-it-wrong/#comment-2950 Jesse Cluff Mon, 18 Apr 2011 22:57:08 +0000 Steering is a wolf in sheep's clothing. For birds and fish yes, humanoids no. I have used it on many projects (first 2001) and it does what it's supposed to. I have since long abandoned this way of combining forces. When steering humanoid characters (supposed to look smart) around, you need to adhere to certain simple rules ( like: don't walk off a cliff ). Steering behaviors makes these simple rules a game of balancing unruly behaviors. For instance "separation" from enough neighbors would make you walk off the cliff. You can start adding rules where certain behaviors are combined in different ways, but you'll soon see that you're steering away from the original concept. For "advanced" behavior (humanoids), you probably need something more advanced than steering-behaviors. Having them wait for each other, keeping track of the objects they avoid, and remember objects they could not "push" out of the way. Steering is a wolf in sheep’s clothing.

For birds and fish yes, humanoids no.

I have used it on many projects (first 2001) and it does what it’s supposed to. I have since long abandoned this way of combining forces. When steering humanoid characters (supposed to look smart) around, you need to adhere to certain simple rules ( like: don’t walk off a cliff ). Steering behaviors makes these simple rules a game of balancing unruly behaviors. For instance “separation” from enough neighbors would make you walk off the cliff. You can start adding rules where certain behaviors are combined in different ways, but you’ll soon see that you’re steering away from the original concept.

For “advanced” behavior (humanoids), you probably need something more advanced than steering-behaviors. Having them wait for each other, keeping track of the objects they avoid, and remember objects they could not “push” out of the way.

]]>
By: Jesse Cluff/2011/04/14/steering-youre-doing-it-wrong/#comment-2819 Jesse Cluff Fri, 15 Apr 2011 16:54:46 +0000 Hello Jesse, Interesting alternative, just one note: <blockquote> Now I’ve never understood why there is a divide by numNeighbours followed by a normalize, my guess is that the normalize was just added later to fix a problem that dividing by numNeighbours wasn’t handling. </blockquote> At least on the OpenSteer I've seen, that's because the result of the sum is not a normalized vector. In the case of steerForSeparation, OpenSteer actually divides each vector by the square of its length (instead of the length itself, which would normalize it), so their average is not going to be a unit vector either. Since the three flocking steering methods are expect to return a pure direction vector, the end result needs to be normalized. This vector eventually gets multiplied by a weight, which is where I think your alternative gets interesting: instead of scaling a pure direction vector by a weight that might be fixed (or even if it's tuned on the fly), you've made this a function of the various forces being applied. Definitely something to experiment with. Hello Jesse,

Interesting alternative, just one note:

Now I’ve never understood why there is a divide by numNeighbours followed by a normalize, my guess is that the normalize was just added later to fix a problem that dividing by numNeighbours wasn’t handling.

At least on the OpenSteer I’ve seen, that’s because the result of the sum is not a normalized vector. In the case of steerForSeparation, OpenSteer actually divides each vector by the square of its length (instead of the length itself, which would normalize it), so their average is not going to be a unit vector either. Since the three flocking steering methods are expect to return a pure direction vector, the end result needs to be normalized.

This vector eventually gets multiplied by a weight, which is where I think your alternative gets interesting: instead of scaling a pure direction vector by a weight that might be fixed (or even if it’s tuned on the fly), you’ve made this a function of the various forces being applied. Definitely something to experiment with.

]]>
By: Jesse Cluff/2011/04/14/steering-youre-doing-it-wrong/#comment-2762 Jesse Cluff Thu, 14 Apr 2011 17:48:01 +0000 Cool article, thanks Jesse! For steering the devil is always in the details - be it the implementation of the algorithm - or even the tuning of certain parameters. Looking forward to read more how you tune and use steering. In-game - do you use the terrain mesh to cut-off and/or re-orient the final steering vector? Most of the original steering behaviors don't really take slopes into account. Cheers, Bjoern Cool article, thanks Jesse! For steering the devil is always in the details – be it the implementation of the algorithm – or even the tuning of certain parameters.

Looking forward to read more how you tune and use steering. In-game – do you use the terrain mesh to cut-off and/or re-orient the final steering vector? Most of the original steering behaviors don’t really take slopes into account.

Cheers,
Bjoern

]]>