Support vector files (KML, SHP, CZML, GeoJSON)

[argallegos]

This is a far-roadmap feature, as implementing it comes with a lot of other considerations, but we should have an issue to track it.

It's frequently requested on the forums - 01, 02, 03, 04

Please feel free to add any other thoughts or potential roadblocks here just so we have it on record.

[techdragon]

Just going to point out I’ve repeatedly shelved projects due to this feature being missing. Particularly CZML… Not having support for these formats was and continues to be a huge letdown. I have never wanted to use Cesium in a project that wasn't in some way dependent on having access to these formats, either as the primary content, or as crucial overlays.

Edit: tiny typo

[shehzan10]

@techdragon Completely agree with you that CZML and other formats supported in CesiumJS add a ton of functionality to create useful simulations and analytics. We're pushing on all fronts to add this (and more) functionality as it would enable a ton of use-cases, like yours, for the entire community. Its sometimes easy to forget (even for us) that Cesium for Unreal release was less than 6 months, so there is a ton of features we're looking to add to get it close to par with CesiumJS, which has a decade of development behind it.

Please feel free to reach out to me directly if there are specific use-cases we can help with in the short-term while we continue to work on these features.

[argallegos]

It looks like a plugin has been created to import this type of data into Unreal before - https://forums.unrealengine.com/t/plugin-import-gis-data-into-ue4/107459, but it doesn't seem maintained currently. Might be helpful as we look into our own implementation.

[techdragon]

I'd like to see specific issues for each of these formats, with the underlying work noted as blockers. Its pretty obvious supporting all the various vector formats is an "epic" task, and its all too easy for interested parties on the outside, like myself and others to see very little traction on these kinds of tasks, since naturally a lot of work needs to be done before such big tickets are marked as "shipped".

Also, that lets people express their support for each format and allow some kind of prioritisation to be performed. For instance CZML and GeoJSON share the need for JSON parsing functionality, KML needs an XML parser, and SHP needs a custom parser for the ESRI Shapefile format. (This also happens to be my personal prioritisation order of these four formats) All the formats will likely need a vector rendering layer to handle common vector rendering coordinate transforms and such, and would probably need a number of renderable object types they can use to show the various data types in the world such as marker, line, polygon, etc types and these should obviously be extensible so that we can implement more advanced rendering of these primitives if needed (for example, rendering markers that vary in size based on data from the GeoJSON). While its unfair to demand that this be a top priority, its a lot easier for us the community to plug gaps/help out/ build our own... if we see the incremental progress on this feature and know that fundamental components are built so we can give the individual functionality parts a shot.

Personally I'd feel much more confident taking a shot at building my own marker/point (and maybe even lines) rendering code if I had the parsing & world coordinate transform taken care of by people that know how all that works a lot better than me. Because while my point could be just enough code to do what I need, its useless to me if I can't keep my points in the right place when the existing raster data map layers move and zooms. I could probably do a decent enough job on a file parser too to be honest. So having paid employee time dedicated to a foundational part necessary for this functionality could be very valueable (the vector rendering layer to handle common vector rendering coordinate transforms I mentioned earlier)

That said... as I write all this out... and read through the https://github.com/CesiumGS/cesium-native code to try and see how the raster layers work since I was looking for something to suggest "we just need a vector version of this class", it feels like a lot of the the Unreal Engine specific magic is in the CesiumGeoreference* files and it might not be quite as much work as I first thought to implement a basic "vector point" but as I don't have the time right now to dig in deeper, I can't say for sure how hard it would be to also add lines or polygons. Lack of a C++ CZML parser isn't a huge deal as its just a specific JSON format so something shouldn't be too hard to cobble together for at least testing/prototyping purposes.

[davesauce14]

Hi team, is there any progress on this? I see this is from over a year ago

[IndigoCloud6]

Hi team, is there any progress on this?

[Neurowerk]

Hi, team, this is will be significant as well, to support CZML files for Cesium for Unreal.

[lzp0070007]

Hi, team, this is will be significant as well, to support geojson files for Cesium for Unreal.

[RayDog1995]

Trying to simplify flight crash recreation animations, attempted fs2020 and ran into issues, played around with cesium and if it would allow a kml file to be imported and used as a spline or something similar so I can easily add a plane model to have it follow the recorded path captured from the blackbox. Also id hope altitude data would be recognized and speed between data points.

[kring]

@RayDog1995 have you seen this "Build a Flight Tracker" tutorial? https://cesium.com/learn/unreal/unreal-flight-tracker/

[RayDog1995]

Yes, several times. That tutorial uses precompiled .csv files, have you seen this thread where everyone is asking for kml support in cesium plugin for unreal just like how cesiumjs can use kml files: https://community.cesium.com/t/how-to-use-vector-data-kml-shp/13041/2

[kring]

Yes, I understand that people want KML support. But that's a large feature, and we currently have more pressing priorities so we won't be able to start it right away. So I'm trying to find you a workaround in the meantime. If you're trying to make a plane follow a path, using a CSV file like in the flight tracker tutorial seems like it could be a viable option. Even if you have to convert the source data to CSV first.

[L0CKZ0R]

Bumping for update. The ability to bring in KML data is much needed for the plugin. The CSV flight path doesn't solve the problem for mac users because there is no visual studio with c++ available.

I need to be able to have a camera follow a KML path, and also to create a visual spline out of the path.

[azrogers]

Another request for GeoJSON from the forums: https://community.cesium.com/t/geojson-from-cesium-ion-to-unreal-engine/31495

[azrogers]

Apropos of nothing, I had an idea for how we might implement this across native runtimes using msdfgen, which is a library for generating Multi-Channel Signed Distance Fields. This means, when loading a vector, we'd load our data into a msdfgen::Shape (using code that would probably look a lot like its SVG implementation) and render it out to a texture, which would look something like:

Shape shape;
if (loadKmlFile(shape, filename)) {
    Bitmap<float, 3> msdf(64, 64);
    SDFTransformation t(...);
    generateMSDF(msdf, shape, t);
}

Then we copy that bitmap to a texture in whatever runtime we're using and treat it like a raster overlay, with the following shader code:

in vec2 texCoord;
out vec4 color;
uniform sampler2D msdf;
uniform vec4 bgColor;
uniform vec4 fgColor;
uniform float pxRange;

float median(float r, float g, float b) {
    return max(min(r, g), min(max(r, g), b));
}

float screenPxRange() {
    vec2 unitRange = vec2(pxRange)/vec2(textureSize(msdf, 0));
    vec2 screenTexSize = vec2(1.0)/fwidth(texCoord);
    return max(0.5*dot(unitRange, screenTexSize), 1.0);
}

void main() {
    vec3 msd = texture(msdf, texCoord).rgb;
    float sd = median(msd.r, msd.g, msd.b);
    float screenPxDistance = screenPxRange()*(sd - 0.5);
    float opacity = clamp(screenPxDistance + 0.5, 0.0, 1.0);
    color = mix(bgColor, fgColor, opacity);
}

This should give us very clean, crisp vector rendering on the GPU. Of course, this is oversimplifying - the loadKmlFile function (or loadShpFile or loadCzmlFile or whatever) is quite a task, so it's a bit of a "draw the rest of the owl" situation. But I think this is an approach that would let us handle the vast majority of the implementation in cesium-native with minimal work for implementation in each runtime - and without rasterizing the data.

[azrogers]

Hah. I wanted to see if there were any techniques for multi-color SDFs, and it looks like Adobe published a technique... in US patent number #10403005. Really cool technique, using the four color theorem to divide up the image into four separate color planes, each of regions of the original color without any adjacent pixels that might cause bleeding. The color planes are dilated to make sure each shape will be completely covered by its corresponding plane. Then in the shader you select the best SDF for the current point and use the color from its color plane. Would use eight or ten textures instead of one, but it could work. Shame it's patented. Maybe we can use this technique in whatever Cesium for Unreal version comes out in 2039.

We could build a texture atlas of all of the 24 RGB bit planes. If we used Valve's two-channel SDF approach instead of the three-channel msdfgen approach, we could pack a full-color 128x128 SDF into a 512x512 RGBA texture. But this feels more like a science project than a realistic proposal.

[azrogers]

Did not mean to close the issue :sob: