Hi, I am troubleshooting some strange behavior. Videos will explain a lot faster than words in this case:
Normal behavior in a small map:
Jittery behavior in 4kmx4km world when about 2km from the origin:
In the “large world”, which is a 4x4km terrain, when I get about 1.5km or more from the origin, the tools which can be moved via mouse start to jitter heavily. I thought I was well within the bounds to not have floating point errors, but perhaps because these actors are so small the issue is pronounced? For reference, the compass is about 12cm’s long.
I am exploring the world composition ability to shift the origin, but this is extremely complicated - if anybody can say that this might be some other issue I’d be happy to explore that before spending days trying to figure out world comp.
I’m in 4.26 by the way. I appreciate any help, thanks.
And additional question, if this is a problem for origin shifting to fix, how can i reduce the max world size which the world comp origin shift feature looks too? It is many times larger than my level, so I would need to reduce it in order to make the origin shifting happen sooner.
(i’m not a programmer, I am doing everything with blueprints.)
Pretty sure you’re right about the precision error and there’s a way to rebase the world but I’m not sure of the details. You should be able to find out how with some googling
I am working on that now.
Implementing the origin shift is possible somewhat easily with world comp, however it seems to have a hardcoded number at which it shifts at. I need to do it much sooner I think. So I am trying to discover how I can change that number.
Don’t have time to look at the videos, but if it is FP jitter that’s seems a very small distance from the origin. Not sure what your flexibility is. But I’d wait for UE5 doubles and see if that helps. If not then redesign the compass to be larger and then shrink it into a smaller widget later on. As moving the whole world seems drastic, as its not a trivial op - its expensive. 
What do you mean shrink the compass into a widget?
There is no widget involved here, it’s a 3d model.
There is other problems too. It’s necessary to make precise marks on the map, and with the errors the marks dont hit at the point of click.
Also note, the videos are less than 20 seconds long.
Looks like in-world widget. Anyway took a look and quick gut reaction, re-resize the mesh and texture so its much larger in world, and then not zoom in as far (or tweak FOV on the camera). Generally if you make things larger jitter tends to vanish. I’ve gone out to +2000Km in single-player. Making things larger or using 3D in-world widgets that you can size larger and move away from the camera helps hide the problem imo. Hope that helps…
unfortunately scaling them up isn’t making enough of a difference. if it was purely cosmetic i could live with it but this does effect ability to perform important gameplay task.
i am searching the api but I can’t find where to access this “MAX_WORLD” value. I think that if I can just make that number smaller, world comp will make origin shift happen sooner, which would solve the problem.
This may be it here:
Will report if it works. Hopefully I don’t break anything, i’m not a programmer 
You really shouldn’t need to worry about jitter at 16km2 or even 20-25km2. Is there something in the ops or how this is attached that’s causing this maybe? If its something in the calcs, maybe you can store intermediate ops as strings.
I have been doing blueprints for about three weeks now, with no prior coding experience. I can share the blueprints of how these are working, but I have no idea what you are asking
Here is the code for dragging actors with the mouse, this lives with the player character:
The actors (map, compass, etc) are separate blueprints that get attached to scene components on the character at begin play, here:
Here is how they are attached:
Note that these actors aren’t using any sort of physics or animations. They are only static meshes.
And just to reiterate, this problem only happens when I move about 1-2km away from origin. If I am closer, the movement is smooth.
This is floating point error, ue5 largely fixes this though
Nothing jumps out at me. Where’s the code for moving the compass like in the clips? Wait for UE5 or cheat for now. Suggestion: Keep everything that’s jittering at [0,0,0] in the world (hidden inside a mesh / beneath a landscape), and just cut to it using another separate camera, instead of attaching / zooming. EDIT: Is using a Spring-arm a factor in the jitter?
That is the that longer bit of code in the first screenshot. It’s just a mouse trace, looks for a custom trace channel, also has an offset so that center of the mesh doesn’t jump to point of hit. Then it sets actor location to mouse position. It’s the same for all tools, this code is run from the character.
Just a report about changing the MAX WORLD SIZE in the EngineDefines.h file: Didn’t seem to change anything… however I am not really sure what I am doing with world comp.
The size of the yellow extent did not seem to get any smaller. I think I’d need to get a programmers help though to really know.
It may be simpler to roll a custom world origin shift, rather than use the world composition tools, but there again I got to get programmer help.
I am not sure moving to a beta engine version is advisable. I can probably finish this project before it’s out of a beta.
I am not sure it’s wise to move to a beta version, especially since I will be ready to publish this game in several months…
I will take a day to move the project to UE5 though just to test. I guess if I can successfully build it should be okay? I kind of don’t want to open that can of worms though.
Better to check that first, as it could be a complete waste. Doubles are coming to UE5, but they’re not fully implemented yet… Everyone agrees this is jitter. But 1.5k from Origin is early. So gotta ask, is attachment to a spring arm a factor in why the jitter is more severe than expected? If I was solving this I’d probably leave what you have and cut away to another camera at [0,0,0] after the zoom. So fake it for now, with an identical but larger ‘giant’ second compass setup. After all the compass takes up the whole screen anyway. You could also try render-texture to scene-capture compass @ [0,0,0]. Gotta go, good luck!
I’ll try without the spring arms.
Rendering from a different camera is an option I would choose second to just living with some jitter at the edge of the maps. For multiple reasons it just isn’t going to be a good fit with the game design.
Thanks for the help!
Hey guys, this seems to work:
It seems too simple almost, but it’s working. I don’t see any problems, everything is staying in place like it should be… obviously i replace the key press with like a trigger sending an event later, but this basically seems to jsut work.
1 Like
