Enhancement of Cesium 3D Tiles Writer: Create Multiple LODs Tilesets

That is an excellent idea!!

Is there any update about this in FME 2020? @daleatsafe

It would be a great addition to this writer. Because of this, the 3D tiles produced by FME are unusable when you have a large dataset (say hundreds of Mb) as Cesium will try to load 100% of the data with the high-res textures, and will just crash.

In another thread, @daveatsafe indicates that you can use the "cesium_priority" value from 0 to 4 to do that manually, but I have no idea how to produce the different LOD in FME from a single dataset (say a CityGML file)

Fabien

IMO this is the essential next step for 3DTiles in FME.

This function will be very useful

Any update about this in FME 2022?

For an update on our Cesium 3D Tiles writer, there are some major improvements we have made for our recent FME 2022.1 release. These improvements centre around more efficient tiling and texture mapping. We also completed a number of bug fixes:

Texture handling, specifically:

• Support for webp textures
• Support for atlas textures

The other big change is in the tile hierarchy:

• Using a quad-tree structure for the tile hierarchy. We are now creating lower LOD tiles which are displayed when zoomed out. The writer is optimized for rendering performance, not for reducing dataset size. 

Other improvements:

• Draco compression
• The cesium_priority attribute is no longer used. The writer will automatically raise the priority of physically larger features.

If you have specific questions about our recent Cesium 3d tiles improvements, please contact support.

Details:

Using a quad-tree structure for the tile hierarchy. This is one reason that the output datasets are larger now, because we are now creating lower LOD tiles which are displayed when zoomed out. The writer is optimized for rendering performance, not for reducing dataset size. As such, some features will be contained in multiple b3dm files, whereas previously each feature was only in a single b3dm file.

A larger "max faces" value should produce fewer tiles. It is a tradeoff between performance and dataset size. For datasets with no textures, the number could be much larger.

Total dataset size is typically a much lower priority than rendering performance. You only create and upload the dataset once, but better rendering performance will benefit every user. 

Point Clouds

The 3D tiles writer will use the Cesium point cloud writer to output a .pnts file for each point cloud feature. So at the moment, to get usable point cloud output, you need to manually split it into separate tiles in workbench before writing to 3D tiles.

In the future the 3D tiles writer will need to:

Do the tiling in the writer, so that users don't have to do this themselves.

Do point cloud simplification, so that we can produce lower LOD tiles.

The point cloud writer can be used as a stand-alone writer, but without the tileset.json file that the 3D Tiles writer produces, the output of the point cloud writer is not much use.

So the best option is to use the 3D tiles writer and tile the point clouds first before writing. Then write out the point cloud features along with any other features using the 3D tiles writer.

I have just tested this in both FME 2022.1 & 2022.2, I get the same results with one one level of detail in both versions.

I tested this with a single OBJ file. I also uploaded the same OBJ file to cesium ION to test this, where multiple LODs were created.

Is there a specific setting that needs to be tweaked within FME to achieve multiple LODs?

Thanks,

Tom

Hi Dean, can I have some clarity on the draco compression please - is this just for point clouds? I have a photogrammertry model (OBJ) - when tiled using FME it is 10x the size compared to tiling on cesium ION. IS draco compression not supported for OBJ files?

I have a simulair experience regarding the writer of 3D tiles. FME writes one 'data' folder with all de b3dm files in it. There is also one .json file for the dataset. Cesium ION generates multiple 'data' folder according to the zoom levels. So, for a small dataset I have a folders called '0', '1', '2'. All of these folders contain some b3dm files that are related to that specific zoomlevel.

In Bentley ContextCapture, the writing of 3D tiles is also different, but more relatable with the FME output. ContextCapture produces b3dm file with names related to the zoomlevel 'example...._L0', but also contains multiple .json files related to the 3d tiles.

Although all the outputs are different, they can be read by Cesium and Luciad Fusion. So, they are all valid. Maybe, the standard of OGC3DTILES is not mature enough to eliminate these problems. However, the loading performance of the tiles produced in FME are slower in comparision to the ones produced with Cesium. So, I really hope that Safe evolves the writer in further editions of FME.

Correct me if i'm wrong, but according to my experience FME is still exporting only one single tileset.json file for an entire Cesium 3DTiles dataset/writer. Therefore i think one could not say this idea is "released". It is indeed true that the geometry itself is splitted into multiple parts/LOD levels since version 2022.2, but that's not the case with the tileset.json file(s) which is quite crucial and goes together with the geometry (3dbm).

Cesium 3DTiles are meant for streaming huge amount of 3D data through the web. If you don't split up the tileset.json files, you end up with one single huge tileset.json file from a few hundreds MB's which is not working in a web environment ofcourse... One tileset.json file should be maximum 2MB and should be build up hierarchically, see also the OGC specifications: https://portal.ogc.org/files/92685 .

There should be one "root" tileset.json file and each "child" object should have it's own tileset.json.

I hope this idea can be opened again and this can be implemented in a future release.