Polarith AI
1.8
Sensor

A sensor is a collection of Receptor instances. There are two different types of sensor shapes available: the planar and the spatial sensor.

Every Context component needs a valid sensor in order to do its work. It is also important to keep in mind that the shape of your sensor and your character controller are inevitably intertwined. For example, for a car-like sensor, as it is shown the following Figure 1 at the right, it makes not so much sense to add a force into the Direction which has the strongest magnitude. Instead, you need to translate the AI output to commands for controlling the car movement. So, e.g., the information received from the two receptors which model side mirrors must be handled individually.

Planar Sensor

The term planar denotes that all receptor Direction vectors are embedded in the same plane. Such planar sensor shapes can be easily created by using the inspector of the Planar Sensor serialized object and customized even further using the Planar Shaper component. There are two basic shapes available: a circle and a line. We highly recommend to start using a circle shape since our included example controllers work best with a circle shape for demonstrating how things work.

Figure 1: A set of example planar sensors, a line, a circle and a custom built sensor which might be used for a car-like agent.

Spatial Sensor

For Pro users only, Polarith AI provides another sensor type called Spatial Sensor. With this sensor, receptor directions can make use of the full 3D space for its orientation. Note, spatial sensors can only be created based on a spherical model. At the moment, there are a so-called UV sphere and icosphere to construct a sensor, whereby we recommend to start with a UV sphere due to its advantageous topology regarding steering behaviours.

Figure 2: An example spatial sensor created based on a UV sphere model.

Level of Detail

Another important aspect is the performance of the system. The receptor count has a significant impact on the overall performance. Thus, we advise to use as less receptors as possible but as much as needed to master a specific situation. For instance, an agent which moves in close proximity to a player should have a sensor with a higher receptor count than an agent which moves far away and is barely visible. Our system is very robust so that it supports to switch sensors dynamically at runtime. This way, you can programmatically use a low-resolution sensor and switch to a high-resolution sensor whenever needed. For that, you can use the Lod Group component which implements a proximity-based level of detail system.

Imprint