Hi,
I’m implementing export to 3D Tiles from our terrain generating cloud service Remoscape and I’m now investigating how to import that into Unreal Engine using the Cesium for Unreal plugin.
For CesiumJS we will include a simple .js file with some code creating a ClippingPlaneCollection to automatically clip a hole in the Cesium World Terrain. I would like to do something similar to make it convenient to import into Unreal Engine as well.
So is there any way I can programmatically create a CesiumCartographicPolygon in ECEF or lon/lat coordinates and include in my export, so that the user can easily import this into Unreal Engine?
/Andreas
Yes, you can create an ACesiumCartographicPolygon instance from C++ code in the same way you can create any Unreal Actor. We don’t have separate documentation for the C++ API, but most of the header files have extensive comments.
Ok, thanks. I’m not experienced with UE, but I guess we could include a C++ class with hard-coded coordinates in our export somehow. But then the users would have to compile it themselves, correct?
Is there any other way that we could include a more simple configuration of a cartographic polygon that can be fairly easy for the user to use to apply, without using C++? For example a configuration file?
You said “programmatically” so I thought you wanted to write code to do this. There’s no built-in support for reading polygon points from a file, but you can easily write either C++ or Blueprints code to read the file and create the polygons. “Easily” if you’re familiar with C++ and/or Blueprints, of course. If not, you’ll have to ramp up on one of them or find someone that can help you out.
Yes, custom code was just my first thought. I’m no stranger to C++ but I’m afraid we would have to build a new DLL for each UE release, or require the user to compile our code. Maybe Blueprints code would be a more generic and better way then, but that’s just a guess. And we would have to read up on and learn Blueprints, which will probably be a later activity.
But let’s say the user wants to create the cartographic polygon manually from our corner coordinates, is there a way to enter exact geocentric or lat/lon coordinates for the polygon points? Or snap them conveniently to the tileset’s corners? When trying to edit each point’s location it seems to be defined in centimeters from the CesiumGeoreference origin, could you confirm and elaborate a bit around that? If I’m right, maybe we could just instruct the user to enter a given origin lat/lon in the CesiumGeoreference and give these local centimeter coordinates that would have to be manually entered as locations.
No, sorry, there’s currently no way in the Editor UI To enter exact longitude/latitude coordinates or do automatic snapping to some other tileset. The points are defined in UE’s normal world coordinates, where are indeed centimeters. The CesiumGeoreference Actor has methods that can convert longitude/latitude/height to UE world coordinates, which can then be used to set the position of polygon points.
One thing you might experiment with is using copy/paste. If you set up a CesiumCartographicPolygon in the Editor and then right-click and choose Edit->Copy, then paste it into a text editor, you’ll see some structured text definining the Actor. The points are in there. You can go the other way, too. If you have text like this on the clipboard, you can paste it into the Outliner panel and UE will create an Actor from it. So, in theory, you could generate this text programmatically and then ask the user to paste it into their level. The trick will be generating the correct polygoin points, because they’re a function of the CesiumGeoreference’s origin. You could ask the user to paste in their georeference first, or ask them to enter the georeference origin longitude/latitude/height.
You’ll also need to be able to do the transformation yourself. cesium-native can do that easily with its LocalHorizontalCoordinateSystem class if you’re working in C++.
But maybe a Blueprint-based plugin to automate all this within the UE environment would be best.
Final thought: using clipping to do inset terrain is probably not a great solution overall. The biggest problem is that the clipped-away tileset will still affect physics. In Cesium ion, we do terrain insetting without clipping by using “layers” of quantized mesh terrain. A layer consists of every tile affected by the inset. Any tiles that don’t overlap with the inset area at all are instead pulled from the base layer.
Thanks for the info!
The copy-paste route may actually be a convenient solution that we might try to implement. That is, if we can figure out how to set the SplineCurves part with its out/in values, arrive/leave tangents and ReparamTable. The transformation should be easier. We’ll have to look into the code I guess.
I don’t quite understand the bit about the quantized terrain layer in Cesium ion. Do you mean that you replace your regular tiles affecting physics with such a layer? Does this happen in the background if I apply clipping planes to cut out a hole for our terrain?
A lot of the curve parameters aren’t actually used because we always use straight lines to connect the polygon edges. So try just ignoring them to start.
The insetting by Cesium ion is done at tileset generation time. When you upload terrain data to Cesium ion, you can choose Cesium World Terrain as the base. For tiles that partially overlap the new data, we combine the base layer (Cesium World Terrain) tile with the new source data to produce a new tile. I think doing this with your own tiler and Cesium World Terrain would be a violation of our terms of use. But you could do it with your own base layer. Or you could use Cesium ion (the offline version of it if necessary) rather than writing your own tiler!