MantisBT
Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0025936Open CASCADE[OCCT] OCCT:Data Exchangepublic2015-03-13 18:042017-07-27 10:38
Reporterdbv 
Assigned Toakz 
PrioritynormalSeverityminor 
StatusassignedResolutionopen 
PlatformOSOS Version
Product Version 
Target Version[OCCT] 7.4.0*Fixed in Version 
Summary0025936: Reusable data structure for 2D tesselation (3- and 4-nodal mesh)
DescriptionIt is necessary to provide a data structure to store 4-nodal mesh
Steps To ReproduceNot required
TagsNo tags attached.
Test case number
Attached Files

- Relationships
related to 0023762newabv Open CASCADE Way of getting normals from Poly_Triangulation is inconvenient 
child of 0025476assignedkgv Open CASCADE Data Exchange - implement import of mesh data from files in PLY format 

-  Notes
(0038352)
git (administrator)
2015-03-13 18:19

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.
(0038354)
dbv (developer)
2015-03-13 18:20
edited on: 2015-03-13 18:30

Dear Kirill,

please review patch in occt branch CR25936

(0038836)
oan (developer)
2015-03-24 15:59

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.
(0038968)
kgv (developer)
2015-03-30 10:47

+  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.
(0038992)
git (administrator)
2015-03-30 16:04

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.

(0038993)
dbv (developer)
2015-03-30 16:06

Dear Kirill,

please review updates in the branch CR25936
(0038995)
git (administrator)
2015-03-30 16:40

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.

(0039034)
git (administrator)
2015-03-31 14:49

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.
(0039037)
git (administrator)
2015-03-31 15:19

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

(0039039)
kgv (developer)
2015-03-31 15:33

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.
(0039041)
kgv (developer)
2015-03-31 15:34

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.
(0039191)
git (administrator)
2015-04-03 11:08

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

(0039193)
dbv (developer)
2015-04-03 11:10

Returned method for adding nodes.

Please review patch in branch CR25936_1
(0039517)
ssv (developer)
2015-04-09 17:34

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).
(0040403)
git (administrator)
2015-04-29 11:39

Branch CR25936 has been updated forcibly by dbv.

SHA-1: 6c1f47fd0fe62716bc7e87a49e3254102b7d0d51
(0040404)
dbv (developer)
2015-04-29 11:43

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
(0042636)
git (administrator)
2015-07-01 15:04

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)

(0042669)
git (administrator)
2015-07-02 13:27

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

(0042672)
git (administrator)
2015-07-02 14:25

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.

(0042698)
oan (developer)
2015-07-03 10:18
edited on: 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?

(0042856)
git (administrator)
2015-07-09 12:07

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).

(0043438)
ssv (developer)
2015-07-27 10:17

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.
(0043457)
oan (developer)
2015-07-27 12:22

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.
(0043622)
git (administrator)
2015-07-28 12:40

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

(0044322)
git (administrator)
2015-08-14 17:53

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

(0044589)
git (administrator)
2015-08-25 11:15

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

(0049409)
git (administrator)
2015-12-22 08:17

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)
(0049410)
vro (developer)
2015-12-22 08:26

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).
(0057452)
ssv (developer)
2016-09-05 10:23

Dear akz, please, proceed with this issue.
(0057508)
git (administrator)
2016-09-06 13:16

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.
(0057509)
git (administrator)
2016-09-06 13:21

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)
(0057535)
git (administrator)
2016-09-06 19:10

Branch CR25936_2 has been updated forcibly by akz.

SHA-1: acdc280811a947a29b4127a9cefe72d7550a0f6f
(0057537)
git (administrator)
2016-09-06 19:11

Branch CR25936CAF_2 has been deleted by akz.

SHA-1: 24c6bf76eb37801f0cd172665244945a818979f4
(0057538)
akz (developer)
2016-09-06 19:12

Branch CR25936_2 was rebased on actual master and ready for review.
(0057579)
ssv (developer)
2016-09-07 23:42

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.
(0057597)
git (administrator)
2016-09-08 15:38

Branch CR25936_2 has been updated forcibly by akz.

SHA-1: 9fd44945c7e954ed0537db100957640c4ce1fe7e
(0057619)
ssv (developer)
2016-09-08 22:41

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?
(0057633)
git (administrator)
2016-09-09 12:05

Branch CR25936_2 has been updated forcibly by akz.

SHA-1: a06632cd2ff07908d3327c013fe36f371039251c
(0057715)
ssv (developer)
2016-09-13 00:32

Reviewed. Please, test.
(0057717)
msv (developer)
2016-09-13 10:25

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
(0057718)
git (administrator)
2016-09-13 10:40

Branch CR25936_2 has been updated forcibly by akz.

SHA-1: e033491e5b79bc746e7d33be68c668025e2370fa
(0057719)
akz (developer)
2016-09-13 10:41

Remarks are proceeded. Please, review
(0057720)
kgv (developer)
2016-09-13 10:48
edited on: 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.

(0057826)
git (administrator)
2016-09-15 16:19

Branch CR25936_2 has been updated forcibly by akz.

SHA-1: d359cc102ad99c3854e18c9d639f46992f04776c
(0057827)
akz (developer)
2016-09-15 16:21

Dear vro, please check branch CR25936_2
(0057925)
git (administrator)
2016-09-19 14:38

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.

(0057930)
msv (developer)
2016-09-19 15:32

My remarks were considered.
(0060346)
mpv (developer)
2016-11-15 13:12

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

- 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 View Revisions
2015-03-13 18:30 dbv Note Edited: 0038354 View Revisions
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-06 13:56 abv Relationship added related to 0026007
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 View Revisions
2015-07-03 10:34 oan Note Edited: 0042698 View Revisions
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 13:32 akz Note Added: 0057510
2016-09-06 19:07 akz Note Deleted: 0057510
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 View Revisions
2016-09-13 10:51 kgv Note Edited: 0057720 View Revisions
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*


Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker