As per my milestones, to demonstrate the procedural capability of the solution, I created a script to take basic input from the user: accelerate, decelerate, pivot (about y-axis).
The values in this script are then converted using inverse lerp to give proportional values which are used to define how far ahead of the biped the next foot marker is place and how fast the hips will rotate over the supporting foot.
The logic for locomotion is identical to that of the 2D biped – using the human gait phases as a switch statement to maintain both feet at opposing points in the cycle.
Implementing full directional control meant giving users the option to completely decelerate the biped to 0 velocity.
This meant having to add logic for the transition between standing and walking. When the biped transitions from standing state to walking state, which ever foot is furthest (or left if distance is identical) from the ‘next target’ marker is selected to enter swing phase.
Constraint Logic Issues
Many of the functions I had intended to re-use or implement to handle 3D locomotion were reliant on the angle values of other joints to determine their behaviour. For example, the foot does not reliably remain within the 3D bubble trajectory designed to eliminate all intersections. Behaviours to curve the path of the biped which required the hip and heel joint rotations are no longer viable as at any point during locomotion, the unconstrained solution will hyper extend or unnaturally rotate a joint to meet the target location.Perhaps the most difficult element to rectify without constrained joints is the end position of the hips and subsequent feet positions once the other foot has rotated the hip joint during support phase. When turning, especially in 3D, it would be preferable to calculate the appropriate end position of the hip joint, then manually arc it to best simulate natural motion. Instead, there is little to use as a reference since joint angles are unpredictable which also may lead to the model crouch walking or further undesirable postures during movement.
Outcome
For demonstration purposes figure 1 shows the biped moving forward in a straight line. |
| Figure 1: 3D procedural walk behaviour, walking straight ahead |
The unconstrained solution is not able to navigate turning/significant obstacles without going through extremely unnatural joint rotations.
I do not expect to be able to improve this behaviour to a near-believable level with the remaining development time. Instead, I feel my remaining time would be most efficiently used correcting issues which can be resolved without the reliance on the CCD constraints.
Next Objectives
I noticed while attempting to implement this behaviour I had overlooked the foot (heel to toe joint) placement.If the CCD constraints were currently working, the foot would stay at a legal angle compared to the ankle joint but would not orient to the supporting surface.
Leg intersections with obstacles are also extremely common without fully functional angle constraints. A behaviour to avoid and reposition the leg limbs is also required to improve the current reliability of the biped.
I will use the limited time remaining to focus on these issues and any subsequent ones that become apparent - both researching and attempting to fix the most needed.
Bibliography
Unity Technologies (2019). Unity - Scripting API: Mathf.InverseLerp. [online] Docs.unity3d.com. Available at: https://docs.unity3d.com/ScriptReference/Mathf.InverseLerp.html [Accessed 9 Jul. 2019].
