Polarith AI
1.8
front-end / back-end: AIMPlanarAvoidBounds | PlanarAvoidBounds
inherits from: AIMRadiusSteeringBehaviour | RadiusSteeringBehaviour
This behaviour works similar to Planar Avoid, so PlanarAvoidBounds is used to actively avoid obstacles. The difference is, as the name suggests, that this behaviour also considers the boundaries of the obstacle objects which should be avoided. For this to work properly, the objects which are perceived by the behaviour need to have a collider attached, or alternatively, the property BoundsType needs to be set to Visual OBB.
Concerning the default parametrization, an agent that moves directly towards a wall will end up moving parallel to the wall for avoiding it. This is achieved by checking two possible avoidance direction towards the obstacle (left and right). These directions are highly dependent on the given AvoidanceAngle and the current angle towards the boundaries. The avoid direction which faces further away from the obstacle is preferred.
This component has got the following specific properties.
| Property | Description |
|---|---|
AvoidanceAngle | Determines the two possible avoidance directions in degrees (left and right) with respect to the current movement direction of the agent. |
Offset | If this value is greater than 0, the agent faces further away from the obstacle bounds after the avoidance maneuver is done. As against with an Offset lesser than 0, the agent faces towards the obstacle bounds after the avoidance maneuver is done. At last but not least, with an Offset of 0, the agent remains perpendicular to the bounds after the avoidance maneuver is done. |
BoundsType | The applied bounding box model: either axis-aligned bounding box (AABB) by collider, oriented bounding box (OBB) by collider or OBB by visual bounds (sprite/mesh). For more details, have a look at the bounding box remarks below. In order for this to work with meshes, a received object must not be static, or otherwise, no visual bounds can be received. |
This behaviour requires valid velocities. So, if an agent has no Rigidbody attached, a Steering Tag which has TrackVelocity activated needs to be present.
The following figure demonstrates how this behaviour works.
Figure 1: With an Offset of 0, the agent's intend is to align itself with the horizontal line (green). The angle alpha (blue) determines the value of the actual applied avoidance angle beta (pink) which is also based on the AvoidanceAngle. An Offset greater than 0 would rotate the horizontal green line further away from the bounds and vice versa.
This angle defines the possible avoidance direction (left and right) with respect to the current movement direction of an agent. For example, if the following is given:
AvoidanceAngle of 45°.Then, the resulting two avoidance directions would be approximately (-0.7, 0, 0.7) and (0.7, 0, 0.7). So, the further the agent faces away from the obstacle, the more the actual avoidance angle decreases. This is intended to prevent overshooting and oscillating when the agent is parallel to the obstacle. Note, this parameter is highly dependent on your controller. For a direct controller, a smaller value (~0 to ~5) might be a better choice, as against a physics-based controller normally benefits from a larger angle (~20 to ~40) in order for the applied forces to have an impact on the Rigidbody(2D).
The difference between the bounding box types can be seen in the Figure 2 below.
Figure 2: Illustrates the difference between an AABB (left) and an OBB (right).
Here, the raw Collider.Bounds information coming from Unity's Collider are used. These bounds represent an AABB. Although this is the fastest option, if the rotation of the object changes, the bounding box does not rotate accordingly. It changes completely like it is shown in Figure 2. Hence, it is advised to use this mode when your objects are axis aligned and do not change during gameplay like, for instance, static walls.
This bounding box type rotates accordingly to the object orientation, like it is shown in Figure 2. The disadvantage is that the calculation is more expensive. However, it may often be necessary to use this alternative, e.g., every diagonal wall would require this option. So, unsurprisingly, everything that is not axis-aligned.
Works exactly like a collider OBB except that the visual (sprite/mesh) bounding box is used rather than the bounding box defined by the object's collider. In order for this to work with meshes, a received object must not be static, or otherwise, no visual bounds can be received.