Automatically placing Catographic Polygon

Hi, I am very new to Cesium and am looking for some advice.

We already have an application set up to stream data into CesiumForUnreal.
What we want to do now is automatically clip specific areas on the map; these areas are set up in 3D software and exported with the scene (now they are represented by simple plane meshes).
I think I can read the tileset data in C++ and somehow get the mesh data, then generate Catographic Polygons based on that.
But the tiles only load when the camera is close enough, and they will be unload/reload frequently, so I am wondering if this is the best way to do it.
We are on CesiumForUnreal v2.16.1. What would be a better approach here?

What I can think of now is if we can stream JSON (like GeoJSON) into CesiumForUnreal, then generate Catographic Polygons using the point data. But CesiumForUnreal doesn’t seem to support GeoJSON?

Hi @isseychen,

This should be possible in the latest versions of Cesium for Unreal! v2.16.1 is a fairly old version of the plugin; since then, we have added:

  • Support for reading GeoJSON documents in v2.18.0
  • Support for generating a polygon from an array of coordinates at runtime in v2.23.0

With this, it should be possible to pass in a GeoJSON document, iterate over its line strings, and set the resulting array of points on a CesiumCartographicPolygon. Let us know if this works for your use case!

Ah thanks!
I don’t think we can upgrade now, but I will check the latest Cesium for Unreal to see if there are any functions we can use.

Thanks for the reply!

A follow-up question.
Do you think it’s a good idea for CesiumCartographicPolygon to be created/destroyed dynamically, like the streaming of 3DTiles?

We are discussing this because we are not sure of the performance cost of just creating a lot of CesiumCartographicPolygon on Earth and leaving them there, even though they might be on the other side of the Earth.

If we want to load/unload them dynamically, is that a function of Cesium?

Hey @isseychen,

Good question. The short answer: polygons on the other side of the Earth should have minimal performance impact because the CesiumPolygonRasterOverlay only needs to rasterize polygons for tiles that are actually loaded. Since tiles far from the camera aren’t loaded, those distant polygons effectively do nothing at render time.

The main cost is the per-frame check of each polygon against each loaded tile’s bounds to determine if rasterization is needed. For a moderate number of polygons (tens to low hundreds), this should be negligible. If you’re looking at thousands, you’d want to profile it.

So for your case, I’d suggest:

  1. Start with keeping them all active. If your polygon count is reasonable, the simplicity of “create them all and leave them” likely outweighs the engineering cost of a dynamic loading system.

  2. Profile if you notice issues. Use Unreal’s stat tools to check if the overlay is taking significant frame time. If it is, then dynamic creation/destruction becomes worthwhile.

  3. Dynamic creation is supported (as Janine mentioned, v2.23.0 added SetPolygonPoints at runtime), so you have the option to build a streaming system around it if needed. But I’d only go there if profiling shows a problem.

There isn’t currently a built-in “stream polygons like tiles” system in the plugin, so that would be something you’d build on your end if needed.

Hope that helps frame the decision!

Ah, thanks for the reply!
That’s very helpful!

Hi, I’m back with another question.

I notice that when the tileset is clipped by CesiumCartographicPolygon, colliders are not always affected, i.e., you are not able to enter the clip area because the collider is not updated.

I searched on the forum, and it seems to be a known issue: the collider is not supposed to be affected by clipping.

But in my case, in some areas it does work; has something been changed on the Cesium side?

If it’s a misunderstanding, i.e., clipping is not affecting colliders, what would be a possible solution to update the collider in CesiumForUnreal v2.16.1?

If it’s not, what should I do to make the collider update more consistently?

Cheers

Hey @isseychen,

I don’t think anything has changed on the Cesium side here. Clipping with a CesiumCartographicPolygon is still a material effect: the CesiumPolygonRasterOverlay sets the opacity mask to zero inside the polygon, so the geometry and its collision are still there. Kevin explained this in an older thread, and I believe it applies to v2.16.1 as well.

I believe the reason it works in some areas is the Exclude Selected Tiles option on the CesiumPolygonRasterOverlay (on by default). Any tile that falls entirely inside a polygon is skipped from loading altogether, so there is no mesh and no collision for it. Tiles that only partially overlap the polygon still load in full, and those are the ones you bump into. Which tiles are fully inside depends on tile size, so it shifts with the tileset’s level of detail, the camera distance, and the Maximum Screen Space Error setting.

Proper geometry clipping (which would fix collision too) is tracked in cesium-unreal#1644, and there is a research issue on filtering physics instead in #1737. Neither are complete yet however, so on v2.16.1 you would need to handle it on the project side. A couple of directions, neither of which I have tested against a tileset:

  • Toggle collision per area. Someone did a version of this in another thread: detect when the pawn is inside a polygon and disable the tileset’s collision while it is, then re-enable on exit. They reported it working for driving down roads cut into photogrammetry. If you need the tileset to keep colliding with other objects while the pawn (or any other object you need) passes through, you could give the tileset its own object channel (Project Settings > Collision > new Object Channel, then set Object Type under the tileset’s Collision settings) and have the pawn ignore that channel while inside a trigger volume over the clipped area. The tileset applies its collision settings to every streamed tile, so the channel carries through. I haven’t tested this myself though, but in theory should work
  • Pad the polygon. Tiles that straddle the polygon edge always keep their full collision, so extend the polygon well past the area the player actually walks in. The invisible edge then sits where nobody reaches it. This is fragile because tile size changes with camera distance and Maximum Screen Space Error, so it suits fixed or constrained camera setups. It would also mean you’d have to put the work in to model or otherwise fill-in the larger removed area.

If you have further questions, can you move this to a new topic? We try to create new topics/posts for new questions so they are more easily discovered for the community.

Hope that helps!

Ah yes, I was thinking I will have to disable the collision test baesd on the character position to get a more reasonable result.

Thanks for the reply, I will do some tests on my end.

If I have further questions I will start a new thread.

Cheers!