Incorrect reproduction of geometry (missing booleans)

[jomijomi]

Hi, I have an IFC-file exported from Tekla that imports correctly in xBIM 4.0.0 and Solibri. However, in xBIM 5.1.0 several boolean operations are missing. From the full file I’ve extracted (using xBIM Xplorer) two elements (out of many) showing the problem. Also, it does not produce any errors in the xBIM Xplorer log.

Assemblies and versions affected:

Version of xBIM that produce CORRECT result (downloaded installer of xBIM Xplorer): Xbim.Common 4.0.0.0 4.0.1911.29500 Xbim.Geometry.Engine.Interop 4.0.0.0 4.0.1912.28352 Xbim.Ifc 4.0.0.0 4.0.1911.29500 Xbim.Ifc2x3 4.0.0.0 4.0.1911.29500 Xbim.Ifc4 4.0.0.0 4.0.1911.29500 Xbim.IO 4.0.0.0 4.0.1911.29500 Xbim.ModelGeometry.Scene 4.0.0.0 4.0.1912.28352 Xbim.Presentation 4.0.0.0 4.0.2002.10344 Xbim.Tessellator 4.0.0.0 4.0.1911.29500

Version of xBIM that produce INCORRECT result (downloaded and compiled latest master/dev of xBIM Xplorer):

MASTER: Xbim.Common 5.1.0.0 5.1.274.0 Xbim.Geometry.Engine.Interop 5.1.0.0 5.1.283.0 Xbim.Ifc 5.1.0.0 5.1.274.0 Xbim.Ifc2x3 5.1.0.0 5.1.274.0 Xbim.Ifc4 5.1.0.0 5.1.274.0 Xbim.IO.Esent 5.1.0.0 5.1.274.0 Xbim.IO.MemoryModel 5.1.0.0 5.1.274.0 Xbim.ModelGeometry.Scene 5.1.0.0 5.1.283.0 Xbim.Presentation 5.1.0.0 5.1.0.0 Xbim.Tessellator 5.1.0.0 5.1.274.0

DEV: Xbim.Common 5.1.0.0 5.1.0.283 Xbim.Geometry.Engine.Interop 5.1.0.0 5.1.0.312 Xbim.Ifc 5.1.0.0 5.1.0.283 Xbim.Ifc2x3 5.1.0.0 5.1.0.283 Xbim.Ifc4 5.1.0.0 5.1.0.283 Xbim.IO.Esent 5.1.0.0 5.1.0.283 Xbim.IO.MemoryModel 5.1.0.0 5.1.0.283 Xbim.ModelGeometry.Scene 5.1.0.0 5.1.0.312 Xbim.Presentation 5.1.0.0 5.1.0.0 Xbim.Tessellator 5.1.0.0 5.1.0.283

Solibri:

xBIM 4.0.0:

xBIM 5.1.0

The (stripped) IFC-file: KP-00-V-00_3dsam.ifc.stripped_876_906.ifc.zip

Best regards, Mikael

[jomijomi]

So, after spending some time trying to solve these issues I have a couple of conclusions. Unfortunately, this will not be a silver bullet. Still, I thought that I could at least share my findings...

-Much of it depends on the chosen tolerance/fuzzy value. The file (from Tekla) has a precision of 1E-05. Increasing this to something like 0.006 seems to work a lot better (which is somewhere in-between the file precision and 1/50, which I have seen in previous versions of xBIM). Now to the fuzzy values (which I interpret as an additional tolerance according to OCCT docs). In XbimSolidSet/DoBoolean I basically set this to zero (default is 6 x tolerance). In XbimGeometryObjectSet/PerformBoolean (this is where feature elements, i.e. openings, are subtracted) I set this to 1 x tolerance (default is zero). So, basically, choosing a slightly “bigger” tolerance together with a small fuzzy value (in relation to the new tolerance) seems to work better overall.

-Now to the big thing: Performing MULTIPLE Boolean operations in a single operation, is NOT guaranteed to give you the same results as if you do them INDIVIDUALLY, i.e. one-by-one. So, what I have chosen to do is to re-perform (start over) the booleans INDIVIDUALLY if I get any WARNINGS (obviously, I do this also if I get any errors). First I tried to decode if there was any specific warning (or the number of them) that could be used as a heuristics as to when I really need to re-perform the booleans, but I couldn’t really find anything to use. The thing is that a warning doesn’t always produce a wrong/bad geometry, but very often it does. The chosen tolerance/fuzzy values also affects when I get a warning. Using the default values might produce a wrong geometry (as you see in the images in the original post), but it doesn’t trigger any warning. In addition, I sort the openings (in Xbim3DModelContext just before they are sent to the geometry engine) by size/volume in order to process the biggest first. First I thought that this might help when doing MULTIPLE at once, but it didn’t... Still, I can at least use it later if I get a warning and have to do them individually – when doing them INDIVIDUALLY I can early-out if I get an error/exception and at least return a geometry with some of the booleans performed (the biggest ones). Performance-wise I do see an increase in processing time (~10-15%), but the “fallback-to-individual-if-multiple-will-trigger-a-warning” is still much faster than doing everything individually. Obviously, this will depend on how much geometry that trigger warnings. If, for some reason, all of your MULTIPLE operations will trigger a warning then you will basically double the processing time…

I have successfully tested the above settings/changes on several other files, but I will have to do some more tests before I can give you a definitive answer on the tolerance/fuzzy values. However, I do believe that the “fallback-to-individual-if-multiple-will-trigger-a-warning” approach is something to consider. At least until OCCT will have a release where we can trust the “multiple” approach to give same results as the “individual” approach (and still have better performance).

Finally, this model does have a large number of booleans (sometimes up to 50 of them) that has to be performed on many of the geometries/components. As such, it can almost be seen as an asymptotic case. Still, Solibri imports the file correctly.

So, not a silver bullet, and also a bunch of magic numbers… Should we keep this as an open issue or close it for now..?

Best, Mikael

[CBenghi]

Hi Mikael,

thanks for this thorough report. Over the years we have changed strategy a few times, when it comes to the topics that you are discussing, and, as you also notice, we have found that there is no single approach that works in every scenario, which makes the balancing decision hard.

Your solution sounds reasonable, and it might be at least a configurable option in the platform.

With issues of corona spreading around I've not find time to devote to geometry lately, but if you have done some work feel free to send me a link to a branch and I'll try to look at incorporating it, as soon as I find time.

Many thanks, Claudio

[jomijomi]

Hi Claudio, I will try to do some more tests in the coming weeks and then clean up the code and see if I can expose some settings for the fuzziness as well as a some options for the booleans (i.e. MULTIPLE, MULTIPLE_WITH_INDIVIDUAL_FALLBACK, and INDIVIDUAL) and then send something to you for review.

I also see that you have some branches with OCCT 7.4.0 – have you seen any big difference in terms of speed or accuracy/correctness compared to 7.3.0?

Yeah, Corona is really starting to have an effect on everything. I hope you, Steve, and the rest of the team manage to stay safe and healthy!

Best, Mikael

[guenter1holzeder]

This area is like "THE aMAZEing LABYRINTH". Please look ahead for a maximum of compatibility. Thanks for investigation to all!

[guenter1holzeder]

... and health and endurance to all of us

[SteveLockley]

Hi all (Hi Claudio, hope you are all safe and well) as Claudio and Mikael point out this is an area where sometimes two wrongs do make a right. I always try to be true to precision and the schema when doing any coding on this area, but I do recognize Guenter's point about compatibility, for which I think he means "all tools should give the same or similar results", well visually at least. These last two weeks I have been working on a whole bunch of regressions and noticed that we do the boolean cut operations differently for cutting openings than we do for IfcBooleanOperations. We have a lot of test cases for the latter so I thought this code was more reliable. I have switched to using it for RelVoids. Guess what it made things worse! So the current version will do worse than the previous for this specific case. Easy enough to wind back though (and bring some other problems back) but before I do that I thought it best to try and dig a bit further and to share the issue wider.

Firstly, I am increasingly reluctant to mess with fuzzy factors. They are little more than fudge factors for bad tolerance definitions. How do bad tolerance definitions arise. Here goes....

1) The modelling software. Revit has a user minimum accuracy of 1/256th of an inch = ‭0.09921875‬mm. Yet it specifies precision for metric models in older versions as 1e-5 (0.00001), newer models are 1e-2 (0.01). So draw the bound of a face in the tool and all points should be more than 1/256th inch apart. Or what actually happens is they are on top of each other i.e. duplicates, this causes downstream boolean calculation errors. This latest update has many fixes for this.

2) Does this Revit precision extend to the idea of booleans too? I believe they use the ACIS engine but pass in the data from the UI. The ACIS engine has higher levels of accuracy, so when it does an operation it may well be 1e-5. or higher. This gives a clue why openings are a problem in Revit. Some geometric data has been constructed at 1/256th inch and some has come out of perhaps the ACIS engine (say an Extruded wire profile as an Opening) at 1e-5 or better. Whether we use 1e-2 or 1e-5 we could get it wrong.

3) So for Revit we have to replay this boolean operation and get the same result as Revit. Probably the last 5 years of my life have been wasted on this :-) but I thought I was close-ish.

4) Now Tekla. This seems to be heavily utilizing extrusion of profiles and CSG Trees. Entirely a different proposition from Revit, ACIS and OpenCascade. Xbim are trying to build correct manifold solids from their data, then do booleans that retain solids in their output. I find all kinds of nonsense in Tekla files, the most common things are face loops that are self-intersecting or have a zero area, Faces that are coincidental, even solids that have only three planar faces. The CSG mode of operation (in or out) can generate an output that looks right for these bad definitions but the result is possibly not a solid anymore. So if we do a lot of booleans one after the other at any point the result may be a non-manifold solid and the next op fails.. Mikael's problem above. I suspect but don't know that Solibri is more sympathetic to this mode of operation. It may have a CSG engine.

5) Finally OpenCascade. You will see lots of discussion on their site about Booleans and they will be the first to say this "Get your input data right" or it will go wrong. This has been my focus for several years now, fixing the input data and removing nonsense and it works fantastically, but I am sure there is more to do. Also there is a real problem with touching solids (i.e operations where two or more solids have coincident faces. The fuzzy factor is designed for these cases and some say it works some say just get your data right.

Conclusion and Suggestions I think we will get greater reliability from OpenCascade Booleans if we focus on the input data and specifically getting input tolerances correct. So when an extruded solid is built from a wire and a vector. The input data we need to focus on is the wire. We can control the tolerance on the vertices, I normally set it to the precision of the model (should I do this as 1/256" for Revit only?). When OCC builds the wire edges it defaults to setting the tolerance to less than the vertices (maybe 100th of the vertex tolerance). Does the IFC model precision apply to edges too? I currently limit the edge tolerance also to the model precision, is this right? It made Revit models work better! What should the tolerance of a face be? to avoid incorrect determination of coincidental faces. Should it be model precision of bigger? I currently set it to model precision, it's possible that for booleans only it should a real world tolerance like 100th millimeter.

I am going to take this example of Mikael's and see if I can fix it by changing the tolerances of the input shapes and hoping I can do it before Covid19 impacts :-) If this is a dead end, then perhaps we should consider implementing booleans as CSG using a different engine to OCC and use this for models like Tekla models.

Please let me have your thoughts and comments Steve

[bekraft]

I share your opinion. The first objective should be a more adaptive and verbose input processing methodology. The way of internal processing should rely on a deterministic logic. Otherwise incorrect input data will yield a „likely“ correct output. So the main goal is not to show geometry like platform X does, but how the geometry is reflected by the exported data. I am actually using the geometry engine as a test engine. The IFC only knows about a single precision per context. It´s better to have a separate tolerance setting per topology class with decreasing precision by value with increasing dimension. I.e. to match two points of the same body a coarser minimum distance setting better. Snapping edges, faces and finally sub solids will require higher precisions (lower by value) respectively. So tolerance is a complex setting per context.

Most of the discussion is about better prequalifying geometry data. We need to get more verbose here in order to list issues on incorrect geometry data. A first attempt of mine was to introduce a nullable volume flag which is more a workaround to check for closed manifolds (its part of a PR :-)

I donˋt recommend to use some internal heuristic adaptive workaround. I.e. concerning the Revit issue is more complex. As far I know, the way how Revit handles the IFC geometry export depends on an internal logic, trying to identify the best way to export the geometry representation. For instance a wall may be exported as swept solid with voids as a CSG representation. When modelling additional recesses, there is some fuzzy threshold which tells the exporter to use triangulated face sets. As you pointed out, there is a difference between UI tolerance and internal precision. Since the triangulation data seem to rely on the UI tolerance, you will get a worse result depending on your modelling workflows in Revit. So hidden workarounds depending on a guess how authoring platforms behave are never a solution. Additionally, the tolerance issue in Revit gets worse with increasing distance to the internal world origin. Users will notice the warning once they´ll try to change some parameters of objects near the boundaries of models having larger extents.

My conclusions:

• We need a prequalifying step which is more verbose with some structured output in order to filter for critical issues.
• A complex tolerance setting is required for points, edges, faces and solids
• An aligned verbose workflow of boolean operations which handles each model the same way

Cheers, Bernold

[jomijomi]

Hi Steve and others, Thank you so much for your detailed input! I have to admit that I almost felt a bit “dirty” to even consider messing with the fuzziness. Seeing Steve’s detailed answer I’m confident that he knows the best areas to focus on regarding tolerance/fuzziness. In my tests I only focused on the boolean operations, and didn’t further inspect the input geometries (except for checking that they were “ok” using the OCCT tools), so the problems might very well originate from tolerance or other issues in the individual geometries (wires, etc.) which then propagates into the booleans.

Yeah, Tekla might have too much of a ”Geometry by perkele” philosophy. The file is also a bit old by now so it’s possible that newer versions of Tekla produce better output. Anyway, this has always been my ultimate test file - “if this file imports correctly, then everything else in the universe will also work...”. I will continue to test more on newer files (from all vendors) and keep you updated. Using the IFC Stripping tool I will try to build up a repository of “problematic cases” to share. For the core xBIM team I will also be able to share the actual files, if that is of interest.

However, I do think that it is interesting that multiple vs individual booleans in OCCT produce different results. As far as I have been able to see from the documentation in OCCT, the “multiple booleans in a single operation” mainly improve performance by re-using the data structures (i.e. caching many of the computations), so in theory they should produce the same output as if we’re doing them one-by-one? Has anyone done some tests with OCCT 7.4.0 to see any improvements in this area?

Best, Mikael

[bekraft]

Hi all,

if the operations all near / or are within the tolerance thresholds, the order of operations will have an impact on the result. The tolerance is actually not only trick to handle input data but also to avoid numerical problems while doing boolean operations. Near the numerical „boundaries“ floating point additions and multiplications aren‘t symmetrical as math states.

In principal, the best way is to pass all inputs to the boolean op engine and let it decide. I don‘t know how Open Cascade builds the epsilon balls wrapping the intersections, but in CGAL it‘s recommended this way. So it can extend the tolerance if needed to. Maybe Steve knows more about this here concerning OCC.

Don‘t get me wrong when arguing about input data. But there lots of authoring tools exporting likely correct data beyond Tekla and Revit...

Cheers, Bernold

[SteveLockley]

I have uploaded a fix to the problem to the develop branch. It is using the latest changes I have made to how geometries are created and the switch to singular boolean operations described above by Mikael. I did quite a bit of testing to track the problem and it is just a problem inside the OCC multi boolean code. The warnings given are

• Warning: The positioning of the shapes leads to creation of the small edges without valid range
• Warning: Some sub-shapes of some of the argument become connected through other shapes and the argument became self-interfered
• Warning: Some of the faces passed to the Solid Builder algorithm have not been classified and not used for solids creation

The classifier is clearly struggling with the complexity and it has numerical issues. The issue of precision is not the cause of the problem here. However Bernold's response and the general problem of data input still need to be addressed. I have a proposal that I would like to share that involves some work I have been doing on netcore. I will create some documentation over the coming weeks and start a new topic to discuss XbimGeometry 6. I am hoping that we can pool our expertese and really wrestle this problem to the ground :-)

[SteveLockley]

Bizarrely this works for one of the panels but not completely for the rest, it needs more investigation I am afraid

[SteveLockley]

The others have some remnant masking the large opening, I am afraid I am too tired now :-)

[SteveLockley]

For info this is what the OCC actual operation in one go produces

[SteveLockley]

Bernhold I agree with you, but I am struggling to track down what is at the heart of this problem, my instinct is the issue of different tolerances for the different topological shapes (vertex,edge,face) may hold some clues

[SteveLockley]

Had a look at this with fresh eyes this morning and the booleans are doing just fine, it appears there is a skin over one side of the model that only shows in the triangulation However, the OCC definition of exactly the same brep data shows nothing The blue lines show that the holes in the faces are correctly cut. So the thin skin is coming from somewhere else. Will try and look when I have a bit of time

[SteveLockley]

Clearer when shaded

[jomijomi]

Steve, Thanks for sharing your progress! It seems then that the problem might actually be in the tessellation (conversion to triangles) then..? Also, don’t forget to sleep :) /Mikael

[SteveLockley]

I am trying to look at the triangulation now using our wexbim mesher and our new cloud platform

[SteveLockley]

But to be clear the single boolean op does not work as you observed

[SteveLockley]

I have identified that the problem is with the opencascade incremental meshing algorithm, I have isolated a face that is showing the problem. It is topologicaly correct and should look like this However when we shade the same face in the occ draw tool we get When I use xbim's tesselation on this face it is perfect...big more digging maybe

[SteveLockley]

Here is the brep if anyone wants to reproduce

Faulty.txt

[jomijomi]

Steve, Great work tracking this down! I took the .brep file and tried to open it in Open Cascade’s CAD Assistant. In the latest version (1.4, based on OCCT 7.4.1) it opens correctly. It also opens correctly in version 1.3 and 1.2.1 (both based on OCCT 7.3.1 according to the dlls). However, in version 1.2 (based on OCCT 7.3.1 according to the dlls) it produces the same error (one skin/face still covering the opening). 1.2 has the release date 2018-10-30 while 1.2.1 has the release date 2019-01-14, so I guess that somewhere in-between there we have the fix! At least I guess it’s safe to assume that the problem is gone from 2019-01-14 and forward. Now, looking at the downloads at the Open Cascade site, I see only 7.3.0 and 7.4.0 so I guess CAD Assistant is using intermediate versions (which we do not have access to)? In that case, is upgrading to 7.4.0 is our only option..?

When you say that that “xbim’s tessellation on this face is perfect”, what do you mean by that? Isn’t xBIM using Open Cascade’s incremental meshing algorithm (which will then produce the same error)? Or do you have a different meshing/tessellation code path that you can switch to instead?

Best, Mikael

[jomijomi]

I see now in the 7.4.0 release notes that Refactoring of BRepMesh was one of the major features in the release... "BRepMesh component has been refactored. The new architecture simplifies the process of mesh generation over OCCT’s BRep models and enables processing of some corner cases that were hard to handle before."

[SteveLockley]

Mikael, this is a life saver. I had started to dig into the meshing code and it was a bit daunting.... When I tesselate the objects if the shape is planar and has polyonal faces I use xbim's tesselation. I only use OCC meshing when it has curved surfaces in the shape. Because this object has a couple of cylinders in it I use OCC meshing. However this face is planar polygonal so I can do it both ways. I will upgrade to OCC4 and see if it does the job. Thanks for doing this, really helpful

[CBenghi]

Hi @SteveLockley,

I had prepared an occ740 branch some time ago with the latest release of occ, you can have a look at merging it from https://github.com/xBimTeam/XbimGeometry/tree/update/occ740

I have never merged it to develop, because you are the only true holder of the regression tests. :-)

Best, Claudio

[SteveLockley]

Aaah sorry Claudio missed this and have just finished upgrade, I did use your very handy tool though

From: Claudio Benghi notifications@github.com Sent: 02 April 2020 12:38 To: xBimTeam/XbimGeometry XbimGeometry@noreply.github.com Cc: Steve Lockley steve.lockley@xbim.net; Mention mention@noreply.github.com Subject: Re: [xBimTeam/XbimGeometry] Incorrect reproduction of geometry (missing booleans) (#254)

Hi @SteveLockleyhttps://github.com/SteveLockley,

I had prepared an occ740 branch some time ago with the latest release of occ, you can have a look at merging it from https://github.com/xBimTeam/XbimGeometry/tree/update/occ740

Best, Claudio

- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/xBimTeam/XbimGeometry/issues/254#issuecomment-607792272, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB6XPJLXJFYM37OJZFV2XB3RKR2KRANCNFSM4LJJBCIQ.

[SteveLockley]

I have updated to 7.4 and we have something that looks right now. It has fixed the meshing issues of OCC and we don't get the openings filled in. One of the panels is perfect, the other still has some small issues of accuracy. The warnings have been changed now to

• Some edges are too small and have no valid range
• Some sub-shapes of some of the argument become connected through other shapes and the argument became self-interfered

This is definitely a data modelling / accuracy issue. The better news is the single boolean operation works and we don't need to do a lot of single cuts so it is much faster. I have also changed xbim tessellation of OCC shapes to only use OCC meshes. This is just to make programmatic consistency, it used to have a performance gain on older computers but is not so significant now.

[bekraft]

Hi Steve, the current Xbim uses hybrid tessellation approach which has an issue in the Xbim-only code with incorrect orientation of the final mesh. I tried also to switch to OCC for tessellation, but noticed a huge decrease in performance for models with lots of polygonal faces. Will it perform better in OCC 7.4?

Best, Bernold

[SteveLockley]

Honestly, I don't know just yet. I have not totally switched it though. There are two places where we use hybrid, I have only switched one. The first is when we know its is a lot of polygonal faces and we do not need to do a boolean cutting operation on it (for example a piece of furniture or a car). Then we just use Xbim Tessellation. The second is when it has been constructed as an OCC shape because we need to do booleans, in fact when we have completed this boolean operation. In this case, if the result was totally a faceted polygon (typically a wall with window openings) then we used Xbim Tessellation on the polygonal faces of the OCC model. (This is in OccShape.cpp) I have only changed the second case. I suspect that the main performance gain is in the first case, as we do not need to sew all the faces using OCC. So hopefully this will not cause a significant problem.

[SteveLockley]

I have pushed this through to xplorer now and the result raises some interesting questions. You can see that there is a ridiculously thin membrane under the window opening. This is topologically correct and I suspect but have not checked that this is how it is defined in the IFC file. i.e. this is a correct interpretation of the data but not what was intended. I think this means there should be some post processing task that removes thin solids.

[jomijomi]

Hi Steve, I’m very impressed that you managed to update to OCCT 7.4 within a single day! (Credit also to Claudio who had already done it! Although I hadn’t tried his branch, I was aware of it but forgot to mention it in the post. Sorry!)

I’ve downloaded/compiled the latest code and will spend some time this weekend to check with a whole bunch of models from different projects/vendors.

However, at least from initial tests I think that I can confirm Bernold’s question about the performance. It still seems that the xBIM tessellation is (much) faster that the OCC one, even in 7.4.0. I took the previous version of OccShape.cpp and compared the time and on complete models it does makes a difference.

/Mikael

[SteveLockley]

I have spent quite a bit of time going over booleans and have found several issues, not least that boolean unions nested inside a lot of clip operations were being treated as cuts. I have made the fuzzy tolerance an app.config variable so you can try different values on different models. I think all of our tests show it does. My inclination is it should be a real world dimension like 0.01 mm or 0.1mm. To do this would mean a lot of changes to the interfaces to pass the size of a millimeter to the DoBoolean op. I just don't have the time to do that now. I have also set the tolerance of half spaces to be effected by the fuzzy tolerance, this improved quite a few failings of half space cuts creating orphaned faces. Normally caused becuase the plane of the half space was slightly off axis or the location point was a distance form the solid being cut. Finally, I moved the unification of shapes to after topological checking and correction when a boolean has been executed. This was because I found an infinite loop in OCC unification if the model was not topologically correct. Mikael, we can switch back quite easily to using Xbim Tesselation in OCC shape, I just wanted to reduce the number of moving parts so we can get consistent results. To sum up. Tekla heavily uses CSG mode of building solids. When I have looked at these models, there are errors in these CSG trees. The most common is self intersecting face wires (I have put a fix into handle these) and clips that leave nothing as a result. Also OCC can get confused whether you do them singularly or in a single operation, but this is greatly reduced in OCC74. I don't think we need to do the operations singularly now when we just get a warning, the result with warnings is often OK.

[jomijomi]

Steve, great work! I haven’t been able to test all of the models in my own repository with the latest version yet, but so far it seems that newer Tekla models are in a bit better shape and import correctly. There are still problems with the original problematic file (the one that those elements are extracted from), but I guess that it contains many small errors that makes it a very difficult case to solve perfectly. I managed to import the full file with visually correct results, but then I have to set the tolerance to 0.03 and the fuzzy factor to something small, like 0.5 to 2.0 and also enable fallback to individual booleans if I get warnings, so this is obviously too many “magic numbers” to be considered a general solution. Also, it is probably as you’ve previously said that two errors somehow make a right... However, I did notice that the meshing can end up in an infinite loop (only for on element so far but...) so I added a timeout for Engine.WriteTriangulation in Xbim3DModelContext (similar to the one in Xbim3DModelContext::CutWithTimeOut). This was actually the thing that took a long time to track down so I didn’t have time to test all of the models...

I will see if I get some time this weekend to check on more models and get back to you with more results! In the meantime I wish you all a happy Easter!!

/Mikael