I’m experimenting with cesium right now and I’ve run into a problem.
I imported a 3rdPersonCharacter from the 3rd person template provided by Unreal, attached the CesiumOriginShift and CeisumGlobeAnchor, and tried to explore the world of Cesium.
However, when using the Change Cesium Georeference mode of CesiumOriginShift to rebase the character to the origin, I discovered that the character was jumping back and forth between two points. After looking a little more closely, I realized that the character should be at (0, 0, 0) after the rebase, but he was teleported to a completely different location.
So I tried to look into the code of the part that teleports the character after the rebase, but it was not easy for me.
I also found a thread with a similar problem to this one, but it was not solved.
complete the quick start and add datasets from getting start in Cesium for unreal.
import the 3rd person template from Unreal and attach the CesiumOriginShift and CesiumGlobeAnchor components to the 3rd person character. Set the Mode of the CesiumOriginShift to Change Cesium Georeference and the Distance to a reasonable amount (100?).
use 3rd person game mode instead of cesium’s dynamic pawn to explore the world as a 3rd person character.
This is an additional question.
It may not be an issue with Cesium.
In the above reproduction, select the mode of CesiumOriginShift to disable and set the maximum speed of the character (which can be set in the character movement component) to 10000.
You will see a jitter that feels different from the jitter in the rebase.
I suspect that whatever character/pawn your using is trying to move in Unreal’s coordinate system, rather than Cesium’s world coordinate system. As far as I’m aware Cesium’s dynamic pawn moves by manipulating the CesiumGlobeAnchor component itself, whereas the character/pawn you’re using is trying to change it’s xyz values - I think. To check:
Play the game, click Shift+F1 (to release the mouse if it isn’t already)
Select your character/pawn in the outliner on the right
Select the CesiumGlobeAnchor component and make sure you can see the location values e.g. latitude longitude
Click back in the game window and move around
The location values of the globe anchor should change as you move, if they don’t then I would suggest trying to modify the dynamic pawn to fit your needs as this has movement already set up correctly.
I suspect your last issue is related to
And my issue that you already linked. This jitter can be resolved by using the origin shift, however, the bug is apparently fixed in 5.4 according to
I’m currently in the process of downloading 5.4 and compiling Cesium to be used with 5.4 so we will see if they have indeed fixed it.
Seems like the same issue in the second post you linked:
I’m not sure if the third person character uses the spring arm component though? Have you tried the solution there (a modified version of the spring arm I believe.
I thought it was similar to the phenomenon in the article.
And I don’t use spring arm’s camera lag feature, but I am using spring arm, so I tried janine’s solution(CesiumOriginShift error - #16 by janine).
But it didn’t work for me and the same phenomenon was repeated.
There seems to be a conflict between UE’s physics engine and Origin shift, but it’s hard to find the cause.
I’m looking to reproduce this error, but just want to confirm some details.
Are you using Cesium World Terrain, or a different dataset?
What is the longitude / latitude where you’re seeing this problem?
For the 3rd person character, is this the same asset as the one included in Cesium for Unreal Samples? (In the third sample level, 03_CesiumDenver)
It would also help to know if you were able to reproduce this in the Cesium for Unreal Samples directly, so that we can have some common ground to troubleshoot from. Thank you!
I appreciate your response and will let you know the details.
Are you using Cesium World Terrain, or a different dataset?
I am using Cesium World Terrain.
What is the longitude / latitude where you’re seeing this problem?
It happened everywhere outside of sublevels, but the latitude/longitude I tested is (39.742999,-116.990742).
For the 3rd person character, is this the same asset as the one included in Cesium for Unreal Samples? (In the third sample level, 03_CesiumDenver)
The 3rd person character I used was from the Unreal 5.3 Starter Template example, but I tested by importing the character from Cesium for Unreal Samples and adding a Globe anchor and Origin shift, and the same issue occurred.
However, I tried to reproduce it by adding a Globe anchor and Origin shift to the character in Cesium for Unreal Samples and it worked.
I don’t know if this is enough, but please let me know if I missed something.
Thank you for the detailed information! We’ve seen similar behavior in the past; the “rebounding” usually happens when Enable World Bound Checks is true. Could you make sure that setting is disabled for your own project? You can find it in the World Settings panel.
Hi, @janine
The world’s “Enable World Bounds Checks” is disabled and the character is still rebounding.
I’ll look into it further to see what the issue is. Thanks!
We experienced that rebounding with flight, but never just normal walking
Janines Solution of the updated springarm solved the flight issue for us and we didn’t face any more issues with it from there.
We’ll be back working on the project in a week or two, Ill ask my team mate who is the more experienced coder of the two of us, if we find anything that can shed light on it, ill be sure to post screenshots here
Hi, @MQS
Congratulations on the completion of your demo.
The thread(CesiumOriginShift error - #20 by MQS) and solution was interesting.
It helped me to understand OriginShift better.
Please let me know if there is anything new, or if I missed something. Thanks!
Thanks Kim!
Im glad you could learn from our questions, we had to get our mind around it too. But Janine was great in helping us get there and providing some code!
And yes I will keep you in the loop if anything arises
The component and function that are currently causing the problem match, and the answers to avoid the problem also seem to match (the forum avoids it by negating collisions, I avoid it with flight mode).
It seems to be UE causing it, but it doesn’t happen in the cesium sample, so there must be something I’m missing.
That’s all for now.
