I am currently facing an issue while attempting to convert an IFC file to a mesh and subsequently to a point cloud. Despite following the conversion process using IfcConvert to generate a .obj mesh file, I am encountering unexpected results.
The ifc I'm trying to convert looks like this [IFC.png]:
Initially, the conversion from IFC to .obj using IfcConvert appears correct, as indicated by the attached photo [mesh1.png]:
However, upon inspecting the mesh using MeshLab instead of CloudCompare, discrepancies become evident [mesh2.png]:
Moreover, when I proceed to convert this mesh to a .ply point cloud using the provided Python script, the resulting point cloud does not accurately represent the original geometry, particularly noticeable with the cylinders [ply.png]:
I suspect that the issue may stem from the initial transformation of the IFC file to .obj. Could you please provide guidance on how to address this issue or suggest any corrections that might improve the accuracy of the conversion?
I think what might be happening is that there is a large offset somewhere so the coordinates in the .obj are large / far away from origin. This causes issues in software that uses less precision. You might want to try running ifcconvert with --building-local-placment to ignore transformations in the spatial hierarchy from building and upwards where usually such large offsets are introduced.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your input regarding the large offsets in the coordinates of the .obj file. You were correct in identifying that the issue was related to the IFC being geolocated. By relocating the model back to the origin, the problem was resolved. However, I was only able to achieve this by using Revit and saving a copy of the IFC centered at (0, 0, 0) without geolocation.
Using the parameters --building-local-placement or --center-model as you suggested did not yield the expected results. The generated files still contain large coordinates, as demonstrated in this example: K24AC201_blp.obj. It seems that these options may not be functioning correctly.
Could you confirm if this functionality is working as intended? Additionally, once this issue is resolved, is there a way to recover the translation that was applied when using these parameters?
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Finally, I was able to solve the issue by using IfcOpenShell to center the model before performing the IFC conversion. However, I still believe there might be an issue with the --building-local-placement and --center-model parameters that should be investigated.
For anyone facing a similar problem, here's the code I used:
I am currently facing an issue while attempting to convert an IFC file to a mesh and subsequently to a point cloud. Despite following the conversion process using IfcConvert to generate a .obj mesh file, I am encountering unexpected results.
The ifc I'm trying to convert looks like this [IFC.png]:
Initially, the conversion from IFC to .obj using IfcConvert appears correct, as indicated by the attached photo [mesh1.png]:
However, upon inspecting the mesh using MeshLab instead of CloudCompare, discrepancies become evident [mesh2.png]:
Moreover, when I proceed to convert this mesh to a .ply point cloud using the provided Python script, the resulting point cloud does not accurately represent the original geometry, particularly noticeable with the cylinders [ply.png]:
I suspect that the issue may stem from the initial transformation of the IFC file to .obj. Could you please provide guidance on how to address this issue or suggest any corrections that might improve the accuracy of the conversion?
For your reference, all relevant files and the Python code used for conversion are available on GitHub at the following repository: https://github.com/MiquelRecloud/Help-IFC2Ply
Thank you in advance for your assistance. I look forward to your prompt response.
Last edit: Miquel Sala 2024-07-09
I think what might be happening is that there is a large offset somewhere so the coordinates in the .obj are large / far away from origin. This causes issues in software that uses less precision. You might want to try running ifcconvert with --building-local-placment to ignore transformations in the spatial hierarchy from building and upwards where usually such large offsets are introduced.
Thank you for your input regarding the large offsets in the coordinates of the .obj file. You were correct in identifying that the issue was related to the IFC being geolocated. By relocating the model back to the origin, the problem was resolved. However, I was only able to achieve this by using Revit and saving a copy of the IFC centered at (0, 0, 0) without geolocation.
Using the parameters --building-local-placement or --center-model as you suggested did not yield the expected results. The generated files still contain large coordinates, as demonstrated in this example: K24AC201_blp.obj. It seems that these options may not be functioning correctly.
Could you confirm if this functionality is working as intended? Additionally, once this issue is resolved, is there a way to recover the translation that was applied when using these parameters?
Thank you.
Finally, I was able to solve the issue by using IfcOpenShell to center the model before performing the IFC conversion. However, I still believe there might be an issue with the --building-local-placement and --center-model parameters that should be investigated.
For anyone facing a similar problem, here's the code I used: