MantisBT - Community
View Issue Details
0023119Community[OCCT] OCCT:Application Frameworkpublic2012-04-22 18:102012-11-16 13:17
Roman Lygin 
[OCCT] 6.5.2 
[OCCT] 6.5.4[OCCT] 6.5.4 
caf named_shape (002) F8 F9
0023119: TNaming_Selector::Solve() fails (changes from single face to compound of multiple faces)
The bug has been originally reported on the forum by Valeriu Catina - [^]
The below reproducer simplifies the defect appearance.

TNaming_Selector::Select() correctly computes the type as FACE. However consequent call to Solve() changes the type to COMPOUND (consisting of multiple faces, and hence invalid), and significantly changes the data stored on sub-labels. See attached screenshots.

Two versions of the reproducer are provided - one using DNaming_SelectionCommands.cxx and one using DNaming_SelectionDriver.

Reproduced on OCC 6.5.x.

Extra note: TNaming_Selector::Select() and ::Solve() creates various structures for faces fuse2_1 ... fuse2_24. Due to lack of documentation of conventions applied by Topology Naming algorithm it is impossible to conclude whether these structures are correct or not, and makes debugging and suggesting a patch virtually impossible.
source naming_test.tcl.
No tags attached.
? naming_test.tcl (1,188) 2012-04-22 18:10
png naming_after_TNaming_Selector-Select()-ok.png (105,586) 2012-04-22 18:17
png naming_after_TNaming_Selector-Solve()-fail.png (104,702) 2012-04-22 18:17
rar OCC_NamingTest.rar (13,009) 2012-08-24 17:02
? naming_test2.tcl (1,352) 2012-08-31 18:17
7z 23119.7z (40,292) 2012-09-12 14:38
Issue History
2012-04-22 18:10Roman LyginNew Issue
2012-04-22 18:10Roman LyginAssigned To => szy
2012-04-22 18:10Roman LyginFile Added: naming_test.tcl
2012-04-22 18:17Roman LyginFile Added: naming_after_TNaming_Selector-Select()-ok.png
2012-04-22 18:17Roman LyginFile Added: naming_after_TNaming_Selector-Solve()-fail.png
2012-04-24 08:34abvStatusnew => assigned
2012-08-10 18:01szyNote Added: 0021231
2012-08-14 16:08szyRelationship addedchild of 0023205
2012-08-24 17:02vcatNote Added: 0021333
2012-08-24 17:02vcatFile Added: OCC_NamingTest.rar
2012-08-31 18:14szyNote Added: 0021377
2012-08-31 18:14szyStatusassigned => resolved
2012-08-31 18:16szyNote Edited: 0021377bug_revision_view_page.php?bugnote_id=21377#r4202
2012-08-31 18:17szyFile Added: naming_test2.tcl
2012-09-05 17:48szyNote Added: 0021415
2012-09-05 17:48szyAssigned Toszy => vro
2012-09-05 17:48szyStatusresolved => assigned
2012-09-05 17:50szyStatusassigned => resolved
2012-09-06 08:20vroNote Added: 0021417
2012-09-06 08:20vroAssigned Tovro => mkv
2012-09-06 08:20vroStatusresolved => reviewed
2012-09-07 10:07bugmasterTarget Version => 6.5.4
2012-09-12 14:37szyNote Added: 0021464
2012-09-12 14:38szyFile Added: 23119.7z
2012-09-13 14:24szyNote Added: 0021476
2012-09-13 14:56mkvNote Added: 0021478
2012-09-13 14:58mkvTest case number => caf named_shape (002) F8 F9
2012-09-13 14:58mkvAssigned Tomkv => bugmaster
2012-09-13 14:58mkvStatusreviewed => tested
2012-09-17 17:29szyChangeset attached => occt master efd4b232
2012-09-17 17:33szyAssigned Tobugmaster => szy
2012-09-17 17:33szyStatustested => verified
2012-09-17 17:33szyResolutionopen => fixed
2012-11-16 13:14bugmasterFixed in Version => 6.5.4
2012-11-16 13:17bugmasterStatusverified => closed

2012-08-10 18:01   
The bug reported by Valeriu Catina is not linked with the reported one.
It concerns incorrect Naming when created shape has not Identity Location.
We have accepted this bug. It is pity that Valeriu still didn't register it in Mantis.
Concerning the current issue. For the moment it is not possible to say is it a bug or not because the attached script is not valid. It uses mixture of not compatible commands. Unfortunately Naming testing framework is still not completed. It has some intermediate state. As result it is not documented. Sorry for this. I do hope we will try to fix it till the end of the year.
I suggest you to use commands defined in DNaming_ModelingCommands.cxx file.
Used by you commands SelectGeometry and SolveSelection are obsolete and should be redesigned. I do hope we will do it in the next release.
Also I will try to find example of correct script to be used for testing temporary.
2012-08-24 17:02   
I attached a C++ coded reproducer of the present bug. The bug reported by me (Valeriu Catina) on the forum is actually identical to the present one. It shows no matter if the created shape has a identity location or not. I rechecked and therefore, the report on the forum appears to be erroneous regarding the location. All other statements seem to be correct.

I hope this clarification and the attached C++ reproducer will help out with the debugging.


Valeriu Catina
2012-08-31 18:14   
(edited on: 2012-08-31 18:16)
The issue presented in the script in 'naming_test.tcl' should be separated to several sub-problems:
1) Bugs in Draw commands (DNaming package)
2) Incorrect using of existing Draw commands
3) Naming bugs

1. Impacted commands (SelectShape & SolveSelection) from DNaming_Selection.cxx were fixed (Branch CR23119 is created). Now as SelectShape as SelectGeometry commands can be used.

2. The script is redesigned and attached for information. It provides working example of consistent using of different groups of DNaming commands.

3. The naming bug (selected Face after re-computation becomes Compound).
  This testing case (presented in the script-reproducer) can be considered as the Algorithm limitation. The solver can't distinguish the expected face from other in Compound because to much participating in re-computation shapes have modification 1 : N. Attempt to filter it by neighbors also gives compound of three faces which all satisfy filter criteria. New script 'naming_test2.tcl' should be used for correct case reproducing.

2012-09-05 17:48   
Review it, please.
2012-09-06 08:20   
2012-09-12 14:37   
Hello Valeriu,
After the provided sample analysis I can make conclusion that your testing case can be considered as the Algorithm limitation too. The solver can't distinguish the expected face from other in Compound because many shapes in the testing case have modification 1 : 2. Attempt to filter it by neighbors also gives compound of 2 faces which all satisfy the filter criteria. See also several pictures (23119.7z) illustrating the conclusion for the case when the face 'F1_selection.png' (modified from F1.png - bottom face of the box B2) was selected, where:
'F1_selection.png' - the face which was selected;
'F1.png' - the initial face from which the selected face was modified;
'F1_mod.png' - result of initial face F1 modification => 2 faces (F1 modified to two presented faces. As result solver can't distinguish them and try to apply filter by neighbors);
'F1_sel_by_nbs.PNG' - result of 'filter' work. It is also two faces. As result solver creates Compound.
2012-09-13 14:24   
For testing purpose the new scripts F8 & F9 from branch CR23119 should be used.
2012-09-13 14:56   
Dear BugMaster,
Branch CR23119 (and products from GIT master) was compiled on Linux and Windows platforms and tested.

Not detected

Not detected

Testing case:
caf named_shape (002) F8 - OK
caf named_shape (002) F9 - OK