if you actually try what you’re describing, you’ll see that it doesn’t work like you think it does. World-space IK effector positions are fine when you are solving to an object in the world, because its position exists independently of the pose of the solver. It doesn’t work for solving to an effector which is itself driven by the pose of the skeleton you’re running the IK on, because poses are resolved in a single pass.
Say you want to use IK to keep a skeleton’s left hand touching a weapon mesh which is attached to a socket on its right hand. With the naive world-space approach, you sample the position of a socket on the weapon mesh, feed it to the AnimBP, and when the AnimBP calculates the pose that frame, it updates the position of the left hand to reach this target position… and then updates the position of the right hand, moving the mesh and the target socket. Now, next frame, it samples this new position for the socket, feeds it back in, and the left hand resolves to it again, at the same time as the right hand’s position once again updates.
You can see the issue here: when you sample a socket in world space you are always going to see that socket’s position last frame, not in the current frame. This creates a one-frame lag where the left hand “chases” the right hand through any animation data, because the left hand and right hand are resolved at the same time. If you instead use component space, you avoid some of the chasing (since you are sidestepping any world-space changes to the actor as it moves) but animated motion still produces problems.
The way to resolve this is to set your IK effector target up in the bone space, of the bone that ultimately drives the socket your effector is targeting. This forces the AnimBP to first resolve this bone’s position (to calculate its coordinate space) and THEN apply the IK solver to this updated position. This produces rock-solid, lock-step IK when using one bone to target another bone on the same skeleton.
This brings me back to my original issue, which is that in order to do this, you have to know the bone space you are targeting in advance. It’s fine as long as your left hand’s IK solver is always targeting a location which is relative to the right hand (you can change the position it targets, as long as it exists in that space) but it will only produce stable results IF the right hand is what moves it. So, say, you need the left hand to target a position relative to the right hand to hold a weapon, but then for a reload animation, you instead need the left hand to target a hip bone, to reach for a magazine. There’s no way, at least that I’ve found, to supply a bone name as a pin to change the space… so you need two IK solvers. One which takes in a right-hand-space location, and one which takes in a hip-space location, and then you adjust their weights. Otherwise, one of these will produce frame lag because there’s no guarantee the bone driving the target position will be resolved before the IK pose is resolved in the AnimBP’s pose update pass. But when you have a lot of potential IK interactions (left hand depends on right hand, left hand depends on hips, left hand depends on chest, right hand depends on left hand, right hand depends on upper back, right hand depends on hips, etc) that creates a huge mess of sequential IK solvers which are all at 0 blend weight except the relevant one.
I’m looking for a way to avoid this, specifically that doesn’t involve using naive world-space or component-space calculations which, as I explained above, produce frame lag when the solver’s position is updated after the animation.
EDIT: and before someone chimes in with it, no, changing tick groups for the mesh will not resolve this issue. If you consider it for a second you’ll see why; if you sample the position of the right hand after updating the pose, the pose won’t see the new sampled position until the next frame, but if you sample the position of the right hand before updating the pose, you’ll be updating the pose with a position sampled based on last frame’s data. The only way to produce stable results is to sample the position after resolving the pose of the driving bone but *before *resolving the pose of the IK chain, and the only way to sample data mid-stream in the pose update like that is to use a bone space IK constraint.
