View Issue Details

IDProjectCategoryView StatusLast Update
0029699Open CASCADEOCCT:Application Frameworkpublic2021-09-03 14:11
ReporterssvAssigned Tobugmaster  
Status closedResolutionfixed 
PlatformWindowsOSVC++ 2013 
Target Version7.6.0 
Summary0029699: Application Framework - OCAF ignores orientation of shape in TNaming
DescriptionThe programmatic scenario is given in "Steps To Reproduce" section. Here is the overview:

Imagine you store a FORWARD face in OCAF using TNaming_Builder. Then imagine you reverse this face and store it again in the same attribute. Here is a bug: OCAF ignores the attempt to store the REVERSED face and keeps storing the FORWARD one.

I can imagine that TNaming_Builder::Generated() is not probably the best way to set shapes in OCAF (is there an alternative?). On the other hand, this problem is not reproduced for shapes with different TShape pointers (that is probably why we do not have this bug in parametric modelers).
Steps To Reproduce// Take any label, where doc is TDocStd_Document.
TDF_Label aDataLab = doc->Main();

// Create just any face.
  face = BRepBuilderAPI_MakeFace( gp_Pln( gp::Origin(), gp::DZ() ) );

// Orientation is FORWARD initially.
std::cout << "Expected orientation: "
          << ( (face.Orientation() == TopAbs_FORWARD) ? "forward" : "reversed" ) << std::endl;

// Set shape.
  TNaming_Builder aNBuilder(aDataLab);

// Get shape to check its orientation.
Handle(TNaming_NamedShape) aShapeAttr;
aDataLab.FindAttribute(TNaming_NamedShape::GetID(), aShapeAttr);
face = aShapeAttr->Get();

// Orientation is forward (OK).
std::cout << "Orientation in OCAF: "
          << ( (face.Orientation() == TopAbs_FORWARD) ? "forward" : "reversed" ) << std::endl;

// Reverse shape before storing.

// Orientation is now REVERSED.
std::cout << "Expected orientation: "
          << ( (face.Orientation() == TopAbs_FORWARD) ? "forward" : "reversed" ) << std::endl;

// Set reversed shape.
  TNaming_Builder aNBuilder(aDataLab);

// Get shape to check orientation.
aDataLab.FindAttribute(TNaming_NamedShape::GetID(), aShapeAttr);
face = aShapeAttr->Get();

// BUG: Orientation is still forward, while it should be reversed (NOK).
std::cout << "Orientation in OCAF: "
          << ( (face.Orientation() == TopAbs_FORWARD) ? "forward" : "reversed" ) << std::endl;
TagsNo tags attached.
Test case number



2018-04-23 10:26

developer   ~0075594

This is known and norma behavior of the NamedShapeAttribute, since it keep all the shapes in the UsedShapes attribute, which contains the not-oriented shapes of map.
Ther naming mechanism never works with orientation of shapes and trying to make this map oriented map of shapes will casue huge number of regressions in the naming and in application that uses it.

So, I may only propose to use additional flag (or integer if FORWARD/REVERSED is not enough) attribute to keep the orientation of the shape, or create a new attribute, which will have no relation to the topological naming.


2019-09-05 04:58

manager   ~0086764

Mikhail, the described behavior is clearly inconsistent and may not be considered as normal. Please consider possible ways to fix it.


2019-09-05 09:21

developer   ~0086772

Sergey, is it help you if TDataXtd_Shape attribute (which stores the full shape only) will store the shape orientation, but not TNaming_NamedShape, which is related more to a local selection?


2019-09-05 10:34

developer   ~0086780

Mikhail, the issue is quite old and is already workarounded by deep copying a face whenever its orientation is reversed. It is up to you to decide whether and how to fix the reported inconsistency. I am sure that I had a look at TDataXtd_Shape as we did not really need the naming service. However I do not remember why it was not suitable (probably, it did not work well on undo/redo or anything else related to backup). Anyway, the issue deserves deeper investigation which I cannot conduct right now.


2021-08-18 10:41

developer   ~0103269

This is a principal idea of the topological naming algorithm, which can not be simply changed.
However it is already in TDataXtd_Shape, where the history naming structures are unused.
So, I would close this issue.


2021-08-18 10:42

developer   ~0103270

Dear Bugmaster,

No changes are needed, please, close this issue.


2021-08-30 15:37

developer   ~0103544

Dear Bugmaster, could you close this issue.

Issue History

Date Modified Username Field Change
2018-04-17 12:44 ssv New Issue
2018-04-17 12:44 ssv Assigned To => mpv
2018-04-23 10:26 mpv Note Added: 0075594
2018-04-23 10:26 mpv Status new => acknowledged
2019-09-04 18:05 kgv Summary OCAF ignores orientation of shape in TNaming => Application Framework - OCAF ignores orientation of shape in TNaming
2019-09-05 04:58 abv Note Added: 0086764
2019-09-05 04:58 abv Status acknowledged => assigned
2019-09-05 04:58 abv Target Version 7.4.0 => 7.5.0
2019-09-05 09:21 mpv Note Added: 0086772
2019-09-05 09:21 mpv Assigned To mpv => ssv
2019-09-05 09:21 mpv Status assigned => feedback
2019-09-05 10:34 ssv Note Added: 0086780
2020-09-10 19:00 ssv Target Version 7.5.0 => 7.6.0
2021-08-18 10:38 utverdov Assigned To ssv => mpv
2021-08-18 10:41 mpv Note Added: 0103269
2021-08-18 10:41 mpv Status feedback => resolved
2021-08-18 10:41 mpv Assigned To mpv => bugmaster
2021-08-18 10:42 mpv Note Added: 0103270
2021-08-30 15:37 mpv Note Added: 0103544
2021-08-30 15:46 mpv Status resolved => feedback
2021-09-03 14:11 bugmaster Status feedback => closed
2021-09-03 14:11 bugmaster Resolution open => fixed