Hey there,
Apologies for the delay, Epic has been on summer break.
Will Smart Objects ever be movable? For example, like the Witcher case where an apple rolls on the ground and a pig chases it to eat it - today Smart Objects are static.
This is theoretically possible, but you may need to make modifications to ensure the registered position is updated in the subsystem when it changes.
Do you recommend using Smart Objects for a first-person player?
Yes, ultimately, Smart Objects are a payload system that creates a base for placement and then what should happen.
Do Smart Objects work well with level streaming?
Yes, with the caveat that if the level or partition streams out, the smart object is not there. So state management still needs to be a thing. We don’t have anything in smart objects to handle the unloaded state.
What’s the best approach when the trajectory changes dramatically for a huge creature that needs time (1-2 m) to kill its inertia? Is it better to interpolate the trajectory smoothly into the new one, or let the animation leave the trajectory (and potentially leave the navmesh)?
This is a complex question because it depends on a bunch of factors. Are you using root motion or are you capsule-driven? Does your motion model already have the capsule with the inertia setup the way you would like it to feel?
Theoretically, if you are capsule-driven and you’ve tuned the movement of the capsule to your liking, animating to that capsule’s trajectory data will give you quite good feeling results, and then you can handle some edge cases like hitting a wall or ledge or something. Then, with offset root motion, you could have some further spring tuning on top of whatever your capsule is doing. We have put more effort into a tunable spring model for Mover, which focuses more on what the capsule is doing, and then the animation follows.
Are there interesting differences between bipeds and quadrupeds from the perspective of animation content for Motion Matching?
There are two considerations.
- Handling speed/gates/turns in a world where, generally, animals don’t “strafe”. There is a great talk from the RDR2 folks on their horse locomotion that I generally recommend.
- https://www.youtube.com/watch?v=8vtCqfFAjKQ
- Experimenting with different channel configurations to track for motion matching.
- 4 limbs position + velocity
- 4 limbs vel + displacement from front left to front right + displacement rear left to rear right
Generally speaking, if you follow GASP’s approach of limiting your match to specific subsets to handle different scenarios like pivots and turns, it should work well to handle your transitions for natural movement. Smooth gait transitions are harder as there is no blendspace support in motion matching today.
In GASP, all trajectories are built for the player from a simple input vector. But NPCs can have far more complex trajectories, for which content cannot realistically be authored (there are effectively millions). What’s the best approach here - for example, simplifying trajectories?
Yes, simplifying your trajectories is probably the best approach. For NPCs, we generally follow the simple input vector provided to the capsule and then layer on procedural elements to smooth things out, using the same animation data as our player set.
As a simpler locomotion example, in the Game Animation Sample when an NPC changes directions like in a 85 degree change it does it instantly, auhtoring for that trajectory to then have the proper coverage becomes a problem. So instead we allow the trajectory to be what it is, and then we use added logic in the ABP to choose the a subset of our locomotion data to determine a pivot, then we let motion matching decide the best score. Then we use procedural things like foot planting, offsetting the root bone, and orientation warping to get them facing the direction of the stick. This allows us to be much more deliberate with what we support while keeping our animation numbers down.
Is there more to your question here that I might be missing?
What content guidelines can you give for root movement - should the root move linearly, should it always stay under the hips/pelvis, should its direction match the body’s facing direction, the head direction, or something else?
Tony Gialdani, here at Epic shows a bit about his workflow in a livestream here, kind of:
https://youtu.be/3RlnclPo-3U?t=2348, but I’ll sum up a few things you’ll want to keep in mind.
- Pelvis or chest is more likely dependent on the max speed of your character. For locomotion in GASP we tend to follow the chest.
- Smoothed out directional facing on the root bone is really important for your trajectory data since we generate it off of the root motion. Have it follow your motion model trajectories and then only break the facing of the root bone to get smoother movement during things like planted turns. M_Neutral_Run_Turn_L_135_Rfoot is an example.
- We authored our animations to be both root motion-driven and capsule driven. But we heavily smoothed out the root motion, this was a gameplay choice.
Is it better to gather all Control Rig logic into one Control Rig, or can we split it and use a composition of Control Rigs?
The answer to this is “it depends”; you sometimes want to have small adjustments for IK mid-graph, or maybe it’s done as a separate pass. But for performance, combining as many of the adjustment-based control rigs is better. Things like arm twist and look at being in the same graph post simple IK adjustments might be better for example.
What’s the best practice to configure Pose Search Schema weights - manually, or is there a way to automate finding them?
We don’t currently have any automation tools for this; it has to be configured manually. We do use choosers and compartmentalized pose-search databases to make the process easier overall by providing better organization.
Are there any predictions for when the steering and slope warping plugin will be released?
The animation warping plugin is fully released and out of beta, and has been for a few releases.
Hope this helps,
Dustin
[Attachment Removed]
