Fri, 03/30/2012 - 18:25
Hello,
please consider the naming structure below:
* 0:1:1:1 - Box_1
---- 0:1:1:1:1 - Box_1: bottom face
---- 0:1:1:1:2 - Box_1: top face
---- 0:1:1:1:3 - Box_1: left face
---- 0:1:1:1:4 - Box_1: right face
---- 0:1:1:1:5 - Box_1: front face
---- 0:1:1:1:6 - Box_1: back face
* 0:1:1:2 - Box_2
---- 0:1:1:2:1 - Box_2: bottom face
---- 0:1:1:2:2 - Box_2: top face
---- 0:1:1:2:3 - Box_2: left face
---- 0:1:1:2:4 - Box_2: right face
---- 0:1:1:2:5 - Box_2: front face
---- 0:1:1:2:6 - Box_2: back face
* 0:1:1:3 - Box_3
---- 0:1:1:3:1 - Box_3: bottom face
---- 0:1:1:3:2 - Box_3: top face
---- 0:1:1:3:3 - Box_3: left face
---- 0:1:1:3:4 - Box_3: right face
---- 0:1:1:3:5 - Box_3: front face
---- 0:1:1:3:6 - Box_3: back face
* 0:1:1:4 - Body_1 = Fuse(Box_1,Box_2)
--- 0:1:1:4:1 - modif. faces via BRepAPI::Modified(from faces of Box_1 and from faces of Box_2)
* 0:1:1:5 - Body_2 = Fuse(Body_1,Box_3)
--- 0:1:1:5:1 - modif. faces via BRepAPI::Modified(from faces of Body_1 and from faces of Box_3)
The boxes are:
TopoDS_Shape Box_1 = BRepPrimAPI(gp_Pnt(-170/2,-200/2,-350/2), gp_Pnt(170/2,200/2,350/2));
TopoDS_Shape Box_2 = BRepPrimAPI(gp_Pnt(-330/2,-330/2,-90/2), gp_Pnt(330/2,330/2,90/2));
TopoDS_Shape Box_3 = BRepPrimAPI(gp_Pnt(-80/2, -480/2,-180/2), gp_Pnt(80/2, 480/2,180/2));
Now we select all faces of Body_2 using TNaming_Selector and imediately call TNaming_Selector::Solve
* 0:1:1:6:1 - sel1.Select(Body2:face_1, Body_2); sel1.Solve(vLabels); NS1 = sel1.NamedShape();
* 0:1:1:6:2 - sel2.Select(Body2:face_2, Body_2); sel2.Solve(vLabels); NS2 = sel2.NamedShape();
....
* 0:1:1:6:30 - sel30.Select(Body2:face_30,Body_2); sel30.Solve(vLabels); NS30 = sel30.NamedShape();
vLabels is of type TDF_LabelMap and it contains all 25 labels used at the naming of Box_1, Box_2, Body_1 and Body_2 (see above).
TNaming_Selector::Select and TNaming_Selector::Solve succeed but TNaming_Selector::NamedShape returns, for 4 of the selected faces, a shape of type TopAbs_COMPOUND instead of TopAbs_FACE (used in selection). Without calling TNaming_Selector::Solve the named shape contains the correct type, however TNaming_Selector::Solve will later fail.
The naming structure above complies to the requirements from OCAF User's Guide, therefore I tend to believe this is a bug.
The attached screenshot shows one of the faces (highlighted with green) for which the selection followed by solving exhibits the aforementioned behavior.
Best regards,
V. Catina
Mon, 04/02/2012 - 17:34
Dear Valeriu,
Once again the specified problem (shape type change) is not reproduced.
We have created boxes exactly with your parameters and sequentially fused them.
Naming works correctly. The problem is located in your code.
See kept OCAF document in .std format (NamingOf3Boxes.std).
Starting from label 0:1:5 consequentially are kept all selected faces.
For Selection Object at 0:1:5 the face is located label 0:1:5:1:2.
And similar for other selection objets x:x:x - x:x:x:1:2.
Regards
Mon, 04/02/2012 - 21:40
Dear Forum Supervisor,
thank you for looking into this issue, once again. However, as the OCAF browser is not available anymore in DRAW (OCC 6.5.2), I cannot see the file's structure. Thus, the file is useless to me.
Best regards,
V. Catina
Tue, 04/03/2012 - 10:57
Dear Valeriu,
1)I hope OCAF Browser will be available in next version of OCCT (6.5.3).
2)Data structure of the document you can easy check navigating the specified labels (using TDF_ChildIterator) of the mentioned document.
The resulting shape contains 30 faces. As I already specified the initial label containing selection Object is 0:1:5. The last one - 0:1:34. Named Shape attribute containing a face is located at sub-label
x:x:x:1:2 of each label of Selection object. You can easy find NS attribute on these labels, extract TopoDS_Shape and check its type.
Regards
Tue, 04/03/2012 - 16:54
Dear Forum Supervisor,
thanks again for spending time on this issue. I suppose you performed the tests in DRAW. I also assume DRAW uses the DNaming module for topological naming. As one can figure out, many commands from the DNaming module aren't documented in the DRAW manual. However, it's not very hard to figure out their syntax by inspecting the source code (DNaming). Therefore, I'll try to test the 3 boxes case in DRAW and let you know the outcome.
Best regards,
Valeriu
Tue, 04/03/2012 - 17:51
Dear Valeriu,
Be sure that Naming component works properly with such trivial solid objects as box.
It is proved as by wide set of local tests as by work of several industrial applications.
Concerning DNaming commands. In fact you try to use not documented features of OCAF component.
When the process of OCAF component update will be finished you will be informed (as usual) and
I hope to have fully consistent documentation at the final step. Besides take into account, please
that for successful work with Naming component it is necessary sufficiently more wide knowledge
than correct syntax of Draw commands.
In the meantime if the problem is critical for you, you may contact us via the Contact Form http://www.opencascade.org/about/contacts/. We will try to find a solution/workaround acceptable for you.
Training and e-learning courses are also at your disposal - http://www.opencascade.org/support/training/.
Regards
Tue, 04/03/2012 - 21:14
Dear Forum Supervisor,
the selection alone works just fine for me too. The problem shows after calling TNaming_Selector::Solve - the type of 4 of the selected faces changes into a TopAbs_COMPOUND composed of 2 faces.
Regards,
Valeriu
Wed, 04/04/2012 - 03:57
Hello,
Just in addition to my previous post: where does one acquire the necessary "wide" knowledge you mention? I suppose not from the OCAF manual. What are the requirements of the naming mechanism? What do TNaming_Selector::Select and TNaming_Selector::Solve expect? What is a "correct" naming structure? Is OpenCascade "Open Source" or just "Open Code"?
Best regards,
Valeriu
Wed, 04/04/2012 - 13:01
Dear Valeriu,
Certainly the amount of knowledge and the speed it is acquired with depend on the way you study.
If you prefer studying on your own, the learning speed might be not the same compared to one provided by our professional training and support programs.
Please also do not expect us to provide on this Forum the level of technical consulting comparable to our professional support - clearly we do not want to harm our own business ;-)
Nevertheless I gave you some hints (including saved OCAF Document with correct data structure of your case) which, together with the following available guides:
1.Application Framework White paper
2.Application Framework User’s Guide
3.Application Framework Function Mechanism User’s Guide
should, in my humble opinion, allow you to find the solution yourself.
If you will decide that you can benefit from our services just contact us via the Contact Form http://www.opencascade.org/about/contacts/.
We will try to propose you the service best suited for your needs.
Regards
Wed, 04/04/2012 - 19:22
Dear Forum supervisor,
a more thoroughly inspection of the file you attached to a previous post (NamingOf3Boxes.std) reveals the following:
- each box is created at the default location and later translated. Let's call the boxes: Box_1, Box_2, Box_3
- Box_1 is fused with Box_2
- the result of Fuse(Box_1,Box_2) is fused with Box_3
If my code performs exactly the steps above - TNaming works perfectly. Now, if the boxes are created, from the beginning, at the right location (no subsequent translation) - TNaming::Select works but after calling TNaming::Solve four of the selected faces turn into compounds. You most surely needed the translation because DNaming::AddBox command in DRAW creates a box between (0,0,0) and (DX,DY,DZ) points. I can see the naming of the boxes and the FUSE results follows the guidelines in OCAF manual (also seen in the DNaming package).
I attached, to this post, my 3 boxes as BREP files. Could you please try to fuse them as you did until now, then select all faces and call TNaming_Selector::Solve on all selections? The boxes are already created at the right location, therefore no translation is needed. I'm sure the bug will show itself since my document respects exactly the same structure as yours except the box translations.
Best regards,
Valeriu
Thu, 04/05/2012 - 15:39
Dear Valeriu,
FYI.
OCAF browser (tcl based) is rehabilitated in OCCT 6.5.3 and can be tested on OCCT 6.5.3 beta version announced yesterday ( http://www.opencascade.org/org/forum/thread_23097/ ).
Concerning the posted issue.
You can use the mentioned workaround and translate a corresponding box into a specified position. As you have already confirmed it works perfectly.
Also you may register the issue in Mantis BugTracker which is available now via the Collaborative portal - http://dev.opencascade.org/index.php?q=home/get_involved.
It will be analyzed and resolved in accordance with our standard procedure. And you will be able to track the progress.
Regards
Thu, 04/05/2012 - 16:30
Dear FS,
I successfully built OCC 6.5.3 beta. However, in DRAW:
pload ALL
Open D:/Test.std doc1
DFBrowse doc1
I get "invalid command name dftree". The old DFBrowser does not exist either.
Regards,
V. Catina
Thu, 04/05/2012 - 17:46
Dear Valeriu,
Probably it is a bug of OCCT6.5.3 beta.
Temporary you can use the next workaround.
Before call of command make the next step:
>> source src\\DrawResources\\dftree.tcl
>>
>> DFBrowse doc1
## tcl Browser window should appear (see the picture DFB1.jpg).
Click at the upper left corner of the Browser window pointed out by the arrow.
Document tree will be opened similar like on the the picture DFB2.jpg)
Regards
Thu, 04/05/2012 - 18:24
Thank you, it works now!
Valeriu
Sun, 04/22/2012 - 18:22
The bug is reproduced regardless of the translation - see http://tracker.dev.opencascade.org/view.php?id=23119
Mon, 04/23/2012 - 04:43
Hello Roman,
I'm happy you were able to reproduce/confirm this problem! The "Forum Supervisor" almost got me believing the mistake was in may code :)
Best regards,
V. Catina
Mon, 04/23/2012 - 23:53
Hello Valeriu,
The bad news is that this appears to be a sighting, i.e. a bug which may or may not be reproduced. As far as I could understand this depends on how TNaming_NamedShapes (arguments of TNaming_Name) get ordered in the 0:2:11 sub-labels. Given that there are maps (not indexed maps) often used, there is no determinism and perhaps this drives changing behavior.
Hope this will help OCC team to root-cause and fix the issue.
Roman
Tue, 04/24/2012 - 01:14
Hello Roman,
at least for the specific case of three boxes sequentially fused, this bug always shows up (for me) on both Windows (OCC 6.5.2, OCC 6.5.3 beta, VS 2008) and Linux (OCC 6.5.2, OCE 0.9.1, gcc 4.6).
Best regards,
Valeriu
Tue, 04/24/2012 - 11:23
Dear Roman,
The bug identified by Valeriu and the one posted by you at http://tracker.dev.opencascade.org/view.php?id=23119 are not the same. The case when a primary element (for example - Face) changes its type to a Compound of entities of the same type means that the Solver can't distinguish between these entities and puts them in the Compound. This can be caused by various reasons.
Best Regards
Tue, 04/24/2012 - 11:43
Dear Forum supervisor:
So? That's the point of the bug - it looks like the face which stems from several iterations of modifications (face#11 in the resulting fuse2) cannot be re-identified ('re-solved') during consequent calls to TNaming_Solver::Solve(). Upon the first call to TNaming_Solver::Select() the solver puts this face and creates two sublabels - one of GENERATION name type and the other of FILTERBYNEIGHBOURGS (note the misspell by the way).
Upon further calls to ::Solve() the solver cannot distinguish that face anymore and always adds a few of its neighbors - they are generated from TNaming_Name's arguments of the GENERATION sublabel and have connection to all arguments in FILTERBYNEIGHBOURGS label.
There is another face (face#19) which has similar configuration and exhibits the same problem.
So my worst assumption is that this case reveals some fundamental limitation of the naming algorithm, though I definitively could be wrong.
Another face #10 looks somewhat similar, its GENERATION label also reconstructs the compound but for some (unclear to me) reason when working on FILTERBYNEGHBOURGS label other adjacent faces appear not connected to the arguments at that label.
Hope this gives some clues for the bug owner.
Roman