View Issue Details

IDProjectCategoryView StatusLast Update
0025936Open CASCADEOCCT:Modeling Datapublic2023-08-01 15:06
ReporterdbvAssigned Tovpozdyayev 
PrioritynormalSeverityfeature 
Status assignedResolutionopen 
Target VersionUnscheduled 
Summary0025936: Modeling Data - reusable data structure for 2D tesselation (3- and 4-nodal mesh)
DescriptionIt is necessary to provide a data structure to store 4-nodal mesh
Additional information
and documentation updates
Possible alternatives:
1. Poly_Triangulation sub-class adding extra quads array as 4 vertex nodes (currently implemented by the patch).
   Quads should not overlap with existing triangles.
   Pros: + no alterings to existing Poly_Triangulation.
   Cons: - code unaware of Poly_Mesh will work incorrectly;
         - independent quads/triangles indexation.
2. Poly_Triangulation sub-class adding extra quads array as triangle pair indices.
   Pros: + quadrangular meshes will be transparently processed by any triangulation algorithm;
   Cons: - memory overhead for additional indices (however, it could be pretty compact for two indices);
         - independent quads/triangles indexation;
         - might be tricky implementing quad/triangle element iterator which would skip triangles defined as quads
           (if strict ordering of triangles is allowed - might be pretty compact).
3. Pre-allocated 4-nodes Element array in Poly_Triangulation (currently used by CAD Assistant).
   Poly_Triangulation may provide an interface returning Poly_Element defining either a Quad or Triangle (4th node having invalid index).
   Pros: + continuous (mixed) indexation of Triangles and Quads;
         + general API for handling Quads/Triangles without nasty down-casts;
        +- with ordering trick (quads only) it is technically possible implementing a fallback returning triangle using old API
          (via range + odd/even check).
   Cons: - memory redundancy (but via memory aliasing it is possible defining packed Triangle-only mesh without overhead);
         - for wide adoption, OCCT algorithms should be adopted to expect Quads.
4. Encode polygons implicitly in Poly_Triangulation and provide tools iterating over polygons.
   This is described in FB_ngon_encoding extension proposal to glTF 2.0
   https://github.com/KhronosGroup/glTF/pull/1620/files [^]
   https://en.wikipedia.org/wiki/Catmull%E2%80%93Clark_subdivision_surface [^]
   Pros: + no alterings to existing Poly_Triangulation;
         + no extra memory for quads.
   Cons: - no direct indexation of elements (until they are unpacked);
         - needs extra tool for packing and unpacking;
         - implicit reconstruction might create unintentional polygons (which should be valid, though).
TagsNo tags attached.
Test case number

Relationships

parent of 0032133 closedbugmaster Open CASCADE Modeling Data - Restriction of access to internal arrays for Poly_Triangulation, revision of API 
related to 0023762 closedbugmaster Open CASCADE Way of getting normals from Poly_Triangulation is inconvenient 
child of 0025476 assigneddpasukhi Open CASCADE Data Exchange - implement import of mesh data from files in PLY format 

Activities

git

2015-03-13 18:19

administrator   ~0038352

Branch CR25936 has been created by dbv.

SHA-1: 1db4014001ecb3e67ed2d98289df41604c5b00ec


Detailed log of new commits:

Author: dbv
Date: Fri Mar 13 18:19:15 2015 +0300

    Replaced all arrays in Poly_Triangulation to NCollection_Vector.
    Poly_Triangulation now does not provide access to whole arrays stored inside it. Only by one element.
    Added structure to store indexes for quad polygons.

dbv

2015-03-13 18:20

developer   ~0038354

Last edited: 2015-03-13 18:30

Dear Kirill,

please review patch in occt branch CR25936

oan

2015-03-24 15:59

developer   ~0038836

DC,

approach used for initialization of Poly_Triangulation fields can take significant time comparing to old implementation due to iterative adding of dummy values in constructor. Suppose that shape consists of few thousands faces and each triangulation contains few millions triangles. Hence, memory will be allocated by NCollection_Vector in few blocks (by default its 256 items per block). As a result, fragmented memory and expenses for allocation of separate block.

Simple test gives the following result:

const Standard_Integer aNbNodes = 20000000;
NCollection_Vector<gp_Pnt> aPnts;
for (Standard_Integer aNodeIt = 0; aNodeIt <= aNbNodes; ++aNodeIt)

{
  aPnts.Append(gp_Pnt());

}

// Elapsed time: 0 Hours 0 Minutes 1.21033318446 Seconds



NCollection_Vector header provides two approaches to enlarge vector's length:
1. Calling the method Append (val) - then "val" is added to the end of the
 vector (the vector length is incremented)

2. Calling the method SetValue (i, val) - if "i" is greater than or equal
 to the current length of the vector, the vector is enlarged to accomodate this index

Using second approach the results are as follows:
const Standard_Integer aNbNodes = 20000000;
NCollection_Vector<gp_Pnt> aPnts;
aPnts.SetValue(aNbNodes, gp_Pnt());

// Elapsed time: 0 Hours 0 Minutes 0.340926777862 Seconds


Yes, 20000000 is a huge number that whether be used, and just a second to initialize structures, but...


Additionally, I suggest to pass number of nodes as a parameter in constructor to NCollection_Vector in other places where data is copied due to the same reasons.

Using prefix "Poly_Triangulation::" for inline methods in Poly_Triangulation.hxx seems redundant.

Concerning AddQuad() method, it requires that index of first triangle should be less than second one by 1. I suppose that it is incorrect. Imagine triangle and three neighboring ones - here, indices can be 1-2, 1-3, 1-4, for instance. In general case it is not obligatory that neighboring triangles should be sequential due to different algorithms of constrains processing, for example.

One more suggestion is to implement the similar API for accessing to nodes and parameters of Poly_PolygonOnTriangulation.

kgv

2015-03-30 10:47

developer   ~0038968

+  struct Polygons
+  {
+    Standard_Integer myUsedTriangles;
+    Standard_Integer myNbQuads;
+    NCollection_Vector<Standard_Integer> myPolygonsIndexes;

please omit suffix "my" within public fields in the structure.

+  inline Standard_Integer UVNodesLowerIndex() const
+  inline Standard_Integer UVNodesUpperIndex() const
...
+  inline Standard_Integer NormalsLowerIndex() const
+  inline Standard_Integer NormalsUpperIndex() cons

the class should maintain consistency between Nodes, UVNodes and Normals.
Optional property should either has the same range or be empty.
Thus this methods should be omitted.

+  Standard_EXPORT  const  Standard_ShortReal& Normal (const Standard_Integer theIndex) const;
+  Standard_EXPORT   Standard_ShortReal& ChangeNormal (const Standard_Integer theIndex);

the method name is confusing - it is expected that normal should has 3 coordinates per node.

+  void Quad (const Standard_Integer theIndex, Standard_Integer& theFirstTriangleIndex, Standard_Integer& theSecondTriangleIndex);

why this method is not exported?

+    for (Standard_Integer anIndex = 0; anIndex < NbNodes; anIndex++)
+    {
+      myUVNodes.Append (gp_Pnt2d())

here and in other places - within NCollection_Vector it is sufficient to set the last element in the vector to force allocation of all intermediate values.

git

2015-03-30 16:04

administrator   ~0038992

Branch CR25936 has been updated by dbv.

SHA-1: a712c150399db532d6f16b41864ed67f68ba0962


Detailed log of new commits:

Author: dbv
Date: Mon Mar 30 16:03:36 2015 +0300

    Remarks fix.

dbv

2015-03-30 16:06

developer   ~0038993

Dear Kirill,

please review updates in the branch CR25936

git

2015-03-30 16:40

administrator   ~0038995

Branch CR25936 has been updated by dbv.

SHA-1: 2629cd72971833c7a35ed9887cd5f4fa9c287cb0


Detailed log of new commits:

Author: dbv
Date: Mon Mar 30 16:39:58 2015 +0300

    Remarks fix.

git

2015-03-31 14:49

administrator   ~0039034

Branch CR25936_1 has been created by dbv.

SHA-1: 5b29eda9a06f897df54b7c2cc0d1dc49fd074884


Detailed log of new commits:

Author: dbv
Date: Tue Mar 31 14:48:34 2015 +0300

    Replaced all arrays in Poly_Triangulation to NCollection_Vector.
    Poly_Triangulation now does not provide access to whole arrays stored inside it. Only by one element.
    Added structure to store indexes for quad polygons.

git

2015-03-31 15:19

administrator   ~0039037

Branch CR25936_1 has been updated by kgv.

SHA-1: 5b43cc4ecb612d22734fc1d6220a3e37670d7d00


Detailed log of new commits:

Author: kgv
Date: Tue Mar 31 15:19:25 2015 +0300

    Poly_Triangulation.hxx - cosmetics

kgv

2015-03-31 15:33

developer   ~0039039

Dear Dmitry,

I have slightly corrected the patch.

> Replaced all arrays in Poly_Triangulation to NCollection_Vector.
please define commit description in accordance with OCCT bug workflow rules.

> Poly_Triangulation now does not provide access to whole arrays stored inside it. Only by one element.
> Added structure to store indexes for quad polygons.
the description is too generous, please consider extending it.

+  NCollection_Vector<Standard_ShortReal> myNormals;
+  Standard_EXPORT   void SetNormals (const Handle(TShort_HArray1OfShortReal)& theNormals);

the data type for normals should be revised.

kgv

2015-03-31 15:34

developer   ~0039041

the patch in current state does not allow to use benefits of NCollection_Vector since there are no methods to add new nodes and triangles.

git

2015-04-03 11:08

administrator   ~0039191

Branch CR25936_1 has been updated by dbv.

SHA-1: fdb679fe1ade301d1a7b4adeaf5f57f7428faf4f


Detailed log of new commits:

Author: dbv
Date: Tue Mar 31 17:44:21 2015 +0300

    Method for adding new nodes

dbv

2015-04-03 11:10

developer   ~0039193

Returned method for adding nodes.

Please review patch in branch CR25936_1

ssv

2015-04-09 17:34

developer   ~0039517

Some notes after discussion with abv, kgv:

1. For the sake of clarity it seems better to eliminate all quad-related functionality from Poly_Triangulation. A new Poly_Mesh structure inheriting Poly_Triangulation can be introduced instead. This structure will provide all necessary API to bind triangles into polygon aggregations.

2. An iterator interface for accessing the mesh elements has to be introduced. The currently available Quad() method looks like a direct-access method, but this is not true (it loops over the stored collections). Switching to iterator interface will unmask this peculiarity and force users to iterate themselves (clearly understanding the performance overheads). Internally we will have a vector of pairs for element indices (in case on triangles only the first index is populated).

git

2015-04-29 11:39

administrator   ~0040403

Branch CR25936 has been updated forcibly by dbv.

SHA-1: 6c1f47fd0fe62716bc7e87a49e3254102b7d0d51

dbv

2015-04-29 11:43

developer   ~0040404

Patch has been updated.

Dear Sergey,

please review latest patch in occt branch CR25936 (http://git.dev.opencascade.org/gitweb/?p=occt.git;a=commitdiff;h=6c1f47fd0fe62716bc7e87a49e3254102b7d0d51)
and occt-products branch CR25936

git

2015-07-01 15:04

administrator   ~0042636

Branch CR25936 has been updated by ssv.

SHA-1: fa9fbda259b7bb4a0dcd6dde259ff7ad36ad66e4


Detailed log of new commits:

Author: ssv
Date: Wed Jul 1 15:04:26 2015 +0300

    API has been changed to be more convenient (indices of nodes are passed)

git

2015-07-02 13:27

administrator   ~0042669

Branch CR25936 has been updated by ssv.

SHA-1: f3a397c320c69604c4d295a37fa4eebc7f4e2994


Detailed log of new commits:

Author: ssv
Date: Thu Jul 2 13:27:38 2015 +0300

    Get() method of Poly_Element was made const

git

2015-07-02 14:25

administrator   ~0042672

Branch CR25936 has been updated by ssv.

SHA-1: 62317aefeebf74e20da8e79ebd0b97d7f1bdf4b9


Detailed log of new commits:

Author: ssv
Date: Thu Jul 2 14:25:30 2015 +0300

    New Element() method was added at the level of Poly_Mesh class. This method is more convenient than direct accessing of Poly_Element structures with low-level treatment of its internal triangles. Moreover, the new method encapsulates the conventional order of nodes in the pair of triangles composing a quad.

oan

2015-07-03 10:18

developer   ~0042698

Last edited: 2015-07-03 10:34

DC,

as far as internal structure of Poly_Triangulation and Poly_PolygonOnTriangulation has changed, I suggest to add duplicating API to these classes that takes NCollection_Vector-s directly instead of TColgp-s.

This can be useful in case when some points should be skipped (check for free nodes can be performed right before storing of mesh). Using TColgp array with strictly defined limits is not suitable here. In this case there is a double conversion: before passing to Poly class - NCollection_Vector => TColgp_Array, in Poly class TColgp_Array => NCollection_Vector.

Additionally, this feature will require changing of internal structure of Poly_PolygonOnTriangulation, i.e. porting to NCollection vectors too that seems correct in the light of current modifications to make implementation of Poly classes consistent algong the whole unit.

The last one also means that Poly_PolygonOnTriangulation will be declared using pure header file like it is done for Poly_Triangulation. As the result the following auxiliary classes will remain cdl-declared:
class Triangle;
class Array1OfTriangle;
class HArray1OfTriangle;
class Polygon3D;
class Polygon2D;
class Connect;

Probably it is also possible to remove cdl declarations for the Poly unit at all?

What do you think about this?

git

2015-07-09 12:07

administrator   ~0042856

Branch CR25936 has been updated by ssv.

SHA-1: 2967f26f6e392227811dac73c9d79f5f68746a96


Detailed log of new commits:

Author: ssv
Date: Thu Jul 9 12:07:18 2015 +0300

    Added one more constructor accepting Poly_Triangulation. Thus it is now possible to create Poly_Mesh around Poly_Triangulation (copy of triangulation will be prepared).

ssv

2015-07-27 10:17

developer   ~0043438

Dear oan,

Could you please review this new Poly_Mesh structure? Concerning your note, we did not affect Poly_PolygonOnTriangulation, so for me it is better to have a dedicated issue for TColgp_Array => NCollection_Vector conversion.

oan

2015-07-27 12:22

developer   ~0043457

Dear Sergey,

I have few suggestions rather than remarks. I suppose that copying of nodes (UV nodes, elements and normals) in Poly_Mesh constructor can be performed using capabilities of NCollection_Vector::Assign due to that it performs copying by memory blocks instead of copying by elements. myElements may be initialized by number of triangles in order to allocate memory block for whole range of elements instead of allocation of many blocks during copying. In order to avoid usage of copy constructors, initialization of content of myElements can be performed using myElements.SetValue(aNbTriangles, Poly_Element()) and then indices can be updated within a loop. There is no necessity to use addElement in constructor due to myNbQuads is never being changed. Suppose it can speed up a little bit an initialization stage of Poly_Mesh structure.

Additionally, please note that Standard_OutOfRange_Raise_if used in Poly_Mesh will be replaced by empty plug in release mode and here is a possibility for real access violation. This is due to No_Exception macro is defined in release build configuration.

Regarding Poly_PolygonOnTriangulation, naturally there are few changes in this class made in context of this issue and as for me it would be logical to integrate fully updated API of Poly package by a single shot. Segregating of such a minor change on a separate task can lead to that this change will probably appear in another OCCT relase than current issue. However, it is only my personal opinion.

git

2015-07-28 12:40

administrator   ~0043622

Branch CR25936 has been updated by ssv.

SHA-1: 8acdc1a772f8d9d8275d522853ae7080bd39f9c6


Detailed log of new commits:

Author: ssv
Date: Tue Jul 28 12:36:34 2015 +0300

    Added copy ctor in Poly_Triangulation, Poly_Mesh conversion ctor optimized

git

2015-08-14 17:53

administrator   ~0044322

Branch CR25936 has been updated by ssv.

SHA-1: af9ac4846bf7d8b08a45dc1c65f49ba558bfa112


Detailed log of new commits:

Author: aml
Date: Thu Aug 6 13:23:45 2015 +0300

    0026493: BRepProj_Projection failed to project a wire on a shell
    
    Cylindrical projection moved from old boolean operations to the new BOP.
    
    Test case for issue CR26493
    
    Conflicts:
        src/BRepProj/BRepProj_Projection.cxx
        tests/boolean/gdml_private/O1

Author: aml
Date: Wed Jul 29 16:14:09 2015 +0300

    026464: BRepOffset_MakeOffset does not provide valid output
    
    Handling of degenerated case improved.
    
    Test-case for issue #26464

Author: mkv
Date: Tue Aug 4 16:49:10 2015 +0300

    0026442: Access violation in BRepOffset_MakeOffset
    
    Test cases for issue CR26442

Author: aml
Date: Tue Jul 21 11:19:14 2015 +0300

    0026418: Unjustified limitation on tolerance of a input shape in BRepOffset_MakeOffset
    
    Performance improvements and regression elimination.
    Handling of degenerated case added.
    
    Update of test-case offset faces_type_a A2 according to the new behavior
    Test-case for issue #26418

Author: aml
Date: Thu Jul 9 14:12:21 2015 +0300

    0026356: Wrong result done by projection algorithm
    
    Changed internal one dimension search algorithm in case of fast changing curve.
    
    Test-case for issue #26356

Author: nbv
Date: Thu May 21 13:47:55 2015 +0300

    0026197: Incomplete intersection curve
    
    Correct the algorithm to get right Start point for extension of the walking line.
    
    Test case for issue CR26197
    
    Correction of test case bugs/modalg_6/bug26197

Author: azv
Date: Tue Jul 21 09:51:19 2015 +0300

    0026458: BRepBuilderAPI_Copy does not copy mesh structure
    
    * The possibility to copy mesh is implemented. It may be enabled by copyMesh key, by default it is disabled.
    * Poly_Triangulation::Copy() method is added
    * Poly_Mesh::Copy() method is added
    
    Conflicts:
        src/Poly/Poly_Triangulation.cxx
        src/Poly/Poly_Triangulation.hxx

git

2015-08-25 11:15

administrator   ~0044589

Branch CR25936 has been updated by ssv.

SHA-1: 91849d81a1818b2d6423169c4cd21a9d69502ad6


Detailed log of new commits:

Author: ssv
Date: Tue Aug 25 11:14:55 2015 +0300

    Fixed incorrect range in initialization of a collection of elements

git

2015-12-22 08:17

administrator   ~0049409

Branch CR25936CAF has been created by vro.

SHA-1: 7786f8f8cb47629fd363e511fb78a08bee4faf39


Detailed log of new commits:

Author: vro
Date: Tue Dec 22 08:17:07 2015 +0300

    0025936: Reusable data structure for 2D tesselation (3- and 4-nodal mesh)

vro

2015-12-22 08:26

developer   ~0049410

A new branch is created CR25936CAF. It consists of:
 - a new Ocaf attribute TDataStd_Mesh. The attribute duplicates the API of Poly_Mesh and this way it completely covers the mesh data structure. Therefore the user has access to the mesh only through the Ocaf attribute.
 - persistence: XML & binary. Also, BRepTools_ShapeSet now has a method to write and read Poly_Mesh in ASCII format (similar to Poly_Triangulation).

The branch inherits the master. Later, when CR25936 is ready for integration into master, I will review the Ocaf attribute and check again how it works (by means of the scripts caf/basic/N1 and N2).

ssv

2016-09-05 10:23

developer   ~0057452

Dear akz, please, proceed with this issue.

git

2016-09-06 13:16

administrator   ~0057508

Branch CR25936_2 has been created by akz.

SHA-1: 8dba06a38ec09584ad801687e8a7a3c692ef5ff3


Detailed log of new commits:

Author: akz
Date: Mon Sep 5 16:27:10 2016 +0300

    Rebase branch on actual master

Author: ssv
Date: Tue Aug 25 11:14:55 2015 +0300

    Fixed incorrect range in initialization of a collection of elements

Author: aml
Date: Thu Aug 6 13:23:45 2015 +0300

    0026493: BRepProj_Projection failed to project a wire on a shell
    
    Cylindrical projection moved from old boolean operations to the new BOP.
    
    Test case for issue CR26493
    
    Conflicts:
        src/BRepProj/BRepProj_Projection.cxx
        tests/boolean/gdml_private/O1

Author: azv
Date: Tue Jul 21 09:51:19 2015 +0300

    0026458: BRepBuilderAPI_Copy does not copy mesh structure
    
    * The possibility to copy mesh is implemented. It may be enabled by copyMesh key, by default it is disabled.
    * Poly_Triangulation::Copy() method is added
    * Poly_Mesh::Copy() method is added
    
    Conflicts:
        src/Poly/Poly_Triangulation.cxx
        src/Poly/Poly_Triangulation.hxx

Author: ssv
Date: Tue Jul 28 12:36:34 2015 +0300

    Added copy ctor in Poly_Triangulation, Poly_Mesh conversion ctor optimized

Author: ssv
Date: Thu Jul 9 12:07:18 2015 +0300

    Added one more constructor accepting Poly_Triangulation. Thus it is now possible to create Poly_Mesh around Poly_Triangulation (copy of triangulation will be prepared).

Author: ssv
Date: Thu Jul 2 14:25:30 2015 +0300

    New Element() method was added at the level of Poly_Mesh class. This method is more convenient than direct accessing of Poly_Element structures with low-level treatment of its internal triangles. Moreover, the new method encapsulates the conventional order of nodes in the pair of triangles composing a quad.

Author: ssv
Date: Thu Jul 2 13:27:38 2015 +0300

    Get() method of Poly_Element was made const

Author: ssv
Date: Wed Jul 1 15:04:26 2015 +0300

    API has been changed to be more convenient (indices of nodes are passed)

Author: dbv
Date: Wed Apr 15 13:40:50 2015 +0300

    0025936: Reusable data structure for 2D tesselation (3- and 4-nodal mesh)
    
    Replaced all arrays in Poly_Triangulation to NCollection_Vector.
    Poly_Triangulation now does not provide access to whole arrays stored inside it. Only by one element.
    New classes Poly_Element, Poly_Mesh.

git

2016-09-06 13:21

administrator   ~0057509

Branch CR25936CAF_2 has been created by akz.

SHA-1: 24c6bf76eb37801f0cd172665244945a818979f4


Detailed log of new commits:

Author: vro
Date: Tue Dec 22 08:17:07 2015 +0300

    0025936: Reusable data structure for 2D tesselation (3- and 4-nodal mesh)

git

2016-09-06 19:10

administrator   ~0057535

Branch CR25936_2 has been updated forcibly by akz.

SHA-1: acdc280811a947a29b4127a9cefe72d7550a0f6f

git

2016-09-06 19:11

administrator   ~0057537

Branch CR25936CAF_2 has been deleted by akz.

SHA-1: 24c6bf76eb37801f0cd172665244945a818979f4

akz

2016-09-06 19:12

developer   ~0057538

Branch CR25936_2 was rebased on actual master and ready for review.

ssv

2016-09-07 23:42

developer   ~0057579

Dear akz,

Good job. Here below are some remarks, which look critical to fix before integration:

1) Please add upgrade notes to dox/dev_guides/upgrade/upgrade.md. It is to mention that old fashion of data access via getting collection reference is not more allowed for safety reasons.

2) Why changes in BRepProj_Projection? This is irrelevant to the current CR and very dangerous inherently (to start using "new" bops instead of old proven ones). I suggest you to run unit tests locally to find such errors before certification.

3) I am not happy with conversion in IVtkOCC_ShapeMesher (near line 382). Let's use NCollection_Vector from Poly_Triangulation directly instead of re-packaging its contents to an array. Just note that tessellation is already a quite heavy stage there, so we don't want to slow it down more -\

4) IMPLEMENT_STANDARD_HANDLE macro can be removed from Poly_Mesh.cxx.

5) In QABugs_19.cxx there is a code to access a normal vector:

gp_Dir aNormal = aT->Normal( i*3 + 1 )

Here the access is coordinate-wise, while the new Normal() method of Poly_Triangulation is vector-wise. I guess, multiplication by 3 is a mistake here. Please, check if there are any other places with such problem as I could miss some.

git

2016-09-08 15:38

administrator   ~0057597

Branch CR25936_2 has been updated forcibly by akz.

SHA-1: 9fd44945c7e954ed0537db100957640c4ce1fe7e

ssv

2016-09-08 22:41

developer   ~0057619

In MeshTest_PluginCommands.cxx near the line 380 there was a check on aT->HasUVNodes(). Looks like it was removed my mistake, can you restore it?

git

2016-09-09 12:05

administrator   ~0057633

Branch CR25936_2 has been updated forcibly by akz.

SHA-1: a06632cd2ff07908d3327c013fe36f371039251c

ssv

2016-09-13 00:32

developer   ~0057715

Reviewed. Please, test.

msv

2016-09-13 10:25

developer   ~0057717

Please, consider the following small remarks:

src\HLRBRep\HLRBRep_PolyAlgo.cxx

- indentation is broken in lines 815, 835, 853, 868

src\Poly\Poly_Mesh.hxx

- comment in line 80 is not relevant to the method.

src\VrmlConverter\VrmlConverter_ShadedShape.cxx

- indentation is broken in line 160

git

2016-09-13 10:40

administrator   ~0057718

Branch CR25936_2 has been updated forcibly by akz.

SHA-1: e033491e5b79bc746e7d33be68c668025e2370fa

akz

2016-09-13 10:41

developer   ~0057719

Remarks are proceeded. Please, review

kgv

2016-09-13 10:48

developer   ~0057720

Last edited: 2016-09-13 10:51

+// Created on: 2015-12-10
+// Created by: Vlad Romashko
+// Copyright (c) 2007-2014 OPEN CASCADE SAS

dates in the header do not match each other.

+  // Progress indicator.
+  const Standard_Integer nbMeshes = Meshes.Extent();
+  //Message_ProgressSentry indicator(GetProgress(), "Meshes", 0, nbMeshes, 1);
...
+  //TODO: Uncomment these lines to activate the progress indicator
+  //(when Poly_Mesh is included into BRep_TFace).
+  //Handle(Message_ProgressIndicator) progress = GetProgress();
+  //Message_ProgressSentry PS(progress, "Meshes", 0, nbMeshes, 1);

what for this progress indicator?
These methods are static and GetProgress() is inaccessible.

+  theSource >> d; //deflection

there will be no need to add a comment if variable will have meaningful name.

+// Writes meshes (Poly_Mesh).
+void BRepTools_ShapeSet::WriteMeshes(Standard_OStream& OS,
+                                     const TColStd_IndexedMapOfTransient& Meshes,
+                                     const Standard_Boolean Compact)
...
+// Reads meshes (Poly_Mesh).
+void BRepTools_ShapeSet::ReadMeshes(Standard_IStream& IS,
+                                    TColStd_IndexedMapOfTransient& Meshes)
...
+  Handle(TDataStd_Mesh) mesh = Handle(TDataStd_Mesh)::DownCast(theTarget);
...
+  Handle(Poly_Mesh) M = new Poly_Mesh(hasUV);
...
+    if (n == 3)
+        M->AddElement(n1, n2, n3);
+    else if (n == 4)
+    {
+        theSource >> n4;
+        M->AddElement(n1, n2, n3, n4);
+    }
...
+    if (M->HasUVNodes())
+        di << "It has 2d-nodes\n";
+    if (M->HasNormals())
+        di << "It has normals\n";

why OCCT coding rules are ignored in new code (indentation, name conventions)?

+class BinMDataStd_MeshDriver : public BinMDF_ADriver

class description is missing.

+class BinMDataStd_MeshDriver;
+DEFINE_STANDARD_HANDLE(BinMDataStd_MeshDriver, BinMDF_ADriver)

forward declaration of BinMDataStd_MeshDriver is redundant.

+       BinTools::PutReal(OS, T->Node (j).X());
+       BinTools::PutReal(OS, T->Node (j).Y());
+       BinTools::PutReal(OS, T->Node (j).Z());

maybe it is redundant with compiler optimisations,
but it sounds reasonable to replace all such places with local variable pointing to Node / UV Node
instead of several array look-ups.

+  theCommands.Add ("SetMesh", 
+                   "SetMesh (DF, entry, face)",
+                   __FILE__, DDataStd_SetMesh, g);
...
+   theCommands.Add ("DumpMesh", 
+                   "DumpMesh (DF, entry)",
+                    __FILE__, DDataStd_DumpMesh, g);

it would be helpful to have a little bit better description for new commands
(even if other commands in this plugin lack description).

-    const TColgp_Array1OfPnt& aPoints = aTriangulation->Nodes();
+
+    TColgp_Array1OfPnt aPoints(1, aTriangulation->NbNodes());
+    for (Standard_Integer anI = 1; anI <= aTriangulation->NbNodes(); anI++)
+    {
+      aPoints.SetValue (anI, aTriangulation->Node(anI));
+    }

so I suppose this copying will not be fixed for this moment...

+  //! @return Standard_True if the first element index > 0 and the second index == 0.
+  Standard_Boolean IsTriangle()
+  {
+    return (myTriangles[0] > 0 && myTriangles[1] == 0);
+  }
+
+  //! @return Standard_True if the first and the second element indices > 0.
+  Standard_Boolean IsQuad()
+  {
+    return (myTriangles[0] > 0 && myTriangles[1] > 0);
+  }

const

+void Poly_Triangulation::SetNormals (const Handle(TShort_HArray1OfShortReal)& theNormals)

this method should be marked with Standard_DEPRECATED
pointing out that it implies copying (while taking a handle as argument)
and uses inconsistent data types (array of floats, not normals).

+  NCollection_Vector<Standard_ShortReal> myNormals;

why normals are still stored as array of Standard_ShortReal?

+++ b/src/TDataStd/TDataStd_Mesh.cxx
+#include <Standard_GUID.hxx>
+#include <Standard_Type.hxx>
+#include <TDataStd_Mesh.hxx>
...
+++ b/src/XmlMDataStd/XmlMDataStd_MeshDriver.cxx

class header should be first include in cxx.

+//=======================================================================
+//function : AddElement
+//purpose  : Adds element to the mesh.
+//           @param theN1 index of the first node.
+//           @param theN2 index of the second node.
+//           @param theN3 index of the third node.
+//           @param theN4 index of the fourth node.
+//           @return index of the added element.
+//=======================================================================
+Standard_Integer TDataStd_Mesh::AddElement (const Standard_Integer theN1,

methods desription is unnecessarily duplicated in TDataStd_Mesh.cxx/XmlMDataStd_MeshDriver.cxx,
which might lead to inconsistent description in future.

git

2016-09-15 16:19

administrator   ~0057826

Branch CR25936_2 has been updated forcibly by akz.

SHA-1: d359cc102ad99c3854e18c9d639f46992f04776c

akz

2016-09-15 16:21

developer   ~0057827

Dear vro, please check branch CR25936_2

git

2016-09-19 14:38

administrator   ~0057925

Branch CR25936_2 has been updated by vro.

SHA-1: 5edf160fe544c1b0b861e4b56a82940417571023


Detailed log of new commits:

Author: vro
Date: Mon Sep 19 14:38:25 2016 +0300

    Non-regression test for new OCAF attribute TDataStd_Mesh is improved a little.

msv

2016-09-19 15:32

developer   ~0057930

My remarks were considered.

mpv

2016-11-15 13:12

developer   ~0060346

My remarks are the following:

TDataStd_Mesh must be moved to TDataXtd package (and the persistence files correspondingly). As a consequence, addition of TKMath is not needed for TKLCAF. Same for TKBRep in TKXmlL

Since it contains specific API for surfacic mesh management, I guess, it is better to call it TDataXtd_SurfacicMesh or so. It seems this class can not be extended to 3D mesh support later.

upgrade.md: changes will be in 720, not 710

szy

2021-01-29 14:28

manager   ~0098514

Complete, please this bug.

git

2021-02-05 10:24

administrator   ~0098667

Branch CR25936_3 has been created by vro.

SHA-1: cfb9db8a4d135724d52ccc550d1bcb4c768b0ea3


Detailed log of new commits:

Author: vro
Date: Fri Feb 5 10:24:40 2021 +0300

    0025936: Modeling Data - reusable data structure for 2D tesselation (3- and 4-nodal mesh)
    
    // Porting of old development (for OCCT 7.1.0) to the current version of Open CASCADE.
    // All remarks are checked and fixed, regressions are fixed.
    A new test-case is added : caf basic Z1

git

2021-02-05 15:02

administrator   ~0098675

Branch CR25936_3 has been updated by vro.

SHA-1: eb9c72252f0ace6cf458bf854786b7c5bfcf0302


Detailed log of new commits:

Author: vro
Date: Fri Feb 5 15:03:45 2021 +0300

    0025936: Modeling Data - reusable data structure for 2D tesselation (3- and 4-nodal mesh)
    
    // Just forgot to add Poly_Element and Poly_Mesh files into the Git.

git

2021-02-05 18:18

administrator   ~0098686

Branch CR25936_3 has been updated by vro.

SHA-1: 2417ed2b78240fcc9db1d70dceef4d355e8d9269


Detailed log of new commits:

Author: vro
Date: Fri Feb 5 18:20:00 2021 +0300

    0025936: Modeling Data - reusable data structure for 2D tesselation (3- and 4-nodal mesh)
    
    // Fixed compilation errors in samples

git

2021-02-08 17:35

administrator   ~0098771

Branch CR25936_4 has been created by vro.

SHA-1: da4a528115cdb56ef07428cd9a1815dfc3b52ccd


Detailed log of new commits:

Author: vro
Date: Mon Feb 8 17:36:34 2021 +0300

    0025936: Modeling Data - reusable data structure for 2D tesselation (3- and 4-nodal mesh)
    
    // Recompilation of IFC external library

git

2021-02-08 17:41

administrator   ~0098773

Branch CR25936_4 has been updated by vro.

SHA-1: 5ca2e679c511ea97b239ecfcf81c5308cfa5d4eb


Detailed log of new commits:

Author: vro
Date: Mon Feb 8 17:42:30 2021 +0300

    0025936: Modeling Data - reusable data structure for 2D tesselation (3- and 4-nodal mesh)
    
    // Updated documentation

git

2021-02-08 17:46

administrator   ~0098774

Branch CR25936_4 has been updated by vro.

SHA-1: 2fb2b5dee8d41ae07404a8014a9898995040ff21


Detailed log of new commits:

Author: vro
Date: Mon Feb 8 17:47:13 2021 +0300

    0025936: Modeling Data - reusable data structure for 2D tesselation (3- and 4-nodal mesh)
    
    // Added lost files

git

2021-02-08 18:02

administrator   ~0098775

Branch CR25936_4 has been updated by vro.

SHA-1: f2384f0ca8f37db6a1eef20a7fc222003acbd563


Detailed log of new commits:

Author: vro
Date: Mon Feb 8 18:03:28 2021 +0300

    0025936: Modeling Data - reusable data structure for 2D tesselation (3- and 4-nodal mesh)
    
    // Added skipped changes in samples

git

2021-02-10 18:13

administrator   ~0098816

Branch CR25936_4 has been updated by vro.

SHA-1: b62c9889c634bcbb4eb8517f1a404b0aeac93d77


Detailed log of new commits:

Author: vro
Date: Wed Feb 10 18:13:17 2021 +0300

    0025936: Modeling Data - reusable data structure for 2D tesselation (3- and 4-nodal mesh)
    
    // NCollection_Array1 replaced NCollection_Vector in Poly_Triangulation for nodes, triangles, ...

git

2021-02-10 18:22

administrator   ~0098818

Branch CR25936_4 has been updated by vro.

SHA-1: 84bf82489726c472a6b8647bf346575f9f727eb5


Detailed log of new commits:

Author: vro
Date: Wed Feb 10 18:21:56 2021 +0300

    0025936: Modeling Data - reusable data structure for 2D tesselation (3- and 4-nodal mesh)
    
    // Poly_Quad.hxx is added instead of Poly_Element.hxx

git

2021-02-11 09:36

administrator   ~0098823

Branch CR25936_4 has been updated by vro.

SHA-1: 69f6d1ab9844271cf0555115331500abbdfac267


Detailed log of new commits:

Author: vro
Date: Thu Feb 11 09:35:59 2021 +0300

    0025936: Modeling Data - reusable data structure for 2D tesselation (3- and 4-nodal mesh)
    
    // A warning is removed about SetNormals()

git

2021-02-11 11:47

administrator   ~0098824

Branch CR25936_4 has been updated by vro.

SHA-1: c5dabc6485fb079c3fcf5dd0c88e7dfe0e26c444


Detailed log of new commits:

Author: vro
Date: Thu Feb 11 11:46:55 2021 +0300

    0025936: Modeling Data - reusable data structure for 2D tesselation (3- and 4-nodal mesh)
    
    // A keyword "override" is inserted in declaration of the method Copy() from Poly_Mesh

git

2021-02-11 14:49

administrator   ~0098828

Branch CR25936_4 has been updated by vro.

SHA-1: ebd0c54c96de1efb4380eeed19a6c6c2d6590885


Detailed log of new commits:

Author: vro
Date: Thu Feb 11 14:49:44 2021 +0300

    0025936: Modeling Data - reusable data structure for 2D tesselation (3- and 4-nodal mesh)
    
    // Implementation of Poly_PolygonOnTriangulation::Node() was skipped

git

2021-02-14 08:55

administrator   ~0098867

Branch CR25936_5 has been created by vro.

SHA-1: d289c94297380df582152e7e37c09027db2b7672


Detailed log of new commits:

Author: vro
Date: Sun Feb 14 08:55:02 2021 +0300

    0025936: Modeling Data - reusable data structure for 2D tesselation (3- and 4-nodal mesh)
    
    Extension of triangular mesh of Open CASCADE to support quadrangular elements.
    A Poly_Mesh class inherits Poly_Triangulation and manipulates quadrangles.
    A TDataXtd_SurfacicMesh OCAF attribute is added to support a new surface mesh in OCAF operations.
    
    // Porting of old development (for OCCT 7.1.0) to the current version of Open CASCADE.
    // All remarks are checked, regressions are fixed.
    // A new test-case is added : caf basic Z1

git

2021-02-14 09:08

administrator   ~0098869

Branch CR25936_5 has been updated by vro.

SHA-1: b0b103c05ce940f2bf64e3cc3623046c3b1369e1


Detailed log of new commits:

Author: vro
Date: Sun Feb 14 09:07:54 2021 +0300

    0025936: Modeling Data - reusable data structure for 2D tesselation (3- and 4-nodal mesh)
    
    // Added TDataXtd_SurfacicMesh.hxx and cxx to the git.

git

2021-02-15 14:28

administrator   ~0098875

Branch CR25936_5 has been updated by vro.

SHA-1: fd76595d64eb8b77a4a379622538ba32d6d8e1f8


Detailed log of new commits:

Author: vro
Date: Mon Feb 15 14:27:53 2021 +0300

    0025936: Modeling Data - reusable data structure for 2D tesselation (3- and 4-nodal mesh)
    
    // Fixed a twice-reverse of normals (revealed in bugs vis... tests).

git

2021-02-15 16:13

administrator   ~0098878

Branch CR25936_5 has been updated by vro.

SHA-1: 8a552e5e4843ee644be2837cedef2fa4dafe6ee8


Detailed log of new commits:

Author: vro
Date: Mon Feb 15 16:13:46 2021 +0300

    0025936: Modeling Data - reusable data structure for 2D tesselation (3- and 4-nodal mesh)
    
    // Fixed a regression in bugs vis bug30630_1 (mirrored shape)

vro

2021-02-15 18:13

developer   ~0098881

Dear Colleagues! Could you review the modifications, please? Any your remarks are welcome.

In brief,
(a) Poly_mesh is added to support quadrangular mesh in addition to triangular (Poly_Triangulation).
(b) Also, both meshes (triangular and quadrangular) don't give access to internal arrays of nodes, triangles, 2d-nodes and normals. Now the user should set the data by index.
(c) An OCAF attribute TDataXtd_SurfacicMesh is created to support Poly_Mesh for OCAF.

kgv

2021-02-15 18:48

developer   ~0098882

Last edited: 2021-02-15 18:51

Vlad, could you please split the patch into several patches (with dedicated issue registered as child of this bug) as discussed last week?

0. Change existing API (hiding internal data structures in Poly_Triangulation, changing normals array) without introduction of quad-mesh support.
1. Introduction of quad-mesh.
2. OCAF attribute.

kgv

2021-02-16 17:31

developer   ~0098901

Last edited: 2021-02-16 18:53

Current patch introduces Poly_Mesh class which is a subclass of Poly_Triangulation storing an additional array of Poly_Quad, a 4 node indices of quad element.

Such definition makes it non-transparent to existing code familiar only with Poly_Triangulation - it will just ignore these quads and display / process only triangles (if any).

As such, it sounds dangerous integrating such data structure ignored by any existing OCCT algorithm (visualization, surface/volume properties, others) without providing any fallback solution for basic functionality.
It might be tolerable, though, if we indicate the limitations and suggest this structure only as alternative representation of a shape supported by limited set of OCCT algorithms.

Other proposals have tried to provide such fallbacks - like defining Quads as indexes of existing triangles,
which would allow working with quads implicitly as with triangles by most algorithms and dealing with quads only in context, where this information is meaningful (e.g. FEA or displaying mesh edges).
However, these approaches imply additional memory overhead and have issues in defining element iterator API handling triangles only ones.

vro

2021-02-17 09:28

developer   ~0098916

It looks like both definition of a quadrangular mesh has positive and negative aspects. Current implementation of Poly_Mesh introduces an array of quadrangles (indeed, an array of an integer - the 4th node for each quadrangle in addition to 3 nodes from Poly_Triangulation). It looks as a natural extension of Poly_Triangulation. What concerns the existing algorithms of Open CASCADE - it is up to us to extend them and use a quadrangular mesh in addition to triangular, where it is needed.

On the other hand, a quadrangle represented through two triangles is widely used in different scientific solvers, as you noticed.

Could we use both definition of a quadrangular mesh? We might rename Poly_Mesh to Poly_Quads, and implement a new class Poly_FEAQuads, for example. What do you think?

kgv

2021-02-19 15:26

developer   ~0098983

Issue History

Date Modified Username Field Change
2015-03-13 18:04 dbv New Issue
2015-03-13 18:04 dbv Assigned To => dbv
2015-03-13 18:05 dbv Status new => assigned
2015-03-13 18:05 dbv Relationship added child of 0025476
2015-03-13 18:19 git Note Added: 0038352
2015-03-13 18:20 dbv Note Added: 0038354
2015-03-13 18:20 dbv Assigned To dbv => abv
2015-03-13 18:20 dbv Status assigned => resolved
2015-03-13 18:20 dbv Steps to Reproduce Updated
2015-03-13 18:30 dbv Note Edited: 0038354
2015-03-13 18:30 dbv Assigned To abv => kgv
2015-03-24 15:59 oan Note Added: 0038836
2015-03-25 10:22 oan Status resolved => feedback
2015-03-30 10:47 kgv Note Added: 0038968
2015-03-30 10:47 kgv Assigned To kgv => dbv
2015-03-30 10:47 kgv Status feedback => assigned
2015-03-30 16:04 git Note Added: 0038992
2015-03-30 16:06 dbv Note Added: 0038993
2015-03-30 16:06 dbv Assigned To dbv => kgv
2015-03-30 16:06 dbv Status assigned => resolved
2015-03-30 16:40 git Note Added: 0038995
2015-03-31 14:49 git Note Added: 0039034
2015-03-31 15:19 git Note Added: 0039037
2015-03-31 15:33 kgv Note Added: 0039039
2015-03-31 15:33 kgv Assigned To kgv => dbv
2015-03-31 15:33 kgv Status resolved => assigned
2015-03-31 15:34 kgv Note Added: 0039041
2015-04-03 11:08 git Note Added: 0039191
2015-04-03 11:10 dbv Note Added: 0039193
2015-04-03 11:10 dbv Assigned To dbv => kgv
2015-04-03 11:10 dbv Status assigned => resolved
2015-04-03 13:13 abv Assigned To kgv => ssv
2015-04-09 17:34 ssv Note Added: 0039517
2015-04-13 14:34 abv Target Version 6.9.0 => 7.1.0
2015-04-29 11:39 git Note Added: 0040403
2015-04-29 11:43 dbv Note Added: 0040404
2015-07-01 15:04 git Note Added: 0042636
2015-07-02 13:27 git Note Added: 0042669
2015-07-02 14:25 git Note Added: 0042672
2015-07-03 10:18 oan Note Added: 0042698
2015-07-03 10:18 oan Status resolved => feedback
2015-07-03 10:25 oan Note Edited: 0042698
2015-07-03 10:34 oan Note Edited: 0042698
2015-07-09 12:07 git Note Added: 0042856
2015-07-27 10:17 ssv Note Added: 0043438
2015-07-27 10:17 ssv Assigned To ssv => oan
2015-07-27 10:17 ssv Status feedback => resolved
2015-07-27 12:22 oan Note Added: 0043457
2015-07-27 12:22 oan Assigned To oan => ssv
2015-07-27 12:22 oan Status resolved => assigned
2015-07-28 12:40 git Note Added: 0043622
2015-08-14 17:53 git Note Added: 0044322
2015-08-25 11:15 git Note Added: 0044589
2015-12-22 08:17 git Note Added: 0049409
2015-12-22 08:26 vro Note Added: 0049410
2016-09-05 10:23 ssv Note Added: 0057452
2016-09-05 10:23 ssv Assigned To ssv => akz
2016-09-06 13:16 git Note Added: 0057508
2016-09-06 13:21 git Note Added: 0057509
2016-09-06 13:30 akz Assigned To akz => ssv
2016-09-06 19:10 git Note Added: 0057535
2016-09-06 19:11 git Note Added: 0057537
2016-09-06 19:12 akz Note Added: 0057538
2016-09-07 23:42 ssv Note Added: 0057579
2016-09-07 23:42 ssv Assigned To ssv => akz
2016-09-08 15:38 git Note Added: 0057597
2016-09-08 15:38 akz Assigned To akz => ssv
2016-09-08 22:41 ssv Note Added: 0057619
2016-09-08 22:41 ssv Assigned To ssv => akz
2016-09-09 12:05 git Note Added: 0057633
2016-09-09 12:06 akz Assigned To akz => ssv
2016-09-13 00:32 ssv Note Added: 0057715
2016-09-13 00:32 ssv Assigned To ssv => bugmaster
2016-09-13 00:32 ssv Status assigned => resolved
2016-09-13 00:33 ssv Status resolved => reviewed
2016-09-13 10:25 msv Note Added: 0057717
2016-09-13 10:25 msv Assigned To bugmaster => akz
2016-09-13 10:25 msv Status reviewed => assigned
2016-09-13 10:40 git Note Added: 0057718
2016-09-13 10:41 akz Note Added: 0057719
2016-09-13 10:41 akz Assigned To akz => msv
2016-09-13 10:41 akz Status assigned => resolved
2016-09-13 10:48 kgv Note Added: 0057720
2016-09-13 10:50 kgv Note Edited: 0057720
2016-09-13 10:51 kgv Note Edited: 0057720
2016-09-15 16:19 git Note Added: 0057826
2016-09-15 16:21 akz Note Added: 0057827
2016-09-15 16:21 akz Assigned To msv => vro
2016-09-15 16:21 akz Status resolved => assigned
2016-09-19 14:38 git Note Added: 0057925
2016-09-19 15:13 vro Assigned To vro => dbv
2016-09-19 15:14 vro Assigned To dbv => msv
2016-09-19 15:32 msv Assigned To msv => kgv
2016-09-19 15:32 msv Note Added: 0057930
2016-09-23 18:15 kgv Assigned To kgv => abv
2016-10-26 18:17 gka Target Version 7.1.0 => 7.2.0
2016-11-01 10:14 kgv Relationship added related to 0023762
2016-11-02 13:57 akz Assigned To abv => akz
2016-11-15 13:12 mpv Note Added: 0060346
2017-07-27 10:38 abv Target Version 7.2.0 => 7.4.0
2019-09-04 12:58 abv Target Version 7.4.0 => 7.5.0
2020-09-17 20:26 gka Assigned To akz =>
2020-09-17 20:26 gka Target Version 7.5.0 => 7.6.0
2020-11-18 11:41 kgv Severity minor => feature
2020-11-18 11:41 kgv Category OCCT:Data Exchange => OCCT:Modeling Data
2020-11-18 11:41 kgv Summary Reusable data structure for 2D tesselation (3- and 4-nodal mesh) => Modeling Data - reusable data structure for 2D tesselation (3- and 4-nodal mesh)
2021-01-29 14:28 szy Note Added: 0098514
2021-01-29 14:28 szy Assigned To => vro
2021-02-05 10:24 git Note Added: 0098667
2021-02-05 15:02 git Note Added: 0098675
2021-02-05 18:18 git Note Added: 0098686
2021-02-08 17:35 git Note Added: 0098771
2021-02-08 17:41 git Note Added: 0098773
2021-02-08 17:46 git Note Added: 0098774
2021-02-08 18:02 git Note Added: 0098775
2021-02-10 18:13 git Note Added: 0098816
2021-02-10 18:22 git Note Added: 0098818
2021-02-11 09:36 git Note Added: 0098823
2021-02-11 11:47 git Note Added: 0098824
2021-02-11 14:49 git Note Added: 0098828
2021-02-14 08:55 git Note Added: 0098867
2021-02-14 09:08 git Note Added: 0098869
2021-02-15 14:28 git Note Added: 0098875
2021-02-15 16:13 git Note Added: 0098878
2021-02-15 18:13 vro Note Added: 0098881
2021-02-15 18:13 vro Assigned To vro => kgv
2021-02-15 18:13 vro Status assigned => resolved
2021-02-15 18:13 vro Steps to Reproduce Updated
2021-02-15 18:46 kgv Steps to Reproduce Updated
2021-02-15 18:48 kgv Note Added: 0098882
2021-02-15 18:48 kgv Assigned To kgv => vro
2021-02-15 18:48 kgv Status resolved => assigned
2021-02-15 18:50 kgv Note Edited: 0098882
2021-02-15 18:51 kgv Note Edited: 0098882
2021-02-16 13:07 vro Relationship added parent of 0032133
2021-02-16 17:31 kgv Note Added: 0098901
2021-02-16 18:53 kgv Note Edited: 0098901
2021-02-16 18:55 kgv Additional Information Updated
2021-02-17 09:28 vro Note Added: 0098916
2021-02-19 15:26 kgv Note Added: 0098983
2021-03-01 10:46 vro Assigned To vro => kgv
2021-08-29 19:12 msv Target Version 7.6.0 => 7.7.0
2022-10-19 15:50 smoskvin Assigned To kgv => vpozdyayev
2022-10-24 10:43 szy Target Version 7.7.0 => 7.8.0
2023-08-01 15:06 dpasukhi Target Version 7.8.0 => Unscheduled