View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0025936 | Open CASCADE | OCCT:Modeling Data | public | 2015-03-13 18:04 | 2023-08-01 15:06 |
| Reporter | Assigned To | ||||
| Priority | normal | Severity | feature | ||
| Status | assigned | Resolution | open | ||
| Target Version | Unscheduled | ||||
| Summary | 0025936: Modeling Data - reusable data structure for 2D tesselation (3- and 4-nodal mesh) | ||||
| Description | It 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). | ||||
| Tags | No tags attached. | ||||
| Test case number | |||||
| parent of | 0032133 | closed | bugmaster | Open CASCADE | Modeling Data - Restriction of access to internal arrays for Poly_Triangulation, revision of API |
| related to | 0023762 | closed | bugmaster | Open CASCADE | Way of getting normals from Poly_Triangulation is inconvenient |
| child of | 0025476 | assigned | Open CASCADE | Data Exchange - implement import of mesh data from files in PLY format |
|
|
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. |
|
|
Dear Kirill, please review patch in occt branch CR25936 |
|
|
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. |
|
|
+ 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. |
|
|
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. |
|
|
Dear Kirill, please review updates in the branch CR25936 |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
Returned method for adding nodes. Please review patch in branch CR25936_1 |
|
|
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). |
|
|
Branch CR25936 has been updated forcibly by dbv. SHA-1: 6c1f47fd0fe62716bc7e87a49e3254102b7d0d51 |
|
|
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 |
|
|
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) |
|
|
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 |
|
|
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. |
|
|
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? |
|
|
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). |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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) |
|
|
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). |
|
|
Dear akz, please, proceed with this issue. |
|
|
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. |
|
|
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) |
|
|
Branch CR25936_2 has been updated forcibly by akz. SHA-1: acdc280811a947a29b4127a9cefe72d7550a0f6f |
|
|
Branch CR25936CAF_2 has been deleted by akz. SHA-1: 24c6bf76eb37801f0cd172665244945a818979f4 |
|
|
Branch CR25936_2 was rebased on actual master and ready for review. |
|
|
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. |
|
|
Branch CR25936_2 has been updated forcibly by akz. SHA-1: 9fd44945c7e954ed0537db100957640c4ce1fe7e |
|
|
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? |
|
|
Branch CR25936_2 has been updated forcibly by akz. SHA-1: a06632cd2ff07908d3327c013fe36f371039251c |
|
|
Reviewed. Please, test. |
|
|
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 |
|
|
Branch CR25936_2 has been updated forcibly by akz. SHA-1: e033491e5b79bc746e7d33be68c668025e2370fa |
|
|
Remarks are proceeded. Please, review |
|
|
+// 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. |
|
|
Branch CR25936_2 has been updated forcibly by akz. SHA-1: d359cc102ad99c3854e18c9d639f46992f04776c |
|
|
Dear vro, please check branch CR25936_2 |
|
|
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. |
|
|
My remarks were considered. |
|
|
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 |
|
|
Complete, please this bug. |
|
|
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 |
|
|
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. |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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, ... |
|
|
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 |
|
|
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() |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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. |
|
|
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). |
|
|
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) |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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? |
|
|
|
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-03-13 18:04 |
|
New Issue | |
| 2015-03-13 18:04 |
|
Assigned To | => dbv |
| 2015-03-13 18:05 |
|
Status | new => assigned |
| 2015-03-13 18:05 |
|
Relationship added | child of 0025476 |
| 2015-03-13 18:19 | git | Note Added: 0038352 | |
| 2015-03-13 18:20 |
|
Note Added: 0038354 | |
| 2015-03-13 18:20 |
|
Assigned To | dbv => abv |
| 2015-03-13 18:20 |
|
Status | assigned => resolved |
| 2015-03-13 18:20 |
|
Steps to Reproduce Updated | |
| 2015-03-13 18:30 |
|
Note Edited: 0038354 | |
| 2015-03-13 18:30 |
|
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 |
|
Note Added: 0038993 | |
| 2015-03-30 16:06 |
|
Assigned To | dbv => kgv |
| 2015-03-30 16:06 |
|
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 |
|
Note Added: 0039193 | |
| 2015-04-03 11:10 |
|
Assigned To | dbv => kgv |
| 2015-04-03 11:10 |
|
Status | assigned => resolved |
| 2015-04-03 13:13 |
|
Assigned To | kgv => ssv |
| 2015-04-09 17:34 |
|
Note Added: 0039517 | |
| 2015-04-13 14:34 |
|
Target Version | 6.9.0 => 7.1.0 |
| 2015-04-29 11:39 | git | Note Added: 0040403 | |
| 2015-04-29 11:43 |
|
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 |
|
Note Added: 0043438 | |
| 2015-07-27 10:17 |
|
Assigned To | ssv => oan |
| 2015-07-27 10:17 |
|
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 |
|
Note Added: 0057452 | |
| 2016-09-05 10:23 |
|
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 |
|
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 |
|
Note Added: 0057538 | |
| 2016-09-07 23:42 |
|
Note Added: 0057579 | |
| 2016-09-07 23:42 |
|
Assigned To | ssv => akz |
| 2016-09-08 15:38 | git | Note Added: 0057597 | |
| 2016-09-08 15:38 |
|
Assigned To | akz => ssv |
| 2016-09-08 22:41 |
|
Note Added: 0057619 | |
| 2016-09-08 22:41 |
|
Assigned To | ssv => akz |
| 2016-09-09 12:05 | git | Note Added: 0057633 | |
| 2016-09-09 12:06 |
|
Assigned To | akz => ssv |
| 2016-09-13 00:32 |
|
Note Added: 0057715 | |
| 2016-09-13 00:32 |
|
Assigned To | ssv => bugmaster |
| 2016-09-13 00:32 |
|
Status | assigned => resolved |
| 2016-09-13 00:33 |
|
Status | resolved => reviewed |
| 2016-09-13 10:25 |
|
Note Added: 0057717 | |
| 2016-09-13 10:25 |
|
Assigned To | bugmaster => akz |
| 2016-09-13 10:25 |
|
Status | reviewed => assigned |
| 2016-09-13 10:40 | git | Note Added: 0057718 | |
| 2016-09-13 10:41 |
|
Note Added: 0057719 | |
| 2016-09-13 10:41 |
|
Assigned To | akz => msv |
| 2016-09-13 10:41 |
|
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 |
|
Note Added: 0057827 | |
| 2016-09-15 16:21 |
|
Assigned To | msv => vro |
| 2016-09-15 16:21 |
|
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 |
|
Assigned To | msv => kgv |
| 2016-09-19 15:32 |
|
Note Added: 0057930 | |
| 2016-09-23 18:15 | kgv | Assigned To | kgv => abv |
| 2016-10-26 18:17 |
|
Target Version | 7.1.0 => 7.2.0 |
| 2016-11-01 10:14 | kgv | Relationship added | related to 0023762 |
| 2016-11-02 13:57 |
|
Assigned To | abv => akz |
| 2016-11-15 13:12 |
|
Note Added: 0060346 | |
| 2017-07-27 10:38 |
|
Target Version | 7.2.0 => 7.4.0 |
| 2019-09-04 12:58 |
|
Target Version | 7.4.0 => 7.5.0 |
| 2020-09-17 20:26 |
|
Assigned To | akz => |
| 2020-09-17 20:26 |
|
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 |
|
Note Added: 0098514 | |
| 2021-01-29 14:28 |
|
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 |
|
Target Version | 7.6.0 => 7.7.0 |
| 2022-10-19 15:50 |
|
Assigned To | kgv => vpozdyayev |
| 2022-10-24 10:43 |
|
Target Version | 7.7.0 => 7.8.0 |
| 2023-08-01 15:06 | dpasukhi | Target Version | 7.8.0 => Unscheduled |
