Tue, 02/22/2022 - 19:13
Hey there!
I hit a bit of a wall a couple of weeks back and haven't been able to find a solution yet so I was hoping that maybe someone here might have an idea for me to what could create this behavior.
The use-case I have is:
-> A box is created and all new faces are correctly written onto TDF tree with the evolution "primitive".
The data tree looks like this after the primitive creation:
0:2 Name: Tracked Shape
--0:2:1 Name: Generated Box Node, Evolution = PRIMITIVE
----0:2:1:1 Name: Generated Faces
------0:2:1:1:1 , Evolution = PRIMITIVE
------0:2:1:1:2 , Evolution = PRIMITIVE
------0:2:1:1:3 , Evolution = PRIMITIVE
------0:2:1:1:4 , Evolution = PRIMITIVE
------0:2:1:1:5 , Evolution = PRIMITIVE
------0:2:1:1:6 , Evolution = PRIMITIVE
-> Then an edge is selected for filleting, the fillet operation is being called and all changed, generated (and possibly deleted) faces are written back to the TDF tree once again (which looks fine from my understanding, also Solve() will work on it):
--0:1:1 Name: A selected edge. Sub-node is the context Shape, Evolution = SELECTED
----0:1:1:1 , Evolution = SELECTED
0:2 Name: Tracked Shape
--0:2:1 Name: Generated Box Node, Evolution = PRIMITIVE
----0:2:1:1 Name: Generated Faces
------0:2:1:1:1 , Evolution = PRIMITIVE
------0:2:1:1:2 , Evolution = PRIMITIVE
------0:2:1:1:3 , Evolution = PRIMITIVE
------0:2:1:1:4 , Evolution = PRIMITIVE
------0:2:1:1:5 , Evolution = PRIMITIVE
------0:2:1:1:6 , Evolution = PRIMITIVE
0:3 Name: Fillet Node, Evolution = MODIFY
--0:3:0 Name: Modified faces
----0:3:0:1 Name: Modified face, Evolution = MODIFY
----0:3:0:2 Name: Modified face, Evolution = MODIFY
----0:3:0:3 Name: Modified face, Evolution = MODIFY
----0:3:0:4 Name: Modified face, Evolution = MODIFY
--0:3:1 Name: Deleted faces
--0:3:2 Name: Faces from edges
----0:3:2:1 Name: Face generated from Edge, Evolution = GENERATED
--0:3:3 Name: Faces from vertices
-> Then another fillet on another edge is being created and written back to the TDF tree.
But this seems to work only for about 80% of the filleting operations.
In some rare cases, the internal TNaming_Selector writes a bunch of (5+) selection nodes onto the tree structure, but then proceeds to return "true" for the selection. In those cases, any later Solve()-operation will fail, since the tree part for the selections then looks more or less like this excerpt:
[...]
--------0:1:4:2:3:4 , Evolution = SELECTED
----------0:1:4:2:3:4:1 , Evolution = SELECTED
------------0:1:4:2:3:4:1:1 , Evolution = SELECTED
--------------0:1:4:2:3:4:1:1:1 , Evolution = SELECTED
--------0:1:4:2:3:5 , Evolution = SELECTED
------0:1:4:2:4 , Evolution = SELECTED
------0:1:4:2:5 , Evolution = SELECTED
--------0:1:4:2:5:1 , Evolution = SELECTED
--------0:1:4:2:5:2 , Evolution = SELECTED
----------0:1:4:2:5:2:1 , Evolution = SELECTED
------------0:1:4:2:5:2:1:1 , Evolution = SELECTED
--------------0:1:4:2:5:2:1:1:1 , Evolution = SELECTED
----------------0:1:4:2:5:2:1:1:1:1 , Evolution = SELECTED
----------0:1:4:2:5:2:2 , Evolution = SELECTED
------------0:1:4:2:5:2:2:1 , Evolution = SELECTED
--------------0:1:4:2:5:2:2:1:1 , Evolution = SELECTED
----------------0:1:4:2:5:2:2:1:1:1 , Evolution = SELECTED
----------0:1:4:2:5:2:3 , Evolution = SELECTED
----------0:1:4:2:5:2:4 , Evolution = SELECTED
--------0:1:4:2:5:3 , Evolution = SELECTED
This occurs for me on v7.5.0 and v7.6.0.
Unfortunately and despite all the tests I did, I could not find any test case which are 100% reproducible for this behavior and that would suggest where I could look for a logical error in my code and I haven't been able to make completely sense of the corresponding OCCT code.
Has anyone here already experienced something similar in the past that could perhaps give me and idea or two to what could cause this?
Thanks in advance! :)