We’re excited to share a few of the new features now available on the Master branch on GitHub. To be able to try out these new features, you will need to download the source code for the Master branch and build the Engine yourself. For more information about how to build the Engine from source code, please see this page. The Master branch on GitHub is constantly being updated and is not quality tested so it may be potentially unstable. We do not recommend using the Master branch for project development. If you wish to wait, these features will be made available to all in an upcoming official release.
Bone-driven Animation Controllers
Bone driven controllers allow you to adjust one or more components of a Driven bone based on the motion of a component of the Driver bone.
In this example, the grenade bone has no authored animations, and is being driven in two axes as a function of the thigh_r bone. Any blend of animations ends up working well without a lot of hand-authored tweaking because it is being calculated at runtime.
You can either take the driver value directly with a multiplier, remap it into a new range, or use a curve asset to drive the motion. Using a curve is usually the best approach as it lets you define the response naturally and interactively tweak points/tangents, seeing the changes in real-time.
Some notes on usage:
- The component selection (Translation X/Y/Z, etc…) is always in parent bone space; you can select the parent of the bone and look at the coordinate system when you are trying to figure out which axis to drive (turn the mesh view off to see the axes).
- Use the new observe bone nodes to figure out the range of input motion and observe the driven value. These let you print out the current position of a bone (at that particular point in the animation tree) and have a couple of options for coordinate space and whether to display relative to the reference pose. You’ll typically want Parent Bone Space, Relative To Ref Pose when working with Bone Driven Controllers.
The observe bone nodes are meant for debugging. They don’t cost much but are not currently compiled out of a shipping build, so you should probably remove them when you are done working with the graph.
Smart Resizing for Transform Details UI
The vector and rotator widgets now support automatically rendering in a more compact mode as the details panel shrinks, making it possible to edit properties over a wider range of widths.
Rotator UI Consistency
Rotators now display everywhere in a consistent order as XYZ, rather than being displayed as XYZ in the level editor but as Pitch, Yaw, Roll (YZX order) in Blueprints.
In a Blueprint:
In the level editor:
All existing content is automatically updated and will work as expected, but you may notice wires crossing that didn’t cross before since the order has changed.
As a refresher (this information is also displayed in the tooltips):
- X is the roll value (rotation about the X axis, typically the forward vector, so tilting your head clockwise/counterclockwise)
- Y is the pitch value (rotation about the Y axis, typically the right vector, so looking up/down)
- Z is the yaw value (rotation about the Z axis, typically the up vector, so turning to face left/right)