View Issue Details

IDProjectCategoryView StatusLast Update
0032241CommunityOCCT:Meshpublic2022-02-04 17:14
ReporterJerome Monaco Assigned Tooan  
PriorityhighSeverityblock 
Status newResolutionopen 
PlatformVC++ 2019 64 bitOSWindows 10 Enterprise 
Product Version7.4.0 
Target Version7.7.0 
Summary0032241: Mesh - wrong shading display of thrusections [regression since OCCT 7.4.0]
DescriptionI gentlemen, just after moving to OCC 7.5 I got this problem.
This was working good with OCC 7.3.0
I do not know if the problem exists in 7.4.0

I tried to change deflection angle before building my shape etc... without success.

I consider it is a blocking problem for me as I cannot update my software with this wrong visualisation.

Thanks in advance.
Best regards.
Jerome
Steps To Reproduce
pload MODELING VISUALIZATION
circle c0 0 0 0 0 0 1 30
circle c1 0 0 0 0 0 1 30
rotate c1 2000 0 0 0 1 0 15
circle c2 0 0 0 0 0 1 30
rotate c2 2000 0 0 0 1 0 30
circle c3 0 0 0 0 0 1 30
rotate c3 2000 0 0 0 1 0 45
circle c4 0 0 0 0 0 1 30
rotate c4 2000 0 0 0 1 0 60
mkedge e0 c0
mkedge e1 c1
mkedge e2 c2
mkedge e3 c3
mkedge e4 c4
wire w0 e0
wire w1 e1
wire w2 e2
wire w3 e3
wire w4 e4
thrusections ts issolid w0 w1 w2 w3 w4 

vinit View1
vdisplay -dispMode 1 ts
vfit
trinfo ts


Output:
This shape contains 1 faces.
                    2146 triangles.
                    1121 nodes.
                    3 polygons on triangulation.
Maximal deflection 45.350609530469775
Meshing deflection 5.0429131473465771
Meshing angular deflection 20
Meshing min size 0.5042913147346577

Result: KO - mesh has deflection 9x times larger than requested one!

explode ts F
tessellate r ts_1  10 10
vdisplay -dispMode 1 r

Result: OK, mesh looks fine.
TagsNo tags attached.
Test case number

Attached Files

  • OCC-7.3.png (13,502 bytes)
  • OCC-7.5.png (13,491 bytes)
  • ts.brep (6,803 bytes)
  • OCC-7.5-Mesh-test-1.png (6,022 bytes)
  • OCC-7.5-Mesh-Skip-Optimization.png (20,001 bytes)
  • BRepOffsetAPI_ThruSections_Issue.cxx (1,679 bytes)
  • BRepOffsetAPI_MakePipe.brep (1,662 bytes)
  • BRepOffsetAPI_ThruSections.brep (1,662 bytes)
  • OCC-7.5-Compare-ThruSection-MakePipe-With-Mesh-Optimization.png (33,014 bytes)
  • BRepOffsetAPI_MakePipe-2.brep (1,662 bytes)
  • BRepOffsetAPI_ThruSections-2.brep (11,752 bytes)
  • OCC-7.5-Compare-ThruSection-MakePipe-Skip-Mesh-Optimization-1.png (120,533 bytes)
  • ThruSections-MakePipe-With-Correction.pdf (545,913 bytes)
  • BRepMesh_NURBSRangeSplitter.cxx (23,599 bytes)
  • Wrong_arc-display-1.brep (184,839 bytes)

Relationships

related to 0030442 newoan Community Mesh - broken triangulation on pipe shape 
related to 0029641 newoan Community Mesher produce 'bad' result for extruded spline with given deviation coefficient 
child of 0026106 closedbugmaster Open CASCADE BRepMesh - revision of data model 

Activities

Jerome Monaco

2021-03-23 12:28

reporter  

OCC-7.3.png (13,502 bytes)

Jerome Monaco

2021-03-23 12:29

reporter  

OCC-7.5.png (13,491 bytes)

kgv

2021-03-23 12:41

developer  

ts.brep (6,803 bytes)

oan

2021-03-29 16:26

developer   ~0099820

Hello Jerome,

Thank you for reporting the issue.

This is a known problem and additional use case will help us a lot.

However, it is not planned for implementation in the nearest future.

We'll keep you informed.

Jerome Monaco

2021-03-30 14:58

reporter   ~0099872

Hello Oan, thanks for the info. If I understand well it should be solved in 7.6.0, so in next september.

I know I can rollback to the 7.3.0 but this mean I have many changes to apply to my code and I will have to redo that again in september.

Is there something I can do do (even if it is not a clean solution) to remove this problem in waiting for your correction ?

Best regards.
Jerome.

kgv

2021-03-30 15:22

developer   ~0099877

> If I understand well it should be solved in 7.6.0,
Jerome, the target version in Bugtracker indicates only preliminary planning (next release is set by default).
The actual planning is done based on available resources and priorities - so that bug can be shifted to the next release.

Jerome Monaco

2021-03-30 19:29

reporter   ~0099895

Hi kgv, ok it is clear for the first part of the question !

Let's go for the second part: Is there something I can do (even if it is not a clean solution) to remove this problem in waiting for your correction ?

Best regards.
Jerome.

oan

2021-03-30 22:11

developer   ~0099896

Last edited: 2021-03-30 22:17

Jerome,

as for the second part of your question, there could be several ways to keep your progress:

- you are welcome to join OCCT developers community and provide your patches for integration or keep your drafts upon OCCT code as the basis for further development and finalization by making commits to corresponding branches in OCCT repository, even if solution is incomplete, but fits your requirements. Please refer to https://dev.opencascade.org/get_involved for additional details.

- you may want to rollback to OCCT 7.3.0 for a while, but keep your progress related to recent version of OCCT using separate branch in version control of your personal project, e.g. local git, svn, etc. until the issue is fixed and apply it afterwards;

- you also welcome to make a request for paid services using "Contact Us" form at https://www.opencascade.com or https://dev.opencascade.org/webform/contact_us

Best regards,
Oleg.

Jerome Monaco

2021-11-02 17:14

reporter   ~0105006

Hi gentlemen, I received an email about the postpone of this correction to 7.7. I am really not happy with that because I was thinking it could be in 7.6.
Anyway, I would like to do the correction by myself but OCC is huge and even if I use it I do not spend my time in it... so can you give me some advise on what / where to check, what you suspect going wrong ?
Thanks.
Best regards.
Jerome.

kgv

2021-11-08 10:09

developer   ~0105059

Jerome,

I understand your frustration, but not all issues could be treated at once.
There are other bug-fixes and features in release, and some problems might looks critical/blocking to specific applications, but that doesn't mean that problem is critical to all applications.

As for the tips, from the other linked issue, oan wrote:
> On the first sight, it looks like an issue within points filtering tool used for NURBS, BRepMesh_NURBSRangeSplitter::GenerateSurfaceNodes().
> Sometimes, it produces excess number of points, sometimes, less than it is expected by human due to the lack of complex checks over curvature change existed since much earlier versions.

Jerome Monaco

2021-11-08 11:58

reporter   ~0105062

Hi kgv, I know it is not easy... anyway thanks for your answer, I will try to check the code if I can understand what is done in it.
Best regards.
Jerome.

Jerome Monaco

2021-12-17 19:53

reporter   ~0106055

Hi gentlemen, I spent some hours on this problem. Unfortunately I did not found the exact reason but I have some information to share:
When I jump over the optimizeMesh(...) function in the BRepMesh_DelaunayDeflectionControlMeshAlgo::postProcessMesh(...) I obtain the attached image. I feel it is not normal as the optimization is only here to refine the mesh if deflection is not respected. This is also the reason why there are so much triangles and nodes, they are added by the 11 steps of the optimization. This mean that you have reason, the BRepMesh_NURBSRangeSplitter::GenerateSurfaceNodes does not make the job. I suspect a wrong u,v params count. That's all I have for the moment.
I wish you all a merry christmas.
Best regards.
Jerome Monaco.
OCC-7.5-Mesh-test-1.png (6,022 bytes)

oan

2021-12-20 11:27

developer   ~0106111

Last edited: 2021-12-20 11:32

Hello Jerome,

Thank you for your interest and investigation of the problem.
Yes, you are correct, optimizeMesh() is intended to add some nodes where surface is too much distorted so it is hard to take this into account using the straight way.
The matter is also that BRepMesh_NURBSRangeSplitter::GenerateSurfaceNodes() could omit some nodes if they produce surface that fits specified requirements for deflection and angle. Please have a look at AnalyticalFilter::checkParameterForDeflectionAndUpdateCache() located in BRepMesh_NURBSRangeSplitter.h file.

This was done to significantly reduce amount of nodes initially produced by generator.
You could try to improve or even remove this check so all the source node would appear in the final mesh.

Could you also please attach some additional shapes representing this bug so we could cover it by as much test cases as possible (e.g. the one shown on your latest screenshot).

Thank you very much and Merry Christmas,
Oleg.

Jerome Monaco

2022-01-04 11:43

reporter   ~0106260

Hi Oleg, I spent some more hours on this problem but still not find the solution....
To obtain the previous screenshot you only have to skip the mesh optimization step in BRepMesh_DelaunayDeflectionControlMeshAlgo::postProcessMesh(...) see code in attachment.
As you can see in the same screenshot, only the first and the last circle have been discretized. I think that the problem do not comes from a point’s removal done by a cleanup function but only because the intermediate points are never added.
Best regards.
Jerome.
OCC-7.5-Mesh-Skip-Optimization.png (20,001 bytes)

oan

2022-01-10 11:18

developer   ~0106275

Hi Jerome,

well, good guess, thank you. Anyway it would help us to localize the problem more quickly.
Yes, I see that discretization of the presented model covers only the circles, but the tube itself remains unmeshed.
Are you able to attach this model to the issue for further investigation?

Once more, thank you for reporting the problem, we will have a look at it once we get a chance.
Oleg.

Jerome Monaco

2022-01-10 14:01

reporter   ~0106279

Hi Oleg, I am sure now that the tessellation part is working well. The problem comes from the BRepOffsetAPI_ThruSections that generates wrong geometry that brings a wrong tessellation. I did the same shape but I used BRepOffsetAPI_MakePipe and the tessellation is perfect.
I think some intermediates sections are missing from finale shape of ThruSections.
Please find attached some code to reproduce.
Best regards.
Jerome.
BRepOffsetAPI_ThruSections_Issue.cxx (1,679 bytes)

kgv

2022-01-10 15:35

developer   ~0106284

Jerome wrote:
> The problem comes from the BRepOffsetAPI_ThruSections that generates wrong geometry

the same issue comes while importing some STEP files with pipes.
So I guess the geometry is OK, though maybe STEP import uses the same algorithm.

Jerome Monaco

2022-01-13 12:42

reporter   ~0106334

Hi gentlemen, I am ok to spend some more time to solve this issue as I got some user complain yesterday.
I suspect it is somewhere in BRepOffsetAPI_ThruSections, kgv says the same issue comes when importing from step with pipes. My time is limited and I cannot spent it all in overall search, can you please give me some advice on where to start ?
Best regards.
Jerome.

oan

2022-01-18 14:22

developer   ~0106439

Hello Jerome,

Yes, BRepOffsetAPI_ThruSections could produce results that end up with artifacts in visualization.
If I remember well, there could be a situation when even circular curves rotated to some angle relatively each other produce bad visual result.

Unfortunately, I am unable to provide any suggestion regarding internals of BRepOffsetAPI_ThruSections.

Probably, kgv or msv could give you a hint.

msv

2022-01-18 16:16

developer   ~0106441

BRepOffsetAPI_ThruSections works correct. It produces the B-spline surface. And it is the disadvantage of BRepMesh algorithm that it cannot correctly tessellate such pipe-like B-spline surface.
As for BRepOffsetAPI_MakePipe, it produces just a torus. BRepmesh can tessellate the toroidal surface well, and it explains the results.

Jerome Monaco

2022-01-26 12:16

reporter   ~0106596

Hello msv, oan, sorry for my late answer. I did some checks and you are right. The brep geometry generated by ThruSections or MakePipe are identical (I compared generated files). This mean, as you said, that the b-spline surface is wrongly handled by BrepMesh.
What I do not understand is that this problem was present in versions before 7.3 (I partially solved it by using specific angles and length values for meshing). It has been corrected in 7.3 and it appear again in 7.5 (I did not checked 7.4).
Do you have some advice about that ?
Best regards.
Jerome.

Jerome Monaco

2022-01-26 12:20

reporter   ~0106600

Sorry I forgot to add attachments about my last email. You will find:
- the 2 generated brep files
- a sreen copy of these files
Jerome.
BRepOffsetAPI_MakePipe.brep (1,662 bytes)
BRepOffsetAPI_ThruSections.brep (1,662 bytes)
OCC-7.5-Compare-ThruSection-MakePipe-With-Mesh-Optimization.png (33,014 bytes)

Jerome Monaco

2022-01-27 17:21

reporter   ~0106636

Hi gentlemen, I am sorry I made an error in my previous email. To resume the geometry generated by ThruSection and MakePipe are both correct when exported to step and imported to SolidWorks. I confirm that the Mesher does not handle properly the geometry generated by ThruSection (bspline surface) under some conditions.
I reattached the correct files.
Best regards.
Jerome.
BRepOffsetAPI_MakePipe-2.brep (1,662 bytes)
BRepOffsetAPI_ThruSections-2.brep (11,752 bytes)

Jerome Monaco

2022-01-27 17:47

reporter   ~0106639

Another example that show very well that the bspline surface is only handled properly at the first and last wires.
OCC-7.5-Compare-ThruSection-MakePipe-Skip-Mesh-Optimization-1.png (120,533 bytes)

oan

2022-01-28 13:39

developer   ~0106651

Hi Jerome,

Thank you a lot for the attached shapes, they would help us very much and will enhance OCCT's non-regression test data base, thus will potentially make it more stable to future modifications.

The matter is that that edges and surface are processed separately, and wires at both ends of the pipe look good in any case, but number of generated surface nodes is not enough to represent surface geometry in the correct way.

On the first glance, I suppose that the problem, initially, takes place at BRepMesh_NURBSRangeSplitter::initParameters().
You see that the splitter relies on the number of BSpline's intervals and then adds additional points that suit specified deflection.
However, there is only a single interval and no point is actually generated for the interior of the face.

There is an issue, 0030330, that supposes addition of some points to surface taking into account curvature of the boundary edges, but it will actually have no sense in case of the straight edges.

Like this, in context of this issue we need to elaborate a specific approach to generate points for tube-like BSpline surfaces with only a single interval.
As the simplest solution it is possible to take all U and V parameters provided by boundary edges and generate a set of internal points as intersection points of the iso-lines corresponded to that parameters.
The only thing in such approach is highly probable performance slowdown on some existing use cases with complex geometry due to excess number of points generated for generally flat surfaces but having curvy edges and, otherwise, will have no effect at all for use cases with highly distorted surfaces confined by straight borders.

The most wanted solution here, IMHO, would be implementation of points generator based on an advanced analysis of BSpline surface, far beyond the naive approach using number of intervals.

MSV, I suggest to go into a very close collaboration with our modeling team here in order to prepare a draft of such analysis tool to cover all possible nuances hidden in the depths of BSpline surfaces' math, given that the issue itself is not the problem of the processor of the discrete model, but in the processor of geometrical data preparing a discrete model that have general nature and is common for all algorithms along OCCT that take exact BSpline geometry into account, e.g. BOP algo or shape fix.

Jerome, thank you a lot for your patience and all the details and use cases provided so far.
We will investigate the issue more closely as soon as we have resources available.

Best regards,
Oleg.

Jerome Monaco

2022-02-02 10:47

reporter   ~0106710

Hi Oleg, thanks to took the time to answer, it is clear. I have a last request:
Could you please just tell me where in code is the best place to add the missing points in waiting for the final bug correction ?
Thanks.
Best regards.
Jerome.

oan

2022-02-02 14:12

developer   ~0106715

Jerome,

For this particular use case you can refer to BRepMesh_NURBSRangeSplitter::initParameters().
There are two calls to grabParamsOfEdges() commented out in the code collecting U and V parameters from edges.
You can try to include this parts on your side as a temporary solution.
However, note that in general initParamsFromIntervals() will always return true, so you should probably move both calls out of each if-block.

Please notify if this would work for you,
Best regards,
Oleg.

Jerome Monaco

2022-02-03 16:05

reporter   ~0106732

Hi Oleg, according to your comment I have solved my problem (in waiting for the OCC team correction) by using the grapParamsOfEdges() function. Sometime it generates a lot of triangles but it is not a problem for my use.
I attached a PDF with what I did and the results I obtain.
I will do some more strong testing in the next days and I will deliver a correction for my users.
Thanks a lot for your team help an support.
Jerome.
ThruSections-MakePipe-With-Correction.pdf (545,913 bytes)

Jerome Monaco

2022-02-04 12:53

reporter   ~0106740

Hi Oleg, I found another case that did not worked. Please find attached the brep file for your tests.
I also strongly modified the BRepMesh_NURBSRangeSplitter.cxx to make it working for my cases. It generates now nice meshes like MakePipe.
I do not try to make optimization on the code or anything else, I also suppose that it may not work on complex surface, but that's enough for me in waiting for the bug correction. I attached also my modified BRepMesh_NURBSRangeSplitter.cxx.
Thanks for your help.
Best regards.
Jerome.
BRepMesh_NURBSRangeSplitter.cxx (23,599 bytes)
Wrong_arc-display-1.brep (184,839 bytes)

oan

2022-02-04 17:14

developer   ~0106742

Hi Jerome,

Way to go, nice and clean!
Yes you are correct, this solution may potentially result in presentations lacking some details as it was described earlier, but it is good to know that it suits your needs anyway.

Will keep you updated.

Issue History

Date Modified Username Field Change
2021-03-23 12:28 Jerome Monaco New Issue
2021-03-23 12:28 Jerome Monaco Assigned To => kgv
2021-03-23 12:28 Jerome Monaco File Added: OCC-7.3.png
2021-03-23 12:29 Jerome Monaco File Added: OCC-7.5.png
2021-03-23 12:41 kgv Assigned To kgv => oan
2021-03-23 12:41 kgv Category OCCT:Visualization => OCCT:Mesh
2021-03-23 12:41 kgv Target Version => 7.6.0
2021-03-23 12:41 kgv Summary Wrong shading display of thrusections => Mesh - wrong shading display of thrusections
2021-03-23 12:41 kgv Steps to Reproduce Updated
2021-03-23 12:41 kgv File Added: ts.brep
2021-03-23 12:42 kgv Product Version 7.5.0 => 7.4.0
2021-03-23 12:42 kgv Summary Mesh - wrong shading display of thrusections => Mesh - wrong shading display of thrusections [regression since OCCT 7.4.0]
2021-03-23 12:44 kgv Relationship added child of 0026106
2021-03-23 12:48 oan Relationship added related to 0030442
2021-03-23 12:48 oan Relationship added related to 0029641
2021-03-29 16:26 oan Note Added: 0099820
2021-03-30 14:58 Jerome Monaco Note Added: 0099872
2021-03-30 15:22 kgv Note Added: 0099877
2021-03-30 19:29 Jerome Monaco Note Added: 0099895
2021-03-30 22:11 oan Note Added: 0099896
2021-03-30 22:17 oan Note Edited: 0099896
2021-11-01 18:13 szy Target Version 7.6.0 => 7.7.0
2021-11-02 17:14 Jerome Monaco Note Added: 0105006
2021-11-08 10:09 kgv Note Added: 0105059
2021-11-08 10:11 kgv Steps to Reproduce Updated
2021-11-08 11:58 Jerome Monaco Note Added: 0105062
2021-12-17 19:53 Jerome Monaco Note Added: 0106055
2021-12-17 19:53 Jerome Monaco File Added: OCC-7.5-Mesh-test-1.png
2021-12-20 11:27 oan Note Added: 0106111
2021-12-20 11:32 oan Note Edited: 0106111
2022-01-04 11:43 Jerome Monaco Note Added: 0106260
2022-01-04 11:43 Jerome Monaco File Added: OCC-7.5-Mesh-Skip-Optimization.png
2022-01-10 11:18 oan Note Added: 0106275
2022-01-10 14:01 Jerome Monaco Note Added: 0106279
2022-01-10 14:01 Jerome Monaco File Added: BRepOffsetAPI_ThruSections_Issue.cxx
2022-01-10 15:35 kgv Note Added: 0106284
2022-01-13 12:42 Jerome Monaco Note Added: 0106334
2022-01-18 14:22 oan Note Added: 0106439
2022-01-18 16:16 msv Note Added: 0106441
2022-01-26 12:16 Jerome Monaco Note Added: 0106596
2022-01-26 12:20 Jerome Monaco Note Added: 0106600
2022-01-26 12:20 Jerome Monaco File Added: BRepOffsetAPI_MakePipe.brep
2022-01-26 12:20 Jerome Monaco File Added: BRepOffsetAPI_ThruSections.brep
2022-01-26 12:20 Jerome Monaco File Added: OCC-7.5-Compare-ThruSection-MakePipe-With-Mesh-Optimization.png
2022-01-27 11:31 kgv Priority normal => high
2022-01-27 17:21 Jerome Monaco Note Added: 0106636
2022-01-27 17:21 Jerome Monaco File Added: BRepOffsetAPI_MakePipe-2.brep
2022-01-27 17:21 Jerome Monaco File Added: BRepOffsetAPI_ThruSections-2.brep
2022-01-27 17:47 Jerome Monaco Note Added: 0106639
2022-01-27 17:47 Jerome Monaco File Added: OCC-7.5-Compare-ThruSection-MakePipe-Skip-Mesh-Optimization-1.png
2022-01-28 13:39 oan Note Added: 0106651
2022-02-02 10:47 Jerome Monaco Note Added: 0106710
2022-02-02 14:12 oan Note Added: 0106715
2022-02-03 16:05 Jerome Monaco Note Added: 0106732
2022-02-03 16:05 Jerome Monaco File Added: ThruSections-MakePipe-With-Correction.pdf
2022-02-04 12:53 Jerome Monaco Note Added: 0106740
2022-02-04 12:53 Jerome Monaco File Added: BRepMesh_NURBSRangeSplitter.cxx
2022-02-04 12:53 Jerome Monaco File Added: Wrong_arc-display-1.brep
2022-02-04 17:14 oan Note Added: 0106742