Unreal Engine 5.4 Feature Overview | Inside Unreal

0:00:00 short film 0:04:54 start 0:10:22 (animation/rigging) modular rig edtior *new 0:19:59 (animation/rigging) control rig 0:40:07 (animation/rigging) deformer graph *new *beta 0:43:34 (animation/rigging) skeletal editor *beta 0:46:36 motion matching 1:12:00 rendering 1:32:19 horde 1:54:22 Q&A motion matching sample release on june

The motion matching instructor needs a full vid of his own, he is a amazing teacher but would love it he had more time to even go deeper into the tech.

Great presentation Jose, you guys have solved many issues we ran into at Ubisoft in the early days and its super exciting to see... I love that "traditional dance cards" have basically become "choosers" which are much more scalable and easy to work with instead of huge animation files. We had our dance cards split up into STARTS, STOPS, PLANTS, CIRCLES etc, so Epic's solution is very elegant. Very excited to dig into this in June...

Lets give Jose and Chase a whole episode. They only had time to cover things at a high level. Also, Brian talks like John Carmack offloading stream of consciousness - Great to see! :)

This is one of the best and most important live tutorials, I hope I can see more of this type about (Animation Motion Matching, Customizing Metahuman) I hope Unreal provides good documentation on Motion Matching, he moves so fast and crowded his screen with many blueprints he prepared before.

Thanks!! I've really waited for this one. Great presentation Jose! Those features looks really cool, going to play out with them right now.

Nice GFX features, but what about the new networking features (physics replication, resim, predictive interpolation, etc.)?

Your DualQuatSkin component is exponential in runtime. If there is a bone influence that affects multiple vertices, that bone matrix gets converted again and again for each and every single vertex. Also, your Dual Quaternion base class has a bug in it for the multiplication operation. Please consider merging my pull request. I have a proper Dual Quaternion Skeleton node and I've fixed the DQ bug. I've also added lots of missing operations on the Dual Quaternion class. I've added unit tests for all the existing and added operation for dual quaternions.

Jose explaining motion matching be like: "I've done some off-camera mining!" 🤣

I have a question for Brian Karis: I have been trying to figure out ways to work around the fact that Nanite tessellation with displacement maps on landscapes don't give the displaced geometry collision (*No actual/physical deformation on the landscape it self*) One thing i have been thinking about the last cupple of days is to use landmass and the landscape brushes to create the displacement of the certain areas on the map you really want/need the displacement of certain material layers to be displaced in a way that would have the players/vehicles and so on to not be stepping/driving through the surface of the displaced parts. I know it could work really well for something like coastal rocks that you see down by the ocean. And also for desert sand hills. But what i'm curious about is the smaller detail such as: riverbed rocks - gravel piles - gravel slopes - forest tree roots and ground rock/bumps in conifer forests - dirt with small/medium pebbels - beach with rocks and etc Would it not be possible some how to implement a brush type or system that let you use the actual displacement map for a layer, and have it tile the same way it would do in the material painter system, and then apply the paint layer(s) that you want to the brush. And then let the brush deform the landscape with the displacement map and tile together with the layers you apply to it? I mean, if you scale the alpha texture (displacement map in this case) that is shaping the landscape, then the layers you apply will scale/tile in sync with the alpha texture?! This would in that case make the surface of the the alpha brush displace the landscape the same way that nanite tessellation with a displacement map would when all texture sample node are using the same landscape coordinates scaler/texture scaler node. And the materal layer would not even need a deisplacement texture sample since you do all that with the brush. So all you would have to do is of course either create a shape for it that is covering the same area you would paint that layer on to. OR! if there was a masking option that you could use a weightmap in, you would only cover that area no matter how large the brush is. So you can cover larger areas with the brushes, but mask the areas you want it to affect. I would also dare to say that there would almost not be any need for users to paint the material layers like we do now, except the surface areas that you don't need displacement for. The only usefull thing i can't see this working on without some smart solution for is to be able to add the detailed displacement onto cliffs - slopes - mountains that is already there if using a heightmap to create the landscape.... BUT! i guess you could place out brushes to create them with this on them. But it would be really nice if the brushes had a ADD-MULTIPLY-BLEND setting, so that you could also add the fine detail on slopes and mountains/cliffs like this, then apply the different layers to the brush with blend parameters like Slope - Height - Cavity - Convex - Noise I'v been thinking about trying to create some brushes in GAIA or World Creator that would represent different parts of a landscape, and also use material layers that has 2-3 different biome textures masked or blended. And then use a colormap for the far distance blend that also blends nice with the rest of the biome areas... Since only 40% top would need displacement with collision, it should not be that hard to make something that works and also looks good :D

Concerning control rig, what would be great is auto rigging based on motion matching... Every rotational sphere, which I would model internally as a pair of non-consumer facing 1D spin matrices to support parallel computation of the component motions. I still have some changes to update in another aspect of the engine's audio features, but I'll open up a pull request when I can for you guys to review my code...

If I were Epic Games, I would hire Jose permanently. He is in his element and solves problems constructively, this way the Motion Matching process would be more effective and faster, especially when someone works with passion in a given topic, best regards. Somehow I didn't notice before, but under the Credits Jose is already employed at Unreal Engine. This means that we have the same thoughts, greetings once again to the entire Unreal and Epic Games team.

Thx to all of you, great work! Is there any documentation about how to use dynamic nanite tessleation/displacement?

Jose should have an entire episode dedicated to him. He was only able to touch on topics at a high level!

I hope this example uses and highlights the BlueprintThreadSafeUpdateAnimation overridable function, Property Access and FastPath in the AnimBP because some of the recent Samples from memory haven't and neither do the OOTB Templates and it would be a huge performance boost for everyone from the start.

render improvements in order: Tesselation and displacementbounds considerations compute based shaders for postprocessing allows for more speed and more custom effects. custom software based Variable rate shading for Nanite. Removal of empty draws, had to do a Drawcall for every material in scene, (if scene or not) now the GPU trims that. TSR improvement, history resurrections to fix disocclusions (less breakup and fogging) (saw it, lost it, saw it again, bring that back) orthographic camera support (satellite) heterogeneous volumes (raymarched smoke,fire,dust sims) render parallelization of render thread. (more work coming) cut rendertime cost in half in some instances. reducing time or number of shaders that need to recompile, and time reduction per shader too more work on bindless rendering. (Still WIP experimental?) RT Vulkan, should match the featureset, (experimental) RT Perf improvements, making Hardware RT Lumen the more "default" mode, transitioning away from software SDF mode. cases where the old mode is still more efficient sometimes, expecting Hardware RT to be the dominant form soon. (good for long distance RT for us) large world coordinates on GPU not really double precision, its not double in shaders its using a different format then a normal double. not all GPU's support true doubles. perf for doubles is terrible, so does emulation, dual float setup (high low bit) should avoid stepping and banding far away from origin. Neural network engine abstraction for NN's coming into the engine ISPC on CPU or DirectML on GPU generic framework for ML inferencing in engine style-transfer usecases etc.

awesome vid, id really like Jose to explain the A-Z once the MotionMatching demo is out of the whole thing, hes really easy to listen to and follow (despite me being tired from work)

Is your Motion Matching example project going to show how to get around issues with using it in a Multiplayer project because the Trajectory isn't replicated ?

How would we setup the continious pose cost bias or continious pose settings to handle different walk-run-sprint animations for something like when the player is getting tired/hits a sharp angle on the surface and perhaps stumbles a little. Or to just blend in some animation that has the player checks time on a watch/Look around when walking. Maybe cough or change the posture a bit after running for a long periode? And even much more random or preset changes that you want the character to do based on different meet parameters, or elements happening like even rain, wind, snow and even getting shoot at for instance... If getting shoot at, the character might try to evade by covering it head like someone would do IRL and so on.... It would be really nice if you guys dis a stream showing of some of these different scenarios and addons to the standard movement ( idle-walk-run-sprint-crouch-prone) animations added to the database for motion matching.

@BrianKaris -- There's a precision problem with lumen reflections when far from the origin, despite the LWC improvements. Move your scene at 100+ km from the origin, then bring the camera very close to the mirror surface and you'll see very blocky reflections. And the farther you go, the worse it becomes.