Tue, 07/09/2024 - 12:06
Hello.
I've got an issue importing a STeP model that I unfortunately cannot share.
OC keeps consuming more and more memory until it's killed (aroung 40GB or so).
I tried debugging it and I see the problem arises in the function CreateSolids (ShapeFix_Solid.cxx, line 248 in version 7.8.1).
The code is:
//Creation of compsolid from shells containing shared faces.
TopTools_IndexedDataMapOfShapeListOfShape aMapFaceShells;
TopExp::MapShapesAndAncestors(theShape,TopAbs_FACE,TopAbs_SHELL,aMapFaceShells);
for(Standard_Integer i =1; i <= aMapFaceShells.Extent(); i++) {
const TopTools_ListOfShape& lshells = aMapFaceShells.FindFromIndex(i);
if(lshells.Extent() <2) continue;
TopoDS_CompSolid aCompSolid;
BRep_Builder aB;
aB.MakeCompSolid(aCompSolid);
isDone = (theShape.ShapeType() != TopAbs_COMPSOLID || isDone);
Standard_Integer nbSol = 0;
for(TopTools_ListIteratorOfListOfShape lItSh(lshells);lItSh.More(); lItSh.Next()) {
if(ShellSolid.Contains(lItSh.Value())) {
const TopoDS_Shape& aShape = ShellSolid.FindFromKey(lItSh.Value());
TopExp_Explorer aExpSol(aShape, TopAbs_SOLID);
for(;aExpSol.More(); aExpSol.Next())
{
aB.Add(aCompSolid,aExpSol.Current());
nbSol++;
}
}
}
if(nbSol >1)
{
for(TopTools_ListIteratorOfListOfShape lItSh1(lshells);lItSh1.More(); lItSh1.Next())
{
if(ShellSolid.Contains(lItSh1.Value()))
ShellSolid.ChangeFromKey(lItSh1.Value()) = aCompSolid;
}
}
}
At each iteration of i, nbSol keeps growing exponentially:
_ i = 1 -> nbSol = 1;
_ i = 2 -> nbSol = 4;
_ i = 3 -> nbSol = 8;
_ i = 4 -> nbSol = 16;
_ i = 5 -> nbSol = 32;
_ i = 6 -> nbSol = 64;
_ i = 7 -> nbSol = 128;
_ i = 8 -> nbSol = 256;
_ i = 9 -> nbSol = 512;
...
_ i = 24 -> nbSol = 16777216;
_ i = 25 -> nbSol = 33554432
... then it's hard to keep going on.
Something is obviously wrong (as the model is imported correctly by other softwares); however I'm not so proficient with OC internals, so I don't know where to look or what to set or what tools I should try.
Anyone can give any hint?
Thanks in advance.
Tue, 07/09/2024 - 12:21
Hello, your problem similar with 0032127: Data Exchange - faceted STEP file will not open - MantisBT (opencascade.org)
I see that you have a lot of shells within single solid. That is not expected input for current algo.
The fast workaround is disable that type of healing - if you are using XSTEP shape healing file, please turn off next setting (FromSTEP.FixShape.FixShellOrientationMode). Make it equal with "0"
Usual path: "occt\occt\install\src\XSTEPResource\STEP"
If you don't use a file or not delivery, please update that parameter using the next code.
Please check with JeMalloc memory manager. It can not help, but at least can be tested. If you can share your file, it will be helpful for us to reproduce especially on your problem case.
Best regards, Dmitrii.
Tue, 07/09/2024 - 20:20
Thanks for answering.
I fail to see the similarity with the bug you linked: the problem there, IIUC, is there's no structure in the file, but only a lot of free faces; here there are breps. In any case, I'll trust you and keep an eye on that issue.
I don't even know what "XSTEP shape healing file" is (sorry, I feel documentation is the worst part of OC :).
I'm using the following code:
Handle(XCAFApp_Application) App{XCAFApp_Application::GetApplication()};
Handle(TDocStd_Document) Doc;
App->NewDocument("BinXCAF",Doc);
>>> STEPControl_Controller::Init();
>>> Interface_Static::SetIVal("FromSTEP.FixShape.FixShellOrientationMode",0);
STEPCAFControl_Reader;
if (reader.ReadFile(FileName)!=IFSelect_RetDone) throw std::runtime_error{"OpenCASCADE STEP reading failed"};
if (!reader.Transfer(Doc)) throw std::runtime_error{"OpenCASCADE transfer failed"};
As you can see, I added the code you suggested (>>>), but nothing changed.
Perhaps I've done it wrong?
I've tried this on FreeBSD, which, AFAICT uses jemalloc by default.
In cmake config I have USE_MMGR_TYPE=NATIVE.
Do you still suggest I try USE_MMGR_TYPE=JEMALLOC?
I wish I could share this file. Alas, as I said previously, I don't have clearance. It comes from a big well-known company who doesn't like to share their "secrets".
bye & Thanks
av.
Tue, 07/09/2024 - 21:20
Yes, needs to update the CMake variable to use another manager.
As for a parameter. This parameter will have no affect if resource is exist on the your env. please copy a resource file from "occt\occt\install\src\XSTEPResource\STEP" to some location.
And specify the next env variable before calling your app or inside your app. "CSF_STEPDefaults" to the folder which contains "STEP" file (no extension).
And please update the parameter that i describe before.
_
Yes, documentation for OCCT is not well structured. We want to improve userability, but it is difficult for application from 1990x :) With a gigantic size of functionality.
Soon we simplify DE processes to have any needed API in one place.
Best regards, Dmitrii.
Sun, 07/14/2024 - 20:28
Thanks.
Using the file and the environment variable it works perfecly.
However, this is a bit of a hassle (we'd need to modify installers, etc...), so if I could achieve this through code, it would be a lot simpler.
Consider:
_ I don't have the "STEP" file anywhere (except in OC sources);
_ I don't have the "CSF_STEPDefaults" environment variable;
_ IIUC you're saying in such a situation the code I posted should work? Or, otherwise, how should it be modified?
Thanks in advance.
bye
av.
Mon, 07/15/2024 - 09:57
Hello, it is for sure possible from your source code update.
You need to make specific OCCT's static variable as empty string. I do not remember which one. I will return to you when found.
Anyway I guess it will be better to improve out documentation in the same time :)
Best regards, Dmitrii.
Mon, 07/15/2024 - 12:13
That should work :0
Best regards, Dmitrii.
Mon, 07/15/2024 - 17:04
Works perfectly.
Thanks a lot.