UE5.0.3 and UE5-Main (compiled from source) LWC (Large World Coordinates) do not work for First Person Shooters/ First Person Driving games. When player actor location is x=10km y=10km both static and skeletal meshes wobble/shake/jitter. This effect starts from 3km and and peaks at 10km further increasing distance does not increase wobble noticeably. At 10 000 000km wobble looks almost same as 10km from world origin. I’ve tested UE4.26 and wobble is not as bad as UE5. I’ve noticed that if I increase player actor scale to 10 the wobble is not noticeable anymore… even at 10 000 000km from world origin. No, I’m not going to scale whole game by 10.
I’ve searched info for this issue and all I could find is bug: UE-155378 https://issues.unrealengine.com/issue/UE-155378
This is most likely UE5 rendering issue as individual vertices seem to snap to random positions. While in UE4 whole mesh was shaking at 10km distance from origin.
Is there any chance this issue gets fixed for UE5? For third person games this wobble effect is barely noticeable. For First Person games LWC is useless as max map size is 8x8km(or even less) to avoid wobble.
The documentation seems to indicate that worlds larger than 21km should be possible (it mentions going up to 88 million km). It seems like in some part of your code it may still be using float instead of double versions of values which would cause the precision errors.
Maybe this LWC conversion guide will point you to some things to check for - Large World Coordinates Project Conversion Guidelines
@MostHost_LA We expect it to work due to introduction of LWC (Large World Coordinates).
@bjgil2 My project is not using any custom code. I’ve conducted tests with blank new UE5.0.3 project using blueprints only and double values.
Thanks for suggestions.
I just completed tests and comparison to UE4.26.2 – there is no wobbly rendering while UE5.0.3 is rendering vertices wobbly.
I’ve created new empty project both in UE4 and UE5. Created new empty level. Placed Sphere Actor (StaticMeshActor). Set coordinates to (X=1000000,Y=1000000,Z=0). Opened level blueprint and added on event tick: Add Actor World Rotation (Z=0,001) for sphere. Set viewport view to top and wireframe. Pressed F to center camera on sphere and zoomed in to max. Alt-S to start simulating project. UE5 vertices are individually snapping around. UE4 everything looks very smooth, no issues.
Here is video comparison:
Please lets keep it professional.
The issue I have is not occuring on UE4.26.2
Could you please elaborate why this issue occurs on UE5, but not on UE4? See my video where sphere is rotating. It shows UE5 and then UE4.
I haven’t tested large distances in UE4. Only up to 10km. Yes, meshes start to shake/jitter at great distances in UE4. It is due to floating point precision. However on UE5 not the meshes jitter, but individual vertices of those meshes thus it creates wobbly looks. What is more interesting that while (UE5) going further than 10km up to 1 000 000km and more doesn’t increase wobbliness intensity. It remains same.
Its a deforming mesh.
Floating point precision matters for individual vertex, when they are being displaced based on WPO. Since wpo is outside the floating point precision.
Normally, the animation is automatically localized (ei, the location is not important to the animation/skinning).
Ue5 being beta if even, and having unfinished issues with skinned mesh, probably doesn’t do it right yet.
Regardless, its a non issue.
Now one should expect things anything to work at 10km or even at 1km from origin.
If the spehere is not a skeletal mesh, then you probably have nanite on.
Nanite works by modyfing your object geometry, so that too not working is no wonder.
Basically anything at all that moves the vertex somehow will be prone to floating point precision errors, flickering, etc.
Worse cases are WPO materials.
Best case are perfect engine objects positioned with no decimal values.
But, get high enoough and the way the Float is stored will also cause issues.
Memory storage is done by converting to binary.
I wasn’t kidding when I told you to look up what 32bit vs 64bit means to learn why what you are asking is mathematically impossible.
The issue exactly same with both static mesh and skeletal mesh. It is not problem for third person games, but it is great problem for first person games.
World Rebase has lots of problems in UE5. Just tested - seems not to work properly with world partition system. But I’m sure there are ugly ductape solutions for those problems.
UE-155378 has been solved - however my issue of wobbly rendering remains both with static meshes and skeletal meshes. I’ve tested with latest source version from Github.
@Elitic I guess I have the same exact problem, and there’s no real reason for that if internally 64bit are used for actor placement. Have a look at my post at the CESIUM forum, because I thought that maybe it was caused by the CESIUM plugin (it isn’t):
I really kills the UE5 implementation, and rebasing is not an option.
Yes, I’ve reported issue to Epic.
Yes, sphere example is most basic and very easily achieved. I’ve sent them video.
I’ve just I’ve tried to compile latest UE5-Main (5.2), but it failed to compile.
Then I’ve tried to compile 5.1 brach from github. It succeed, but issue remains unchanged.
Thanks to your link to your post on Cesium forum I started to dig into UE5 source code and found workaround/solution.
In Engine/Source/Runtime/Core/Private/Misc/LargeWorldRenderPosition.cpp
Just change: #define UE_LWC_RENDER_TILE_SIZE 2097152.0
into smaller value (I’ve changed into 8 times smaller) (Edit: 524288.0 works good too. 1048576.0 yields no improvement) #define UE_LWC_RENDER_TILE_SIZE 262144.0
I do not know what will be side-effects because of this change, but it seems to solve the issue.
Edit: Wobblyness is fixed in UE5.1. Jittering is still not fixed in 5.1 and "UE_LWC_RENDER_TILE_SIZE " needs to be lowered to fix it. Marking as solution…
About rebasing: For rebasing you need to move all existing actors in the scene at once during one frame. I’ve got tons of actors, and I need to maintain a stable framerate of 90fps in a mixed reality setup using the Varjo XR-3 headsets that have four displays internally - so it’s almost impossible to do everything that’s needed in a flight simulation plus all the added work for rebasing every 3-4 km of flight distance inside of 11ms without getting one or more dropped frames. This is undesirable in a flight simulator used for doing handling qualities during aircraft development. So, as I said, for us rebasing is not an option. And it shouldn’t be needed at all, with doubles for locations. UE5 will handle this beautifully after the issue is fixed.
thanks for telling me about your workaround. I haven’t had to compile from source for the last two years, but I guess I will now start again.
I’m of course a bit afraid of potential side-effects, as you mentioned. And every time I start reading UE source code to get the answerer about an important question I’m reminded of how much I don’t know about the engine.
I will make a close contact I have at Epic Games aware of this problem (he’s taking care of companies like ours how are using UE for simulation). Maybe he can push this a bit, or re-open the issue as it is not fixed.
[EDIT: I forwarded the problem to the simulation team at Epic Games, I hope they will have a look at it soon.]
, but it seems to solve the issue.