Currently the SteerForNeighbor behaviors, such as SteerForCohesion, SteerForSeparation and SteerForAlignment, all come from a base class on which CalculateForce iterates over the detected vehicles, checks if they're still valid, and verifies that the vehicle is in the neighborhood before adding up its contribution.
This has the advantage that we can configure some values such as the angleCos on a per-behavior basis, but the disadvantage that we're evaluating some values and iterating over the list multiple times, when one could suffice.
I'll update it so that:
Each SteerForNeighbor behavior exposes CalculateNeighborContribution.
SteerForNeighbor itself will always return Vector3.Zero for its own force, and will not have the current radius and layer checking configuration properties.
A new SteerForNeighborGroup will aggregate all existing SteerForNeighbor behaviors, and iterate over the neighbor list only once, calling the relevant methods on each.
This will likely make a difference mostly on larger clusters.
ricardojmendez
commented
10 years ago
Currently the SteerForNeighbor behaviors, such as SteerForCohesion, SteerForSeparation and SteerForAlignment, all come from a base class on which CalculateForce iterates over the detected vehicles, checks if they're still valid, and verifies that the vehicle is in the neighborhood before adding up its contribution.
This has the advantage that we can configure some values such as the angleCos on a per-behavior basis, but the disadvantage that we're evaluating some values and iterating over the list multiple times, when one could suffice.
I'll update it so that:
This will likely make a difference mostly on larger clusters.