In code, skeletal mesh components are setup to tick in pre physics, with an end group of post physics, provided they aren’t simulating physics. The cloth tick is also set to tick in pre physics with and end of post physics. However, since the primary tick is a prereq of cloth, this forces the main skel mesh tick to start and finish in pre physics so cloth can prep for simulation in pre physics.
Many of our frames come with wasted space on the main thread in the during physics tick group. We wanted to see about offloading our non cloth skeletal meshes to tick in that tick group, but we don’t know what configurations/data to change to make that happen. Do you know how we could force those types of skeletal meshes to postpone until a later tick group that is still in their tick span? We cannot set the tick group at the BP level since we might use the same BP but change the skeletal mesh asset dynamically (i.e. mutable), and that could be one with cloth or not.
The default skeletal mesh tick settings are set up to tick as early as possible to avoid issues with dependencies, but as you noticed that isn’t always the best performance. There are a few CVars in SkeletalMeshComponent that affect the generic rules, notably tick.HiPriSkinnedMeshes (which forces all skeletal meshes to tick at the very start of their tick group) and tick.AnimationDelaysEndGroup (which delays the EndTickGroup for every skel mesh component so it won’t stall the end of the PrePhysics tick group to wait for them). They don’t address your issue but you might need to disable those as they try to automatically fix things you don’t want changed.
If you can’t set tick settings at the BP level because of your content setup (which is common for anything like an RPG) you’ll have to do it in game-specific native code. You could do this in the “NPC builder” code that spawns the characters in the first place, or in the BeginPlay of the game-specific native base class of your characters. There isn’t really anything built in to the engine to help with this. We’ve discussed trying to add something to make it easier to construct and set up characters but this logic is generally VERY game-specific.
All of the tick function setup for the recent UnrealFest demo was done in game-specific native code. I recommend watching some of the detailed presentations on the full schedule as several talk about skeletal mesh/character setup.
So yeah the basic answer is “write some custom code to do what you want”. If you have any followup questions about that you can ask them here.
So I tried turning off tick.HiPriSkinnedMeshes as well as TaskGraph.TaskPriorities.ParallelAnimCompletionTaskHighPriority to see how that would work (tick.AnimationDelaysEndGroup is on by default and it looks like that’s what we want to span). While it probably now allows mesh ticks to span better, in our case everything still ends up starting and completing in pre physics.
To your knowledge, would their be any inherent repercussions in the engine if we were to, say, move the skel mesh primary tick (and by extension cloth tick) to begin during physics? I’m guessing that collision resolution on skinned physics bodies would always be a frame behind, but with the spanning that was always a possibility anyway.
The engine should be fine with any tick group changes, but you might need to subclass SkeletalMeshComponent to do what you want. I’m not very experienced with the cloth tick setup, I know chaos cloth works differently than the older style but the animation team are the specialists there. With the current tick system you just kind of need to try changing things and see what happens. I did fix a few bugs in 5.6 where it could deadlock if you set up bad circular dependencies, but that won’t matter if you set up dependencies and tick groups to be exactly what you want.
I’m working on writing better documentation to explain this, but the best way to investigate tick dependencies is using the task tracing features built into Unreal Insights. If you do a task capture and click around you can see exactly why certain tasks are executing when they are, which should help you debug issues.
We’re about to go on our summer break at Epic and I’ll be OOO after that, so if you don’t have any follow up questions today/tomorrow I’ll close this question out for now.
It would be great to get someone from the animation team to weigh in just for a sanity check. If that doesn’t happen until you guys are back from break that’s fine.
You can run the skel mesh primary tick whenever you like but you’ll have to live with the potential side effects of moving it. As you mention, if you allow the tick to complete after PrePhysics finishes (to allow DuringPhysics to kick in potentially before you run), then you might run concurrently with physics and the order of execution isn’t guaranteed. This means that on some frames you might run before and have no latency (same as finishing in PrePhysics) while other frames you might run after physics and introduce a frame of delay. This could change frame to frame with the potential to do bad things as the change in momentum might become erratic on the rigid bodies impacted by your skel mesh. If you want determinism, you’ll want to make sure you complete before physics kicks off or you have to run after physics is done, consistently.
That being said, this lack of determinism with respect to the physics simulation might not matter in your case, at least for Chaos cloth. If you drive rigid bodies that can impact the main physics scene (e.g. you can push ragdolls or env things) then the lack of determinism is potentially problematic. However, Chaos cloth uses a local simulation by default (I think) as it doesn’t collide with the environment (and other things in the main physics scene). I believe it only self-collides by default and as such you only need cloth to run after the skeletal mesh and either of these could happen at any time in the frame. You can think of Chaos cloth as running its own physics scene where you have to specify what to include explicitly for each instance.
>> As you mention, if you allow the tick to complete after PrePhysics finishes (to allow DuringPhysics to kick in potentially before you run), then you might run concurrently with physics and the order of execution isn’t guaranteed
This is how the engine is set up by default. It sets the tick group to pre phys and the end tick group to post phys. So if this was a concern why would the engine be set up this way?
The change I’m doing would be to not even start the tick until during physics. Under normal circumstances that means skinned physics would always be resolving a frame behind right? So that would make it deterministic but lag a frame.
If the mesh is simulating physics then I would let the normal engine tick ordering execute, which should force it all to finish in pre phys so bodies are up to date for physics sim. That should eliminate any potential issues with simulating bodies and the rest of physics, correct?
> This is how the engine is set up by default. It sets the tick group to pre phys and the end tick group to post phys. So if this was a concern why would the engine be set up this way?
There is nuance there. A skeletal mesh component has 3 tick functions (see skel mesh comp constructor):
A primary tick function (the one from ActorComponent) which runs and finishes in PrePhysics by default
An end physics tick function which runs and finishes in EndPhysics
A cloth tick function which starts after the primary tick within PrePhysics and must end in PostPhysics
The primary tick function will update animation and update the rigid bodies, hence why it must run before cloth/physics. If your rigid bodies don’t impact the global simulation (e.g. you can’t push env cloth or push ragdolls etc) then you don’t have to run before physics runs as determinism won’t matter in that case. Cloth needs to update after the primary tick though, since you need both the updated joint positions and the updated rigid bodies (for the local simulation).
You can delay the start of the cloth tick function to During/PostPhysics, that should be fine. The default setup allows cloth to kick off as early as possible because it can take some time to execute and finish but there is no mechanism to express that during PrePhysics, it should be lower priority than other PrePhysics work (and so it can end up competing for resources) while in later tick groups it should be higher priority as we need it to finish by PostPhysics. There’s no notion of dynamic priority as the frame progresses like this, only a static priority. As a result of this, it is sometimes necessary to tune kickoff of tick function per title (as you are experiencing). That’s something I have some hope of addressing in the future but not anytime soon unfortunately.
Right. The idea I had was moving both primary tick and cloth tick to during physics only if you are not running end physics (in which case I leave everything as is). Based on what you said I should be able to do this because I am not simulating a ragdoll and also because the cloth sim only does local collisions since it runs in its own solver independent of the global phys sim one.