Articles

Over the weekend I pushed some UnitySteer changes to the development branch on Github. Some of these came about as a result of testing in unexpected conditions, so I thought a write-up might be interesting.

I was looking for some simple prototyping models, to give a better visual idea than with the cubes. Matt from M2H kindly shared some funny looking figures from their Vikings and Bankers prototype, which I promptly added.

They had a characteristic I hadn’t expected: after exporting them from Blender to Unity, the pivot point ended up at the base of the figure. This meant that the vehicle was off-center, as can be appreciated on the grey outline here:

After some hemming and hawing, I ended up adding a Center property to the Vehicle class. It behaves much like the center on a SphereCollider, and is affected by the parent transform’s scale. For consistency, I extended the same behavior to the vehicle radius.

Testing this pivot point issue brought to my attention some issues from OpenSteer’s implementation of the method for finding an intersection between a line and a sphere. This is how a box is perceived as a SphericalObstacle:

In many cases on this test scene, the OpenSteer implementation just didn’t detect any collisions with the circle. Looking into the Paul Bourke derivation referenced on the code, there were some implementation decisions that didn’t make sense to me – for instance, the future vehicle position seemed to be used only for calculating the distance after the intersection point has been estimated, but not for estimating the line endpoint itself. I ended up re-writing FindNextIntersectionWithSphere and updating the method for steering away from a spherical obstacle.

There was a bit of a funny overcompensating bug, in a case where the implementation still detected an intersection when the obstacle was already behind it:

But I’ve fixed it and avoidance now behaves as expected:

We now have much smoother behavior, even when navigating multiple obstacles (cyan circles are the vehicle’s perception radius, the cyan lines their intended path when they detect an obstacle, the red and magenta lines trace vehicles and obstacles they’re steering away from):

Funny how something as simple as looking at a model that is a bit different from your tests can lead you to improvements you hadn’t initially planned.

Of course this still follows what Mikko referred to in his Paris talk as the sumo approach, as it is still following a similar line of thought to the one used in UnitySteer. The good thing is that ever since the reorganization, replacing this with an velocity obstacle-based approach would be straightforward, so it’s something that might be in the cards in the near future.