Reducing my number of Bing Maps sessions with Cesium for Unreal

Cesium for Unreal
1

I’ve gotten an email along these lines the last two months:

image
image1185×556 46.4 KB

I have a few questions about this. I realize they’re probably oversimplified, so if anyone knows the details, that would be super helpful:

  1. Is it true that every time I open an Unreal project that has Cesium, does that use a bing maps session? (I think yes)
  2. Every time I press play, does it use a different bing maps session? (I think yes)
  3. After I’m done playing and go back to the editor, does that use yet another bing maps session? (I think no)
  4. If I do a build and I distribute it, is it true that each time the app is used, it uses a bing maps session that is linked to my account? (I think yes)

Are there any tips for reducing this in Unreal?

Thanks!

1 Like
2

Hi @nbaja,

Yes you are correct in your answer to all of your questions. CesiumJS differs in (2), and we should update Cesium for Unreal to match. I wrote an issue to cover this:

Kevin

1 Like
3

Thank you for the info and thanks for writing up that issue.

4

Kevin

I am happy to report my account has been restored after significantly exceeding my Bing sessions quota. My questions are:

  1. Does a rebuild of a UE project from an archive, including shader recompilation, require more than a one or two Bing Map session associated with opening the editor? My project has many UE Maps, each containing a Cesium terrain and buildings layers.
  2. If I use Cesium OSM buildings with a Bing imagery overlay, and a Cesium terrain with Bing image overlay in a map, does opening this level result in two Bing Map usage counts?
  3. If I delete (temporarily) the Bing imagery layers from the Cesium OSM buildings and Cesium World terrain in my level, but do not remove the Cesium Ion asset from the level completely, does reloading this still cause my Bing Map session to be incremented? When I add the “CesiumIonRasterOverlay” back, I don’t need to enter the access token, so I understood playing the level still results in a single count of token use, but I thought it wouldn’t count as a Bing Maps session, since Bing data was not being accessed….only the Cesium terrain.

My questions are in response to over 4000 Bing Maps sessions in a single day, which I cannot otherwise explain. I am trying to understand what triggers a Bing Map session count. My users and I would very much like to cache data to reduce server usage.

Thanks for any help you can provide….

Tom

5

Hi @Cloudhopper3,

I wasn’t sure of the answer to your questions, so I did some experiments. If you want to test any of this yourself, you can open up UnrealAssetAccessor.cpp in the plugin and add a line like this near the top of the get method:

SPDLOG_WARN("GET: {}", url);

And a line like this near the top of the request method:

SPDLOG_WARN("{}: {}", verb, url);

With this, every HTTP request will show up as a warning in the log. You’ll probably need to put the plugin in your project in order for Unreal Engine to recompile it with this change.

For the purposes of usage counting, the ones that matter are for a URL that looks like /assets/#/endpoint, where # is the asset ID.

The main thing I learned is that the caches work well when Bing imagery is requested throughout an application lifecycle. For example, when you enter or leave Play-in-Editor mode, this does not trigger a request to assets/2/endpoint, and so it doesn’t count as a new session.

However, when the same asset is used in multiple places (nearly) simultaneously, it doesn’t work as well. For example, in your example with Cesium World Terrain and Cesium OSM Buildings, and both of them have Bing imagery as a raster overlay, both tilesets will initiate a request for assets/2/endpoint at close to the same time. As a result, both get a cache miss (the response isn’t in the cache yet), and both independently initiate the request. So in this scenario, yes, it would unfortunately count two sessions.

On the other hand, if the load of the two tilesets were staggered slightly, the second one would get a cache hit and only one session would be used.

I wrote an issue for this:

I’ll try to answer your specific questions:

  1. If Unreal opens all of the levels (nearly) simultaneously, then it’s possible each one would use a session (or potentially more). I couldn’t see it doing this in my quick tests, but I suggest you check your particular case.
  2. Yes, as mentioned above, this scenario will use two sessions. But in that same Editor or application session, switching to another level that uses the same assets (or reloading the same level) should not use further sessions.
  3. Reloading the same tileset should not use another session, whether you delete the overlay first or not. Deleting and re-adding the overlay will not use another session, either.
6

I performed some tests today. Each packaging of my Unreal ENgine 5.4.4 project (Shipping) generates 23 total Bing Maps hits. There are 26 Maps in the package, 21 if which have Cesium terrains, and a few have OSM buildings. I must admit I don’t understand why packaging should result in any Bing Map Sessions, but perhaps there is a check done to verify the included tokens in the project are valid, requiring a server query. I learned that my project includes two different tokens, which I will want to address.

I plan to add the logging statements to the plugin as you suggest, but have not yet done so. I’m still trying to get my head around how I could rack upi 2700+ Bing sessions in one day of compiling, so that In the future it can be avoided.

To verify my understanding of your response to question 3 above, each time a play a level in Editor, I should NOT see the Bing count increment, whether or not it contains Bing Imagery overlay? This is great news, as most of my debugging involves restarting the same level in Editor over and over. This makes it all the more difficult to see how my usage counts have been so high.

It also sounds like deleting the Bing Imagery overlay is both unnecessary and ineffective in reducing my Bing map session counts.

In my project, one of my maps uses level streaming to load detail assets into different play areas as the user enters and exits. There are 39 global geographic regions and a persistent map containing the Cesium terrain. From a lobby, the user selects where to play, and the global coordinates are loaded into the Georeference, setting the origin, and the detail assets (Foliage, special buildings etc.) get loaded through Level Streaming Volumes.

The remaining 20 Maps included in the project each contain one Cesium Terrain, perhaps an OSM Building Asset with Bing Imagery applied, and have a hard-coded Georeference location. These were the first maps I created, before learning about Persistent Map layers. Each time the user wants to go to a different area, they return to the lobby and select the desired locale, and the appropriate map is loaded.

I had assumed that with each such relocation and new map loading, another one (or two) counts would be accrued. From you description, I could infer that this is not the case, and that no additional hits would occur. Is this correct?

Is it possible to simply teleport from one location to another on the globe without getting any more counts beyond those accrued when initially loading the level? I could modify my project to load a persistent map once, and make the lobby a location in that world that one teleports back to, and then selects the next location to teleport to, all without starting to Bing Maps sessions. Does this make sense?

Thanks again for your guidance. Trying to keep the count as low as possible as we figure this all out.

Cloudhopper3 (Tom)

7

Hi Tom,

Unreal’s level management is… complicated. So it might be best to add those log statements and get some firm evidence of what requests are made during your workflow. Otherwise I’m largely making educated guesses, and they could be wrong.

If something seems off based on those experiments, we can talk about what changes can and should be made in Cesium for Unreal to improve the situation. For example, Cesium for Unreal doesn’t do anything special to validate keys or anything of the sort during packaging. However, if Unreal itself loads the levels during this process, and thereby creates the Cesium3DTileset instances, we might be able to reduce usage by detecting this and not actually loading the Bing layers. Maybe.

My understanding of how the session reuse works is pretty simple, though. Bing sessions are cached at the process level (literally a static field in the C++ code), whether that process is the Unreal Editor process, or your application process. So each process should use only one Bing session, with a few exceptions:

  1. Simultaneously access, as mentioned in my previous message.
  2. Different Bing layers. For example, if your application uses both Bing Maps Aerial and Bing Maps Aerial with Labels, these are two different layers and each one will count as a session when first accessed.
  3. Token refresh. After some amount of time (I think it might be an hour?) the session token will expire and a new request to /assets/#/endpoint is required to get a new session token.

I don’t know if Unreal does something funny, like spawn a separate process multiple times during packaging.

8

I did have a situation once where Bing calls via Ion were failing and retries flooded my logs and smashed through my quota in minutes. I can’t recall the details but it was something like the Ion session wasn’t valid but my token was still being sent. I modify cesium-runtime and cesium-native - so was likely my bad.

But keep an eye on your logs in case you’re getting similar failed calls and retries. Ideally I’d like to be able to set a lower quota in Ion for such runaway conditions, so I don’t have to work on something else for the rest of the month.