-
Notifications
You must be signed in to change notification settings - Fork 297
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add CesiumGeoreferencingInterop blueprint class. #1223
base: main
Are you sure you want to change the base?
Conversation
Thanks for the pull request @kring!
Reviewers, don't forget to make sure that:
|
When packaging a game that doesn't use the new CesiumGeoreferencingInterop Blueprint and also doesn't have the GeoReferencing plugin enabled, we get a bunch of scary messages in the log:
However, it still packages and runs successfully. |
I wanted to try a thing or two to avoid those errors, but I can't seem to get them to happen again, no matter what I do. I reset the project to a clean checkout from the Samples repo. I deleted my DerivedDataCache. I deleted the plugin and re-extracted it from the ZIP. Still those errors won't come back. Very strange. |
The NewName must actually exist. Not be a name that will be further renamed later.
I think possibly the reason I was seeing packaging errors initially is because I had an object in the project that referenced the CesiumGeoreferencingInterop class. It seems that engine plugin assets that are not referenced by the project at all are not included in the packaged game, which is great. However, when the plugin exists in the project's Plugins directory (rather than in Engine/Plugins/Marketplace), then the asset does get compiled and included, even if nothing else in the project uses it. And if the GeoReferencing plugin isn't active, then the resulting compilation failure will stop the packaging from completing. It seems to be actually pretty common for people to put our plugin in their project directly, so it's really unfortunate that including this extra interop blueprint will break their projects. I can't really see a solution to this, so our options are:
I'm currently thinking that (4) is the best solution. In which case this doesn't need to be part of v2.0 because it won't require any changes to Cesium for Unreal at all. |
I like the idea of 2), maybe also 3), just from an aspect of effort. The few users who need this can try it out, assuming they don't already have some mechanism to solve this. For us, it doesn't bog down our development efforts in a significant way. It's almost an implied nudge to use one or the other completely. |
Thanks again for your contribution @kring! No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy? I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with |
Hi there, I just wanted to check if there are any updates on this. We are doing quite a bit of work trying to implement means to sync UE Georeferencing, Cesium and ArcGIS plugin, and knowing whether this is going to be implemented or not might affect how we go about things. |
No, we're unlikely to merge this, because it requires dependencies that we don't want to take. My attempted workaround of that problem didn't actually work. However, you can feel free to use the code in this PR in your own project if it helps you. |
This is a PR into #1217 so merge that first.
Fixes #1169
Unreal Engine has its own GeoreferencingSystem, described here:
https://docs.unrealengine.com/5.1/en-US/georeferencing-a-level-in-unreal-engine/
It won't really work as a replacement for the CesiumGeoreference, but it still has two useful purposes in a Cesium app:
So, using both the CesiumGeoreference and GeoreferencingSystem in a single level is sometimes necessary or useful. And that leads to the awkward situation where both need to be kept in sync. For example, see this part of the Using Web APIs like Google Maps API from Unreal Engine (BP Only) tutorial:
We could solve this by teaching the CesiumGeoreference how to automatically synchronize with the GeoreferencingSystem. The problem with this is that it would require that the Cesium for Unreal plugin depend on the GeoReferencing plugin. In order to avoid that, I've taken an alternate approach in this PR. I've added a Blueprint class derived from CesiumGeoreference called
CesiumGeoreferencingInterop
. This acts just like a normal CesiumGeoreference, except it has some extra functionality:Two Blueprint- and Editor-callable functions allow bidirectional syncing between this CesiumGeoreference instance and a selected GeoreferencingSystem. And there's also an option to automatically copy any CesiumGeoreference changes to the GeoreferencingSystem.
Adding an instance of this Blueprint class to your level with still require you to activate the GeoReferencing plugin. But Blueprint's late binding (compared to C++) allows us to ship this class with our plugin without taking a hard dependency on the other plugin.
I'm opening this as draft because I need to do some more cleanup and testing.