I’m facing some troubles converting IFC data to Cesium 3D Tiles.
Background:
I have several IFC files containing mostly 3D objects concerning civil engineering
source coordinate system: EPS:2056
different, user-defined PropertySets
different IFC versions
Goal:
Cesium 3D Tiles with all attributes (PropertySets)
What I did so far (transformers in FME):
Adding a dynamic reader with autodetecting IFC version
Extracting PropertySets from Geometry
Doing some cleaning on Geometry, i.e. removing extra Bounding Boxes and adding Vertex Normals
Scanning the schema
Writing dynamically to Cesium3DTiles
FME Version: 2024.2.1.0 (Build 24801)
Problems:
some features are missing
I cannot see why some features/objects are missing. They obiously run through all transformers until the writer. There are no errors, only 2 warnings saying: NOT changing coordinate system of reader identified by keyword `IFC_1' from `EPSG:2056' to `IFC_COORDSYS_0' -- mapping file setting of `EPSG:2056' overrides coordinate system `IFC_COORDSYS_0' read from file and Geometry instance was modified, the geometry definition will be instantiated
When inspecting the data just before the writer I cannot see any difference to other objects. They all are the same geometry type.
Questions:
Do I miss some validations?
Are there any more requirements for writing Cesium 3D Tiles?
Cheers, MariaKa
Best answer by virtualcitymatt
virtualcitymatt wrote:
mariaka wrote:
I just let my collegue run the workspace - with the same result.
Additionally I published the workspace on an FME Flow instance (2024), again with the same result. If I add a tester, which filters the subjected objects, the result is empty.
@virtualcitymatt Can you please add a Tester and see if the result is empty or not?
If there are any files written, can you please give them to me?!
Sure- here I output to gltf and obj with the same filter
Ahh but 3DTiles was empty - The issue is that these features are being treated as schema features rather than data features.
These 3 features are the first features for each of the feature types. On the features there are is a special fme attribute which controls this. “fme_schema_handeling”. The value of this is “schema_only”. It means that the first features for each feature type will be treated as only a feature and will be used to define the output schema, the remaining features will be written as data features.
The FeatureMerger after the ScemaScanner joins the schema onto all the features including this unexposed attribute.
From what I can see you want to fanout by the fme_basename, but I see that the fme_basename isn’t included as an attribute on the schema feature. This shouldn’t matter for writing.
If you change the settings of the SchemaScanner to also GroupBy the fme_basename this should help.
I also skipped out all the stuff at the end and just ran the schema scanner output directly into the writer. Because the SchemaFeatures come out fist these are used by the writer to define the feature types one at a time in order.
One thing you can check is to try using the gltf writer to see if there are any warnings about skipped geometries although I would expect the 3DTiels writer to also let you know
I know that for GLTF (and by extension 3D Tiles) the formats are sensitive to invalid mesh geometries. I’ve found that I’ve had to do quite a bit of fixing of geometries for FME to not skip parts of the file. for me the issue was made obvious because I was merging all meshes together into a single feature, if there were any parts which were bad then the whole geometry got skipped.
@virtualcitymatt Thanks, that helped a bit. This writer didn’t write these objects either. 😶 In the meantime I also tried other 3D-writer (besides GLTF): OBJ, FBX, STL, COLLADA, USD, CITYGML and OGCKML. None of them wrote these objects and didn’t give me any errors/warnings.
I would like to provide some sample data and appreciate it very much if someone could find out why some objects couldn’t be written. The data is manipulated in their location and all the attributes were removed (due to privacy policy), but the geometries and relevant id attributes were preserved.
Hmm, which version of FME are you working with? I just tried this dataset in FME 2024.2 and had no issue in the output. The 3 reported features seemed to be there.
I just let my collegue run the workspace - with the same result.
Additionally I published the workspace on an FME Flow instance (2024), again with the same result. If I add a tester, which filters the subjected objects, the result is empty.
@virtualcitymatt Can you please add a Tester and see if the result is empty or not?
If there are any files written, can you please give them to me?!
I just let my collegue run the workspace - with the same result.
Additionally I published the workspace on an FME Flow instance (2024), again with the same result. If I add a tester, which filters the subjected objects, the result is empty.
@virtualcitymatt Can you please add a Tester and see if the result is empty or not?
If there are any files written, can you please give them to me?!
Sure- here I output to gltf and obj with the same filter
I just let my collegue run the workspace - with the same result.
Additionally I published the workspace on an FME Flow instance (2024), again with the same result. If I add a tester, which filters the subjected objects, the result is empty.
@virtualcitymatt Can you please add a Tester and see if the result is empty or not?
If there are any files written, can you please give them to me?!
Sure- here I output to gltf and obj with the same filter
Ahh but 3DTiles was empty - The issue is that these features are being treated as schema features rather than data features.
These 3 features are the first features for each of the feature types. On the features there are is a special fme attribute which controls this. “fme_schema_handeling”. The value of this is “schema_only”. It means that the first features for each feature type will be treated as only a feature and will be used to define the output schema, the remaining features will be written as data features.
The FeatureMerger after the ScemaScanner joins the schema onto all the features including this unexposed attribute.
From what I can see you want to fanout by the fme_basename, but I see that the fme_basename isn’t included as an attribute on the schema feature. This shouldn’t matter for writing.
If you change the settings of the SchemaScanner to also GroupBy the fme_basename this should help.
I also skipped out all the stuff at the end and just ran the schema scanner output directly into the writer. Because the SchemaFeatures come out fist these are used by the writer to define the feature types one at a time in order.
That means: The writer needs a “blank” feature conatining the schema to dynamically read the schema from that feature. Right?! And it always takes the first feature? In case some sorting will be done in between I have to make sure that no needed geometry data will get lost as schema feature (and re-sort again)?!
That means: The writer needs a “blank” feature conatining the schema to dynamically read the schema from that feature. Right?! And it always takes the first feature? In case some sorting will be done in between I have to make sure that no needed geometry data will get lost as schema feature (and re-sort again)?!
It doesn’t have to be blank, but everything in it will be ignored for the first feature, yes. Usually the SchemaScanner just handles all this and should be used right at the end before the output. That should give you you’re best chance of a clean workspace and a clean output.
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.
