Determining rotation for collision avoidance?

Hi i was wondering what the best way to determine which way a character should rotate when it its ray returns a hit.

I have thought about casting two rays so that the one least close to the collier determines the direction, but i cant figure out how to code the ray direction.

any help is very appreciated.



alt text

        // C# code version of JS provided by  Motionreactor below
        RaycastHit hit;
        Ray ray = Ray(gameObject.transform.position, Vector3.forward);

        if (Physics.Raycast(ray, hit, 10))
            Debug.DrawLine(ray.origin, hit.point);

You can cast a ray in a specific direction like this:

var hit : RaycastHit;
var ray : Ray = Ray(gameObject.transform.position, Vector3.forward);
if(Physics.Raycast(ray, hit, 10))
    Debug.DrawLine(ray.origin, hit.point);

Vector3.forward could be any Vector direction you wish.

This steering behavior and others are implemented in UnitySteer, which is a port of Craig Reynolds' OpenSteer (the reference on autonomous steering that MotionReactor linked to is Reynolds' as well).

The function you'd be interested on is steerToAvoidObstacles, or maybe steerToAvoidNeighbors.

Once you begin getting into the fnier points of steering, such as a group of vehicles attempting to behave reasonably when encountering each other, you might want to look at Mikko Mononen's Project Cane, as well the other articles he has posted on his site on the topic of velocity obstacles.

To close, I don't actually recommend you use raycasting for every aspect of navigation. For static areas like walls, a navigation mesh and AngryAnt's Path is a better option.

Having done a "bit" of this stuff over the years, I agree with Ricardo's assessment cautioning you against extensive use of ray casting for navigation. The corner problem that you are encountering is a perfect example where ray casting, and more generally, purely reactive steering becomes problematic. For example, in corners, as you are turning away from the corner you typically wind up moving closer to one side of the corner or the other. A purely reactive solution (e.g., turn in the direction of most space) will cause you to move back into the corner and cause the oscillation you are seeing.

As Ricardo mentions, Mikko Mononen's website has a superb set of links to the latest papers in the field, most of which are based on a concept known as velocity objects (and variants such as reciprocal velocity objects). The big idea of velocity objects is that, based on the relative motion of 2 objects, it divides velocity space into those velocities (speed and direction) that are collision-free over some time horizon, and those velocities that will result in a collision over that time horizon. When tied to a planner that provides, in effect, a preferred velocity (namely one that will get you to the goal position), you can arrive at the closest velocity to your preferred velocity that will still be collision-free over the time horizon. At the end of the day you need a robust local steering (collision-avoidance) system as well as a nav. planner of some sort.