Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ShapeUpgrade_UnifySameDomain causes a freeze #483

Open
santiagoIT opened this issue Jun 5, 2024 · 6 comments
Open

ShapeUpgrade_UnifySameDomain causes a freeze #483

santiagoIT opened this issue Jun 5, 2024 · 6 comments
Assignees

Comments

@santiagoIT
Copy link

Opening the attached IFC is not possible using the self-compiled XBim-Explorer (developer) branch.

During opening the program hangs and after a long wait the process dies.

What is causing the issue is a particular IfcBeam (#60042):
image

The problem happens when the ShapeUpgrade_UnifySameDomain is executed:
image1

if that line is commented out, the file opens fine.

This is the precise line where the program seems to hang forever:

image

In this case the solid is the result of calculated CSG solids. Is it really necessary to unify faces, edges after a boolean operation?
I have zero experience with Open-Cascade, but from experience with other modelers it seems odd to me.

I would expect to do something like that if a BREP is read in from an IFC file. In that case it makes sense to unify faces/edges.

Would be great to have some feedback. Ideally it is not always necessary to perform the face/edge cleanup.

A side remark:

The last oficial release of the XbimViewer (v4 I believe) opens the file just fine.

This is how the beam looks like (using a different IFC Viewer):

image

Let me know if I should try to look deeper into the problem. Maybe I am able figure something out, or if I hope it is not always necessary to do the face/edge cleanup. That is also something I could implement if you help me understand when not to execute it.

testFile.zip

@andyward
Copy link
Member

andyward commented Jun 6, 2024

Perhaps @Ibrahim5aad can shed some light?

@Ibrahim5aad
Copy link
Member

Ibrahim5aad commented Jun 30, 2024

Hi @santiagoIT, sorry I wasn't able to pick this earlier. Sadly, this is a long-standing issue for the ShapeUpgrade_UnifySameDomain algorithm, for some particular topologies and under some fuzzy tolerances in the Boolean operation, the output shape can cause the the unifier to hang and get stuck in some infinite loop. We provided some problematic shape before to a tracking ticket on OCC tracker, but it is still an open issue: https://tracker.dev.opencascade.org/view.php?id=32949

One thing you can do is to tweak the fuzzy tolerance of the Boolean operation a little bit . You don't need to dig into the codebase for that. The V5 engine have some application setting called FuzzyFactor that you can use. It is a factor that the model tolerance is multiplied with and used as the fuzzy tolerance of the Boolean operation.

image

The default value is 10.

image

I tried to set it to 1 and I got the IfcBeam (#60042) processed fine. I hope this can be of help to you.

@santiagoIT
Copy link
Author

@Ibrahim5aad @andyward
Thank you for the valuable info. Indeed, by setting the FuzzyFactor to 1 the file opens fine.

Would it make sense to expose the public static values in XbimGeometryCreator to managed code, so that they can be set/modified at runtime?
My suggestion would be to expand: IXbimGeometryCreator with the following properties:

static int BooleanTimeOut;
static double FuzzyFactor;
static double LinearDeflectionInMM;
static double AngularDeflectionInRadians;
static bool IgnoreIfcSweptDiskSolidParams;

Then managed code could set those values. That would be beneficial for us since we provide a class library.

Let me know your thoughts/suggestions, I could then create a pull request.

@santiagoIT
Copy link
Author

Now that I think about it further, the better approach would be add a static class:
XbimGeometryCreatorSettings to Xbim.Geometry.Engine and expose the properties there.

@andyward
Copy link
Member

Hi @santiagoIT

Agreed I'd avoid extending IXbimGeometryCreator - partly since the implementation may not be singleton and the lifetime of the GE is not always in the user's control. So you'd potentially find your setting being missed out

A static settings class would work - albeit there may be edge-case concurrency issues (but note the GE is not fully re-entrant anyway).

In the net6 branch I would probably adopt the Options pattern and have an IOptionsMonitor<GeometrySettings> passed in the GE constructor. That way you could change the settings dynamically at runtime.

@santiagoIT
Copy link
Author

Hello,

I have run into another case where an infinite loop occurs.

To reproduce set the FuzzyFactor to 1 and open the attached file.
InfiniteLoop_ShapeUpgrade_UnifySameDomain.zip

You can reproduce using the latest XBim-Explorer (developer) branch.

Setting FuzzyFactor >= 2 avoids the infinite loop.

I see there was some activity on the OCC trying to address the issue. But it seems the issue is still open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants