The human kinematics model is a simple model of human movement.
The entity will speed up, slow down, and turn instantly when the requested values change. It maintains an appropriate posture for movement and takes current terrain conditions into account.
Inputs to the Model
The model accepts the following control inputs:
-
Speed
-
Facing Direction -- topographic heading
-
Movement Direction -- topographic heading
-
Desired Static Posture -- posture entity should assume when not moving, e.g standing
Other factors taken into consideration:
-
Soil Type -- for example, a human can move faster over pavement than it can over sand.
-
Potential Collisions with Terrain -- do not walk through walls.
-
Terrain Pitch -- along the direction of movement.
-
Maximum Speed -- upper bound on a human's speed.
-
Maximum Slope -- upper bound on slope a human can move.
Resulting Behavior
The model responds instantly to changes in the control inputs. For example, if an entity is being controlled in such a way as to follow a route (for example by the DtHumanMoveAlongController, it will abruptly change direction at each vertex along the route, at a constant speed.
Model Details
The model must be ticked periodically. Each tick, the length of time of the previous tick, dT, is available as a parameter in the current tick. Below is an outline of what the model does each tick:
-
Retrieve the 'old' state variables (values from the previous tick) from the entity's state repository:
-
old_local_position
-
old_local_velocity
-
old_body_velocity
-
old_local_orienation
-
Compute old_direction_of_movement (topographic heading) from old_local_position and old_local_velocity.
-
Check the input ports for new values. If new data is available then use it, otherwise use previous values for:
-
desired_speed
-
facing_direction
-
movement_direction
If the following condtions for the entity are true:
-
has not been repositioned (e.g. via a "drag and drop")
-
old_body_velocity = 0
-
desired_speed = 0
-
is facing in the same direction
then no additional work is necessary and the computation for the tick is complete. Otherwise, we need to compute new values for state and update the entity's state repository.
-
Compute the max_speed that the entity can move over the terrain:
-
Initialize max_speed with data from the entity's state repository.
-
Compute the new direction of movement for the entity
-
Compute the terrain pitch under the entity, at its current position and along its direction of movement,
-
If pitch is positive (i.e. entity is moving uphill), compute a scale factor and apply it to max speed:
pitch_scale_factor = 1 - ( pitch / maximum_allowed_pitch )
max_speed *= pitch scale
-
Compute the new_body_velocity for the entity. Use max_speed as an upper bound on desired speed, as necessary.
new_speed = desired_speed
if ( new_speed > max_speed ) then new_speed = max_speed
new_body_velocity.x = new_speed
new_body_velocity.y = 0
new_body_velocity.z = 0
-
Compute the new projected location. Entity is initially oriented to face along movement_direction at its old_local_position.
-
Create a 3x3 rotation matrix that represents the rotation of the about the topographic Z-axis, only taking the movement_direction heading into account.
-
Project new_body_velocity into topographic coordinates
-
new_projected_location = old_local_position + project_velocity * dT,where dT is the duration of the previous tick (in simulation time).
-
If model has been configured to check for terrain collisions, it will check to see if it is blocked by terrain. If so, it will set the entity's velocity to zero. The algorithm for determining if the entity is blocked by terrain is to check for a terrain intersection by a chord going from the old bounding volume center to the new center point of the front face of the bounding volume. If the entity is blocked, it positions the entity such that the front face of the entity's bounding volume is even with the intersection point.
- Note:
- This algorithm is only applicable when the entity is moving forward.
