engine_web-ifc
engine_web-ifc copied to clipboard
ThatOpen
Wall openings is not displayed
Hello IFC files does not display some wall openings, please check image. On some other viewer, it is displayed. IFC file: https://easyupload.io/iy1jfm bad image: https://postimg.cc/LJFDTjmv OK image: https://postimg.cc/SjwfScYq Thank you for your help.
I think the hole is made, but for some unknown reason there is a thin layer blocking the hole
🟢🟢🟢
::take
Hi, @aka-blackboots! Thanks for taking this bounty! The due date is November 1, 2022 UTC.
If you need to submit some pull requests (PR) to complete the tasks, make sure that the last and only the last PR has a title that either starts with the bounty ID or is exactly the same as the bounty name. After the PR is merged, this bounty’s status will automatically changed to done.
If you do not need to make a PR, tell the manager @agviegas to run ::done command after your tasks is confirmed to be done.
Good luck!
🟢🟢🟢
::drop
Hi, @aka-blackboots! Thanks for giving it a try! It’s now once again available for anyone to take.
The link for the model appears to have expired. Would you be able to attach the model again?
@BSchafer01, connect with me on discord, and I will share a basic IFC file with you.
Hello, I have the same problem with this file: Projekt_COLORADO_PS.zip Some Openings are displayed correctly, but others dont. Hope this file can help.
And I guess, the same issue here: https://github.com/IFCjs/web-ifc/issues/126
Thank you
Hi, I think I have the same problem with a "public" IFC file: AC20-FZK-Haus.ifc (so easily retrieved by anyone and pretty small one). Some (most openings) are "closed" by a thin layer. When exporting "only" the IFCOPENINGELEMENT it see a strange thing: this thin layers is there.. so it is not a result of the boolean op... (it is in a way) but that in the first place the geometry to "remove" from the wall to create the hole contains that non manifold thin layer.
The model should look like this:
but the openings only are:
there is a thin layer inside each ones... sometimes it gets removed and sometimes it stays there... don"t know it it helps...
I'll keep ranting here because this problem is bothering me ... Looking a bit closer into this issue... it looks like in the IFC file, the geometry used to create the hole is defined (most of the time) as #32472= IFCSHAPEREPRESENTATION(#118,'Body','SweptSolid',(#32455,#32471)); I guess this means 2 reps are used to define the shape. Both are extruded #32455= IFCEXTRUDEDAREASOLID(#32445,#32452,#32453,0.3); (why a software would end up generating this... I don't know, specifically considering both "blocks" are same size and basically stand back to back). I assume webIFC generates the 2 geometries and pool them together in a single geometry. In turns, when boolean substract is called, it is called between a geometry and this 'pooled result' of two back to back geometry. The isInsideMesh function is then unable to provide the correct answer for those duplicated back to back triangles (moreover, answer is probably inconsistent depending on the ray direction)
Edit: some more digging... in fact it does generate triangles that are back to back but not identical.
contains a "manifold" inside "wall" :
made of triangles that are not "identical"
This probably comes from the fact the opening is made of 2 extrude that are merged into single representation. So when util.h::flattenRecursive is called => the method just "merge" both list of triangles... where a proper union should be made. Unfortunately the joinBoolean method within web-ifc is not able to remove these triangles either.
Finally able to confirm:
replacing the included boolean by csgjscpp and unioning in flattenrecursive =>
Now the 2 cents questions => is flatten recursive always supposed to perform union ? I would guess no (?) in this case... passing a flag all along to know what this union is exactly could be required... fully replacing the provided boolean bycsgjscpp is pretty easy and probably would be a good idea here... ... or not... as csgcpp enters infinite loop in some cases...