To make SetPos works with async physics, it was modified to register a
position offset that would be applied to the real position during the
simulation.
A common pattern to teleport NPC in scripts is a sequence of SetPos/Disable/Enable in the same frame.
Since Disable/Enable creates a new physics actor using last known
RefData::Position, the registered offset never get a chance to be applied.
Modify disable() to call moveObject with the offset applied, so that the newly created physics actor will have up-to-date position
For actors with big bounding box given constants may not work properly like
it's not possible to get close enough to actor from a given angle to make it
move.
When distance between start and end point is greater than max radius of area
possibly covered by navmesh there is no way to find path via navmesh. Also if
distance is greater than cell size navmesh might not exists withing mentioned
area because cell is not loaded therefore navmesh is not generated. So minumum
of these values is used to limit max path distance. Assuming that path
actually exists it's possible to build path to the edge of a circle. When
actor reaches initial edge path is built further. However it will not be
optimal.
This allows to distribute AI reaction calls over time.
Before this change actors appearing at the same frame will react in the same
frame over and over because AI reaction period is constant. It creates a
non-uniform CPU usage over frames. If a single frame has too many AI reactions
it may cause stuttering when there are too many actors on a scene for current
system.
Another concern is a synchronization of actions between creatures and NPC.
They start to go or hit at the same frame that is unnatural.
The sunglare works by comparing an occlusion query with depth testing on
against one with depth testing off to determine if there's anything
closer to the camera than the maximum depth buffer value. For the depth-
tested query, the depth range is set from 1 to 1 so it's always drawn at
the maximum distance. Originally, we had the depth function set to LESS,
meaning that the query would always fail as 1 is not less than 1, but
also glPolygonOffset was used to move the query by "the smallest value
that is guaranteed to produce a resolvable offset for a given
implementation" closer to the camera. While other driver and hardware
combinations do that, Mesa seems to be clamping to the depth range, so
still failing.
Instead, it's simpler to just get rid of the polygon offset and change
the depth test to LEQUAL as 1 *is* less than or equal to 1, but not than
any other possible depth buffer value.
