ChaosMover's CrouchTransition does not update the capsule's component shape data on the GameThread

I’ve been trying to familiarize myself with mover, specifically the chaos mover part, so do let me know if I have just not completed any important and obvious step, but from what I can tell, crouching with the physics mover has a couple of `visual` and state sync issues.

I’ve managed to get the actual crouch to work on chaos mover, by following the source code, since crouch for the physics pawn isn’t in the mover examples. At first I thought this wasn’t working at all because the anim bp I used wasn’t setup for crouching, and I was relying on seeing the capsule shrink, whether via making it visible or with `Show Collision`.

But then as I dug around the code and realized that everything was firing and executing correctly on the physics thread, I realized that I can actually go under low collision, higher than the half height *2 + ground clearance. And after that, I confirmed with ChaosVisualDebugger that everything is indeed working as intended.

It was just that the capsule component on the game thread, recieves no updates to its radius/height or world location when the crouch stance modifier gets enabled. But the physics particle is correct.

I double checked if the game thread actually receives the data chaos mover sends by writing a little helper:

And this confirmed my suspicion, which was that the game thread does receive the updated particle, because I also tried tracing on the game thread against the play, to see if the trace results change between crouch and standing, and they do.

So I believe that a sync point which modifies the actual UCapsuleComponent and its member data to match the new capsule shape is missing.

However, I suspect fixing this only on the game thread side is impossible, as that would perhaps lead to desyncs.

Contrary to how crouch works in the CMC or the regular mover, this physics pawn crouch, re-pivots the capsule as a physics shape, without touching the owner’s location, meaning the capsule is no longer pivoted at the center, at least in the physics world. The getter code snipped can also show that. And here is basically where I stopped trying to figure out how to fix this myself and thought I’d open this ticket. Because the game thread cant support this concept, since the capsule is the root component, so a non central pivot isn’t supported.

And so I am curious how this will be addressed, since the actual implementation of crouch here is very nice, not changing the base location, and shifting the capsule down is a very clean way to resolve the traditional CMC crouch issues, where you effectively crouch mid air, begin falling and rely on the snap to ground to roughly make it a smooth transition, where as here, everything is very stable, and its up to the pawn to tackle the visual re-presentation. The caveat here is that this representation is impossible for the game thread.

For now, the code snippet provides enough info for a draw debug capsule to replace the visualization during development.

void UMyProjectFunctionLibrary::GetCapsuleFromPhysicsThread(UCapsuleComponent* CapsuleComponent, float& CapsuleRadius,
    float& CapsuleHalfHeight, FVector& CapsuleCenter)
{
    FVector CapsuleExtents = FVector::ZeroVector;
    CapsuleComponent->BodyInstance.GetBodyBoundsLocal().GetCenterAndExtents(CapsuleCenter, CapsuleExtents);
    CapsuleCenter = CapsuleComponent->GetComponentLocation() + CapsuleCenter;
    CapsuleHalfHeight = CapsuleExtents.Z;
    CapsuleRadius = CapsuleExtents.X;
}

[Attachment Removed]

Steps to Reproduce

  1. Follow the Mover Examples documentation: https://dev.epicgames.com/documentation/en\-us/unreal\-engine/mover\-examples\-in\-unreal\-engine
  2. Duplicate the ChaosMannyPawn, found in MoverExamplesContent/Pawns to your project file so we don’t modify engine content.
  3. Under the walking mode of the mover comp of that new pawn, add a `chaos character crouch check` transition, add stance settings under shared classes, and set up some capsule half height and radius settings and some ground clearance (setting it the to be : target height - standing capsule half height, will keep it the same as in standing walking)
  4. Set the max speed for the crouch transition to a lower speed than the default max for the pawn, as this way its easy to know when crouch is active
  5. In the event graph, just put a regular input key event, like the key `C` and plug Crouch(chaos mover as target) and UnCrouch(chaos mover as target) in pressed and released
  6. Click on the capsule of the pawn, and set visible=true

Observe that crouching does change the speed, however it doesn’t affect the capsule’s bounds or the actor’s location

[Attachment Removed]

I will try to reproduce using these steps, but here’s how it should work:

  • In FChaosStanceModifier::UpdateStance we log a simulation event and record the time on the physics thread
  • On the game thread when the time hits the physics thread time we fire the event. This is done in UMoverComponent::DispatchSimulationEvent - we call OnEventProcessed on the event. This calls the callback that we defined in FChaosStanceModifier::UpdateStance which calls Chaos::FPBDRigidParticle::SetGeometry with the new capsule

Do you see this event getting fired on the game thread?

Also, are you running standalone or client/server?

[Attachment Removed]

Ah, sorry, I re-read your question and it seems that the issue is not that the geometry is not getting updated but the capsule component data no longer matches. Is this causing you problems? I guess we could change the crouching code to keep the capsule centered, but it causes other complications

[Attachment Removed]

I’ll try to break where you suggested but I am guessing it will fire correctly.

But yeah, as you said, fixing the capsule component data update leads to complications (my suspicion is with pivots)

As to, is it causing problems or not, now that I know about this, I can work around this and with the function I provided, get the real data, however, as this isn’t an expected pattern of behavior for unreal’s shape components to not match their physics bounds, I think this will be an area where people get confused and might spend a long time not even realizing that they are building off of the wrong state.

An example I can think of is trying to do some gameplay logic with tracing or cameras. If I was trying to do a capsule trace, for whatever reason, I’d grab the component and use the height and radius from the component to match the trace call. And with the camera example, lets say someone wants to maintain eye height, relative to the capsule half height, so that crouch doesn’t have a different eye height, it maintains the same relative to the base of the capsule, that would fail on the account of half height not changing at all. Or another example is where in first person, you divide camera pitch by 90 to normalize it, clamp it and then multiply it by a factor capsule radius use that as the X component of the camera’s relative location to simulate a `neck` when looking down, the if crouch now has a different radius, that wouldn’t work either

[Attachment Removed]

Yeah, this is a good point. I think it would be good for the capsule data to match. I’ll look into it. In the meantime, I guess we could change the capsule data and have the offset be incorrect. Maybe that would be better

[Attachment Removed]

Yeah, the capsule having the correct params but hovering is probably better. Locally, I’ve got a debug draw capsule using the body instance extents and world location, hooked to p.Chaos.DebugDraw.Enabled 1.

If you are thinking of this partial fix going to one of the engine hotfix versions, perhaps just having a tooltip on the crouch transition, saying that there will be an offset, and that something like p.Chaos.Solver.DebugDrawShapes 1 can be used to at least see the real shape.

Also, I am hitting the Chaos::FPBDRigidParticle::SetGeometry, from the stance GT update.

I look forward to seeing how this is solved in future updates, I am early in my ChaosMover explorations, but I’ve already found other quirks, when I get something substantial I’ll start a new thread and hopefully it helps iron out some kinks. So far there are lots of very positive things though! Thank you

[Attachment Removed]

Sounds good. Thanks for the input. Please do let us know if you find other things that need improving

[Attachment Removed]