We’re not sure why, but the CesiumOriginShift component seems to be causing issues with the camera/player when they are moving at fast flight speeds. We have a CesiumOriginShift component on our flying player. When we move fast enough, thats when we begin to flash between 2 points and when using camera lag it breaks it, causing it to snap to the player. Disabling CesiumOriginShift fixes the issue, but now, if the player moves far enough away, ‘down’ is no longer towards Earth’s center.
Is there any way to fix this issue?
For some extra context, without camera lag ticked in spring arm the camera shadows the player closely and is directly behind at all times without the pullback or glitches. However without the camera lag chosen, the flight feels jagged and unpolished.
Although after playing around with it a bit, even if camera lag is ticked, if I go fast enough or collide with an object at a faster speed the camera then switches to the other mode as if the camera lag is unticked. Almost as if the camera lag has been broken in scene and it resorts to no camera lag.
Ive also pushed it to the point right underneath the threshold for the breakage and the camera loses track of the player, however if I move the player around just right it finds him again and starts tracking properly again. So it it’s all quite peculiar.
For some extra context, we’re flying in a similar vein to this but have the ability to accelerate the character at much faster speeds to cover more ground
I can make a few suggestions, though it would also help to have screenshots of your camera setup in case there’s something obvious amiss.
- You can set the
Distanceproperty onCesiumOriginShift. This ensures that it only rebases after you are a certain distance away from the origin. - If you attach a
CesiumGlobeAnchorcomponent to the camera, that may help resolve the “flashing” between two points.
While extending the distance does fix the problem, it means that if the player moves far enough from the origin, ‘down’ is no longer the center of the sphere, causing them to slide off the Earth. Unfortunately, attaching a CesiumGlobeAnchor did not fix the issue.
The CesiumGlobeAnchor component should automatically adjust the orientation of the pawn as you move around the Earth, such that your sense of “up” follows the curvature. I suspect that something in the plugin you’re using is conflicting with the logic in CesiumGlobeAnchor and/or CesiumOriginShift.
At this point, I can ask if you see the same issues with the Dynamic Camera included in the plugin. If not, then there’s probably an incompatibility with the plugin you’re using. What do you need the CesiumOriginShift for – can you get away with not using it?
We’re using this CesiumOriginShift attached to the player character to keep down always pointing to Earth.
But there’s an issue: when using it we get the previously described error. Without it there is no error.
After testing further we found with the originshift attached with camera lag left on, our character starts jumping between two points every time the origin shifts. However when it’s attached but the camera lag is turned off, the jumping doesnt happen.
We’ve tested it with both the SuperHero Flight Component and Dynamic Flight Component, and it’s the same issue. We’ve been trying to remedy this over the past 2 weeks to no avail.
We decided to create a fresh project with only cesium and dynamic flight installed (Dynamic Flight with Blueprints in Animations - UE Marketplace).
We found the same error when we attached the origin shift component. Particularly when increasing the flight speeds.
We contacted the developer and after he tested it on his computer with cesium he has confirmed there is nothing in his asset that would cause this.
Video: DynamicFlight_Cesium.mp4 - Google Drive
We then started a completely fresh project with a different flight asset called superhero flight (Superhero Flight Animations in Animations - UE Marketplace), and we had the exact same issue as can be seen here.
Video: SuperHeroFlightComponent_Cesium.mp4 - Google Drive
As described in the earlier post, when the ‘enable camera lag’ is unchecked the bug doesn’t happen. However that setting needs to be able to be enabled otherwise the camera sits too close to the player and feels rigid.
Neither of those flight assets have camera blueprints that would conflict, so we’ve been able to confirm that this is an issue with the cesium origin shift.
Is there a way to remedy this issue? It seems like flight with cesium is a relatively common use case from how I have seen other users utilise it.
Otherwise can this be remedied in an update, that would be great
Thanks
Any ideas on how to fix this?
We’ve kept testing since the message 6 days ago including since my prompt yesterday to no avail unfortunately. It’s been a couple months since we initially noticed it happening.
It occurs at relatively normal speeds with flight controllers, however when accelerating to higher speeds which are suitable to exploration of the terrain, the stutter and flickering of the player from the origin shift is very noticeable and in some circumstances has broken the camera.
As I mentioned, without origin shift this issue doesn’t occur.
So it would be great if someone on the team could help.
Im happy to zip up a demo project and send it through it that helps 
Hi @MQS,
It’s difficult to closely debug this because we don’t have access to those select assets – they’re not free on the Marketplace. It is also not possible to test a project between two environments if one of them doesn’t have the required plugins.
I’ve attempted to reproduce the bug by attaching CesiumOriginShift to the DynamicPawn that comes with the plugin, and setting the mode to “Change CesiumGeoreference”. I have to set my Cesium3DTilesets to “Movable”, otherwise I see a camera warping effect. Maybe that’s the step that’s missing? Beyond that, I can’t see this camera lag that you’re referring to.
Otherwise I can only speculate that there are key differences between the controller movement that we’re unaware of. How do the controllers compare to the setup of DynamicPawn? Are there any notably different components?
Thanks Janine for attempting to reproduce the bug. Hopefully we are able to solve things and identify the root cause of the issue soon.
There are no key differences in the movement that we’re aware of, it’s just additional flight components on top of a default controller, overall it’s fairly standard.
Attached are some screenshots of the setup, however its based upon the base pawn so it doesnt make sense as to why both of these seperate flight systems are having issues.
Since our last message we’ve followed all the instructions numerous times and have scoured the forums still to no avail. The hammerhead studios flight dev has been kind enough to brainstorm with us but it really just seems to be a Cesium issue. His conclusion was that “it seems pretty clear that the issue is related to how Cesium and UE5’s stock camera lag feature interact, not anything related to either flight system. I have to imagine that, when camera lag is enabled, the issue would happen when running on the ground (or jumping) at the same high speeds.”
He has given us permission to send you the url to a version of the zipped project with solely cesium and dynamic flight connected for the purposes of debugging. It also works completely fine without any additional plugins, if you open the project it works immediately without the need for any particular additional installs or settings needing to be applied.
Ive sent it through to you in a private message.
My team mate who recently tested it has asked me to post these recent findings related to the attached project:
“What I’m aiming for is to make sure the Origin shifts, pointing ‘down’ towards the center of the Earth consistently. So, I attached a Cesium Origin Shift component to the player, which moves the origin whenever the player gets 40000 units away from it. But, here’s the issue: the player flashes when this happens. It seems to only occur when “Camera Lag” (Found on the CameraBoom) is on, but I want it on so that the camera backs away from the player as they pick up speed. “F” to enable flying “Shift” to enable fast flying You can change the speed on DynamicFlightComponent found on the player Blueprint.”
If you’re able to look at it for the sake of debugging and helping identify and rectify the issue, that would be very appreciated. We have genuinely tried everything we can think of and at this point don’t know where to go next, but this seems like the type of issue that could be fixed if can see the problem firsthand.
Thanks
Hi @MQS,
I hear your frustration and apologize for the inconveniences caused. Thank you for your patience as we find a solution.
I was able to take a look at the project you sent, and I think I finally understand the issue. When CesiumOriginShift rebases the origin, everything geo-located will move to some new Unreal coordinates. However, this shift won’t be perceivable if the pawn is geo-located (has a CesiumGlobeAnchor) because it will also be shifted, so it cancels out. Your pawn already has this, which is good.
The problem comes when origin shifting with anything that isn’t geolocated. Everything else is shifting around them, so it appears like the non-geolocated objects are teleporting as the origin moves. I suspect that this is affecting the Spring Arm Component, which manages camera lag based on the pawn’s previous location (not geo-located). Since the math interpolates based on Unreal coordinates, it gets disrupted whenever the Unreal origin shifts. That causes the pawn and camera to be de-synced when the origin shifts. The interpolated position will be drastically far away from its original trajectory, which is why there is a quick rebounding of the character.
Interestingly, this is something that can’t really be seen on the Camera component itself, because it’s transform never actually changes. I looked through the source code in SpringArmComponent and found this comment:
I need more time to understand the code here, but this comment could explain why it looks like the model is snapping off-screen then reappearing, as opposed to the camera snapping to the model.
Unfortunately, from Blueprints, there isn’t a way to reach into a Spring Arm Component and explicitly set its coordinates whenever the origin shifts. But in theory, you could implement a C++ class that inherits from SpringArmComponent. Every time the origin shifts, you can call a method on your new C++ class that updates for the new origin, and recompute the camera’s location from the CesiumGlobeAnchor attached to the pawn. By intercepting the code here, the interpolation can hopefully continue as if the origin shift didn’t actually happen. I advise keeping the origin shift Distance above 0, though; I don’t know how well this will respond to constant origin updates.
If this is an avenue you’re willing to pursue, let me know and I can try to help with the C++ code. In any case, I hope these insights have helped. Thank you again for your patience.
Thats excellent news, we’re grateful for you looking into solving this with us!
That cause for the de-sync and the rebounding makes a lot of sense. It’s impressive to see that you were able to make heads and tails of it so quickly! It was difficult to connect all of those dots from our end given our limited experience with cesiums mechanisms.
It is unfortunate that the spring arm component isn’t accessible in this way from blueprints. However your idea regarding implementing a C++ class inheriting from the SpringArmComponent sounds like a great solution!
These insights certainly have helped and given that you see this as best way to remedy the issue, we definitely are willing to pursue this course to solve this issue. Yes, it would be much appreciated if you could help us with this as it seems like you have a much clearer idea of where to start and how to implement than we do.
Are you able to perhaps write something up as a baseline for us to continue with? That would be fantastic!
Im happy to proceed with brainstorming here or over pm, whichever suits you best
Thanks
Hi @MQS,
Yes, I’m willing to write a baseline! And I’m happy to post here, unless there is something about your particular use case that you want to discuss privately.
I’ll need a few days to investigate, but I will get back to you as soon as I can. Aiming for the end of next week at the latest 
1 Like
Thanks Janine that would be excellent. We all really appreciate it and are looking forward to continuing to explore the possibilities with Cesium once we have this figured out!
And we should be ok continue posting here too. Thats a good point regarding privacy. If details come up that I can’t publicly discuss, I’ll pm you. I realised early in the thread I pasted some private info that I later edited out: but I don’t see it being an issue moving forward
Thanks!
Hey @MQS,
Thanks for your patience! I think I’ve got something working, but you can stress test it for me and let me know if something comes up 
Create a new C++ class & configure the project
- Go to Tools > C++ class.
- Under “All Classes”, search and select SpringArmComponent. Name your class; for this walkthrough I’ve named it CesiumSpringArmComponent.
- Add it as Public to your project. This should open the files in Visual Studio and generate a solution for your project.
- In your project’s
Sourcefolder, find the.Build.csfile that got generated for your project. Add this:
// Add Cesium for Unreal plugin dependency path
PrivateDependencyModuleNames.AddRange(new string[] { "CesiumRuntime" });
// Tell Unreal Engine to use C++17
CppStandard = CppStandardVersion.Cpp17;
- In your file explorer, right-click on the
.uprojectfile and run “Generate Visual Solution project files” to make sure the changes are applied.
Verify
You should have CesiumSpringArmComponent.h and CesiumSpringArmComponent.cpp created, with the class UCesiumSpringArmComponent inheriting from USpringArmComponent.
- Make sure you have this macro at the top of your class:
UCLASS(ClassGroup = "Cesium", Meta = (BlueprintSpawnableComponent)) - Close Unreal if you haven’t already, and press Play in Visual Studio. This should build the project and eventually re-launch the Unreal Editor.
- Go to your character Blueprint, and add a new component. Search for “spring”. If all goes well you should see your custom component appear in the dropdown.
- Add it to your Blueprint, and copy all of your custom values from the regular Spring Arm (e.g. transform and camera lag values). Then, drag the camera under your custom component, and delete the old one. So it’ll look something like this:
- Play the level. If all went well, you’ll see exactly the same behavior as the old spring arm component. You’ll still see that teleporting glitch, which is okay, we’ll fix it.
Add Code
Here’s where I’m going to just share my Source folder with the files, so you don’t have to construct them piece by piece 
Source.zip (5.5 KB)
The gist of the changes is that we’re checking for a CesiumOriginShift component, and if so, adding one (though you can change this so it’s not a hard requirement). Then, we’re overriding the parent UpdateDesiredArmLocation with our new logic.
We copy paste the original body of the function, then make some changes to convert the previous globe-relative location of the camera arm, to the new Unreal position after origin shift.
It should be smooth flying from there (pun intended). The solution seems to work even when the origin shift’s Distance is set to zero, so don’t feel obligated to keep the number high. Let me know if any issues come up and I’ll try to help!
2 Likes
Thankyou Janine, this is fantastic!
We’ll be back collaborating again early next week so we’ll be sure to stress test it then, it looks very well strategised and implemented. It will be great to check it out!
Have a great weekend, we appreciate the energy you’ve put into this, chat to you soon
1 Like
We implemented your fix today and it works very well, we really appreciate it Janine!
It’s very impressive and is a lot of fun to use.
We’ll be sure to stress test more in the coming week or two and keep you in the loop with how it goes.
We think you’re awesome, thanks again
Glad to hear it @MQS ! 
Definitely let us know how it goes and if you have any followup questions, or encounter other issues.
1 Like
Hi Janine, just following up
After much after-hours tinkering and creating, we finally completed the demo!
We took a little break afterwards and are going to polish and build upon it more in the coming time.
We’re excited for what’s to come and in the future with it!
Your help here was a game changer, thank-you so much
1 Like