Hello - I am using UE 5.3. I am using the Open World template with World Partition enabled.
I have a setup in my animation blueprint that applies a rotation to the characters hands as the player moves the mouse via a Transform (Modify) Bone node. This is to apply sway to the FPS weapon as the player looks around.
It takes the mouseX and mouseY input axis values to calculate a target angle to apply to the hands. This target value is run through an FInterp To node to smooth it out.
It works perfectly when close to the origin, but there it significant “jitter” in the animation when I am far from the origin (a few km).
I assume this is due to the Transform (Modify) Bone node using single precision? If anyone knows a workaround, or maybe I am just doing something wrong as I am new to Unreal Engine.
I’m newer to UE than you are, but have been doing graphics for a long time, so I might have some insight. My guess would be that the transform is being done incorrectly. For example, rather than transforming the hand as a rotation based on the position of the elbow, the hand is being transformed to the origin, rotated, then transformed back to the location of the player. If there is some limited precision (fixed point maybe?) math in the calculations, you might see problems like this as precision is lost in the transform calculations. Even with single precision 32 bit floats you get around 7 decimal digits of precision, so if the position calculations are done with millimeter precision, a “few km” could use up those digits. 1km = 1,000,000mm. With doubles you would get between 15-17 decimal digits of precision. If you travel in the X direction only, does the jitter only happen on the X axis?
As far as I can tell, you are definitely right on the single precision floats.
There have been others throughout the years that have this issue, UE4 having a different problem with a similar visual glitch- so ignore anything about UE4 fixes for this, the problem is different internally.
I will have to try the suggestion from the post you linked. It looks like it involves changing the source code and recompiling the engine. I will have to research that more, as I’ve never done that before.
The problem does seem to be exacerbated with the FInterp To node… I have a free-look system that rotates just the neck bone, also via a Transform (Modify) Bone node, and this has no noticeable issues… I’m not experienced enough with computer science or Unreal Engine to understand why this would be. My only guess is that my free-look system uses a Timeline to reset the view, resulting in a more stable return to zero - while the FInterp To node seems to smooth to zero very slowly at the end with lots of tiny decimal values.
Thanks for the reply!
Yes good suggestion, if I go 2km out in just the X, the issue is only in the X axis. I think the problem lies with Unreal Engine’s animation blueprint nodes using single precision for the rotation components, so I’m not sure how to get around this without origin rebasing, but maybe the suggestion from the post Mind-Brain linked will help.
It seems like origin rebasing may not play nicely with the World Partition system, so I have a lot of learning to do lol…
I was going to suggest origin rebasing! But I ended up not suggesting it due to that right there. “…may not play nicely with the World Partition system”.
In fact, it used to be doable with blueprint in the World Creation system from UE4, which had its own host of problems (for instance, single-float world coordinates). But now I can’t even find a way to do it with world partition without C++.
It DOES make me think more on how the games that are really big use largely static meshes. Space games don’t really have a lot of fine-tuned movement, it’s so big the jitter is not noticeable because you’re viewing from so far away, and the inside of a ship is usually treated as another level with its own origin.
