View Issue Details

Related ChangesetsJump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0032241CommunityOCCT:Meshpublic2021-03-23 12:282023-03-19 20:25
ReporterJerome Monaco Assigned Tooan  
PriorityhighSeverityblock 
Status closedResolutionfixed 
PlatformVC++ 2019 64 bitOSWindows 10 Enterprise 
Product Version7.4.0 
Target Version7.7.0Fixed in 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 numberbugs/mesh/bug32241, bugs/mesh/bug32422

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 closedbugmaster Community Mesh - broken triangulation on pipe shape 
related to 0029641 closedbugmaster Community Mesher produce 'bad' result for extruded spline with given deviation coefficient 
related to 0033143 newoan Open CASCADE Mesh - Extrusion surfaces: Add regulation for number of points generated along V direction 
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.

git

2022-09-09 11:52

administrator   ~0110898

Branch CR32241 has been created by oan.

SHA-1: 865d4eeaa2600915799903ae006b8a5c3d3b3f2d


Detailed log of new commits:

Author: oan
Date: Fri Sep 9 11:29:38 2022 +0300

    0031853: Mesh - holes in triangulation with large linear deflection
    
    0032422: Mesh - Weird rendering
    
    Scale down min size parameter for NURBS taking into account its U and V resolution in order to prevent comparison of 2d parameters with 3d value involved in filtering process.

git

2022-09-09 11:58

administrator   ~0110899

Branch CR32241 has been updated forcibly by oan.

SHA-1: 827885cc95d52ff776aad3a1ed1b55cdbc1b2ab1

git

2022-09-09 12:06

administrator   ~0110900

Branch CR32241 has been updated forcibly by oan.

SHA-1: 180e7cfc2c3447cb4a718b7e7f22c1989cf42355

git

2022-09-10 01:42

administrator   ~0110910

Branch CR32241 has been updated by oan.

SHA-1: c69aef89cea32a9b52b4e4e1b4b57d55bc35c342


Detailed log of new commits:

Author: oan
Date: Sat Sep 10 01:42:23 2022 +0300

    0032241: Mesh - wrong shading display of thrusections [regression since OCCT 7.4.0]
    
    Corrected test cases

git

2022-09-10 03:29

administrator   ~0110911

Branch CR32241 has been updated forcibly by oan.

SHA-1: dc876cd3258b9cba9579e210b6b59e4db7b9bb33

git

2022-09-12 11:45

administrator   ~0110976

Branch CR32241 has been updated forcibly by oan.

SHA-1: 560cae1ed992065eafceeaa2aafa60e74f82f1ce

git

2022-09-12 12:34

administrator   ~0110979

Branch CR32241 has been updated forcibly by oan.

SHA-1: ef11686e5027c6404119879b792faad06cc925e1

git

2022-09-13 16:01

administrator   ~0111022

Branch CR32241 has been updated forcibly by oan.

SHA-1: 998014a725a7691da351eef2e8daf3465064d15c

git

2022-09-13 20:55

administrator   ~0111029

Branch CR32241 has been updated forcibly by oan.

SHA-1: e4c4c0a564cc6447e333e37dc57f794dbd9029ee

oan

2022-09-13 22:15

developer   ~0111031

Branch CR32241 is ready for review.

Test reports:
http://jenkins-test-occt/view/master-CR32241-OAN/view/COMPARE/

To integrate:
OCCT: CR32241
PRODUCTS: CR32241

git

2022-09-15 13:43

administrator   ~0111065

Branch CR32241_2 has been created by oan.

SHA-1: 8d2919e5d1e82450cca5efb6b0ea2a9606c910d2


Detailed log of new commits:

Author: oan
Date: Thu Sep 15 13:43:41 2022 +0300

    0032241: Mesh - wrong shading display of thrusections [regression since OCCT 7.4.0]
    
    Add at least one midpoint for surfaces with one interval and only two poles

git

2022-09-15 16:47

administrator   ~0111067

Branch CR32241_2 has been updated forcibly by oan.

SHA-1: 964f3366067b5b13400189078cdcfee9b743b9bc

oan

2022-09-16 01:26

developer   ~0111073

Test reports:
http://jenkins-test-occt/view/master-CR32241_2-OAN/view/COMPARE/

To integrate:
OCCT: CR32241_2
PRODUCTS: CR32241_2

msv

2022-09-16 10:44

developer   ~0111081

In new fix theIntervals in the method getUndefinedInterval is first initialized and then if aIntervalsNb == 1 will be initialized again. It is better to make the code to initialize it only once (replace the 'else' statement in the previous version with checking some condition that array was not initialized).

git

2022-09-16 12:56

administrator   ~0111093

Branch CR32241_2 has been updated forcibly by oan.

SHA-1: def85882624ba47f8d22c806d7603af0ad1555ac

oan

2022-09-16 16:47

developer   ~0111103

Remarks are taken into account.

Test reports:
http://jenkins-test-occt/view/master-CR32241_2-OAN/view/COMPARE/

To integrate:
OCCT: CR32241_2
PRODUCTS: CR32241_2

msv

2022-09-16 17:03

developer   ~0111104

Please combine commits in one.

git

2022-09-16 17:27

administrator   ~0111105

Branch CR32241_2 has been updated forcibly by oan.

SHA-1: a357c3be8fa7b71afb7d3821081f3382164afe4c

git

2022-09-16 17:43

administrator   ~0111107

Branch CR32241 has been updated forcibly by oan.

SHA-1: a238b33395d78181de5b12fd9a06c062d6262e54

git

2022-09-16 17:44

administrator   ~0111109

Branch CR32241_2 has been updated forcibly by oan.

SHA-1: a238b33395d78181de5b12fd9a06c062d6262e54

git

2022-09-16 17:44

administrator   ~0111110

Branch CR32241 has been deleted by oan.

SHA-1: a238b33395d78181de5b12fd9a06c062d6262e54

msv

2022-09-16 17:45

developer   ~0111111

To integrate:
OCCT: CR32241_2
PRODUCTS: CR32241_2

smoskvin

2022-09-17 19:31

administrator   ~0111113

Combination -
OCCT branch : IR-2022-09-16
master SHA - changes and them, and you can discard any commits you make in this
a939fd40eb473e79134ba740ed8e3f8aa4df37a7
changes and them, and you can discard any commits you make in this
e0ceb716c70188b98130b1550914140d0502a6f9
Products branch : IR-2022-09-16 SHA - 63dd76a64eb2213a575fdcfd88c28e77af367df1
was compiled on Linux, MacOS and Windows platforms and tested in optimize mode.

Number of compiler warnings:
No new/fixed warnings

Regressions/Differences/Improvements:
No regressions/differences

CPU differences:
Debian80-64:
OCCT
Total CPU difference: 18769.440000000584 / 18960.430000000466 [-1.01%]
Products
Total CPU difference: 11959.870000000119 / 12078.45000000014 [-0.98%]
Windows-64-VC14:
OCCT
Total CPU difference: 20851.0625 / 20895.5625 [-0.21%]
Products
Total CPU difference: 14084.640625 / 13533.359375 [+4.07%]


Image differences :
No differences that require special attention

Memory differences :
No differences that require special attention

git

2022-09-17 19:38

administrator   ~0111122

Branch CR32241_2 has been deleted by mnt.

SHA-1: a238b33395d78181de5b12fd9a06c062d6262e54

Jerome Monaco

2022-10-06 14:53

reporter   ~0111411

Hi gentlemen, I built the 7.7.0 with vs2022 and everything works fine.
Good job, thanks you very much !
Best regards.
Jerome.
PS: I hope this note will not change the status of the BUG...

Related Changesets

occt: master c4ea4ca3

2022-09-09 11:29:38

oan


Committer: smoskvin Details Diff		 0032241: Mesh - wrong shading display of thrusections [regression since OCCT 7.4.0]

0032422: Mesh - Weird rendering
0029641: Mesher produce 'bad' result for extruded spline with given deviation coefficient

Added method BRepMesh_NURBSRangeSplitter::getUndefinedInterval() intended to compute checkpoint parameters for those NURBS surfaces which have no intervals at all. In this case number of poles is used to produce artificial regular grid which can be refined further. Add at least one midpoint for surfaces with one interval and only two poles.

Added BRepMesh_ExtrusionRangeSplitter and BRepMesh_UndefinedRangeSplitter derivatives from BRepMesh_NURBSRangeSplitter intended to handle special cases of extrusion surfaces and general surfaces with undefined parameters.		 Affected Issues
0032241
add - src/BRepMesh/BRepMesh_ExtrusionRangeSplitter.cxx Diff File
add - src/BRepMesh/BRepMesh_ExtrusionRangeSplitter.hxx Diff File
mod - src/BRepMesh/BRepMesh_MeshAlgoFactory.cxx Diff File
mod - src/BRepMesh/BRepMesh_NURBSRangeSplitter.cxx Diff File
mod - src/BRepMesh/BRepMesh_NURBSRangeSplitter.hxx Diff File
add - src/BRepMesh/BRepMesh_UndefinedRangeSplitter.cxx Diff File
add - src/BRepMesh/BRepMesh_UndefinedRangeSplitter.hxx Diff File
mod - src/BRepMesh/FILES Diff File
mod - tests/bugs/iges/buc60820_1 Diff File
mod - tests/bugs/iges/buc60820_2 Diff File
mod - tests/bugs/iges/buc60823 Diff File
mod - tests/bugs/iges/bug306 Diff File
mod - tests/bugs/mesh/bug23631 Diff File
mod - tests/bugs/mesh/bug25287 Diff File
mod - tests/bugs/mesh/bug27845 Diff File
mod - tests/bugs/mesh/bug29149 Diff File
add - tests/bugs/mesh/bug29641 Diff File
mod - tests/bugs/mesh/bug30008_1 Diff File
mod - tests/bugs/mesh/bug30167 Diff File
mod - tests/bugs/mesh/bug31251 Diff File
add - tests/bugs/mesh/bug32241 Diff File
add - tests/bugs/mesh/bug32422 Diff File
mod - tests/bugs/modalg_2/bug264_0 Diff File
mod - tests/bugs/modalg_2/bug292 Diff File
mod - tests/bugs/modalg_2/bug358 Diff File
mod - tests/bugs/moddata_1/bug15519 Diff File
mod - tests/bugs/moddata_1/bug22759 Diff File
mod - tests/bugs/moddata_2/bug428 Diff File
mod - tests/de_mesh/shape_write_stl/A11 Diff File
mod - tests/de_mesh/shape_write_stl/A4 Diff File
mod - tests/hlr/poly_hlr/bug23625_1 Diff File
mod - tests/hlr/poly_hlr/bug23625_2 Diff File
mod - tests/hlr/poly_hlr/bug23625_3 Diff File
mod - tests/hlr/poly_hlr/bug27719_102 Diff File
mod - tests/hlr/poly_hlr/bug27719_103 Diff File
mod - tests/hlr/poly_hlr/bug27719_104 Diff File
mod - tests/hlr/poly_hlr/bug27719_105 Diff File
mod - tests/hlr/poly_hlr/C12 Diff File
mod - tests/hlr/poly_hlr/C14 Diff File
mod - tests/hlr/poly_hlr/C15 Diff File
mod - tests/hlr/poly_hlr/C16 Diff File
mod - tests/hlr/poly_hlr/C17 Diff File
mod - tests/hlr/poly_hlr/C3 Diff File
mod - tests/hlr/poly_hlr/C7 Diff File
mod - tests/mesh/data/advanced/B8 Diff File
mod - tests/mesh/data/standard/L2 Diff File
mod - tests/mesh/data/standard/M8 Diff File
mod - tests/mesh/data/standard/Q3 Diff File
mod - tests/mesh/data/standard/U2 Diff File
mod - tests/mesh/data/standard/W6 Diff File
mod - tests/mesh/data/standard/W7 Diff File
mod - tests/mesh/data/standard/X1 Diff File
mod - tests/perf/mesh/bug26965 Diff File
mod - tests/v3d/bugs/bug288_5 Diff File

occt-products: master be9c0f60

2022-09-12 12:26:26

oan


Committer: smoskvin Details Diff		 0032241: Mesh - wrong shading display of thrusections [regression since OCCT 7.4.0]

0032422: Mesh - Weird rendering
0029641: Mesher produce 'bad' result for extruded spline with given deviation coefficient

Corrected test cases		 Affected Issues
0032241
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - diff Diff File
mod - tests/bfit/loc_complex/A3 Diff File
mod - tests/bfit/loc_propeller/A1 Diff File
mod - tests/bfit/loc_propeller/A2 Diff File
mod - tests/bfit/loc_propeller/A4 Diff File
mod - tests/bfit/loc_propeller/A6 Diff File
mod - tests/bfit/loc_propeller/A8 Diff File
mod - tests/bfit/loc_propeller/B2 Diff File
mod - tests/bfit/loc_propeller/B3 Diff File
mod - tests/bfit/loc_propeller/B5 Diff File
mod - tests/bfit/loc_propeller/B6 Diff File
mod - tests/bfit/loc_propeller/C1 Diff File
mod - tests/bfit/loc_teapot/A1 Diff File
mod - tests/bfit/loc_teapot/A4 Diff File
mod - tests/bfit/loc_teapot/B3 Diff File
mod - tests/bfit/loc_teapot/C2 Diff File
mod - tests/bfit/loc_teapot/C3 Diff File
mod - tests/bfit/loc_teapot/C4 Diff File
mod - tests/bfit/loc_teapot/D1 Diff File
mod - tests/bfit/loc_teapot/D4 Diff File
mod - tests/bfit/loc_teapot/E3 Diff File
mod - tests/bfit/loc_teapot/F3 Diff File

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
2022-09-09 11:52 git Note Added: 0110898
2022-09-09 11:58 git Note Added: 0110899
2022-09-09 12:06 git Note Added: 0110900
2022-09-10 01:42 git Note Added: 0110910
2022-09-10 03:29 git Note Added: 0110911
2022-09-12 11:45 git Note Added: 0110976
2022-09-12 12:34 git Note Added: 0110979
2022-09-13 16:01 git Note Added: 0111022
2022-09-13 20:55 git Note Added: 0111029
2022-09-13 22:15 oan Assigned To oan => msv
2022-09-13 22:15 oan Status new => resolved
2022-09-13 22:15 oan Note Added: 0111031
2022-09-14 13:13 msv Assigned To msv => bugmaster
2022-09-14 13:13 msv Status resolved => reviewed
2022-09-14 14:21 oan Relationship added related to 0033143
2022-09-15 13:43 git Note Added: 0111065
2022-09-15 13:46 oan Assigned To bugmaster => oan
2022-09-15 13:46 oan Status reviewed => assigned
2022-09-15 16:47 git Note Added: 0111067
2022-09-16 01:26 oan Assigned To oan => msv
2022-09-16 01:26 oan Status assigned => resolved
2022-09-16 01:26 oan Note Added: 0111073
2022-09-16 10:44 msv Note Added: 0111081
2022-09-16 10:44 msv Assigned To msv => oan
2022-09-16 10:44 msv Status resolved => assigned
2022-09-16 12:56 git Note Added: 0111093
2022-09-16 16:47 oan Note Added: 0111103
2022-09-16 16:47 oan Assigned To oan => msv
2022-09-16 16:47 oan Status assigned => resolved
2022-09-16 17:03 msv Note Added: 0111104
2022-09-16 17:03 msv Assigned To msv => oan
2022-09-16 17:03 msv Status resolved => assigned
2022-09-16 17:27 git Note Added: 0111105
2022-09-16 17:29 oan Assigned To oan => msv
2022-09-16 17:29 oan Status assigned => resolved
2022-09-16 17:43 git Note Added: 0111107
2022-09-16 17:44 git Note Added: 0111109
2022-09-16 17:44 git Note Added: 0111110
2022-09-16 17:45 msv Assigned To msv => bugmaster
2022-09-16 17:45 msv Status resolved => reviewed
2022-09-16 17:45 msv Note Added: 0111111
2022-09-17 19:31 smoskvin Status reviewed => tested
2022-09-17 19:31 smoskvin Note Added: 0111113
2022-09-17 19:35 smoskvin Test case number => bugs/mesh/bug32241, bugs/mesh/bug32422
2022-09-17 19:36 smoskvin Changeset attached => occt master c4ea4ca3
2022-09-17 19:36 oan Assigned To bugmaster => oan
2022-09-17 19:36 oan Status tested => verified
2022-09-17 19:36 oan Resolution open => fixed
2022-09-17 19:36 smoskvin Changeset attached => occt-products master be9c0f60
2022-09-17 19:38 git Note Added: 0111122
2022-10-06 14:53 Jerome Monaco Note Added: 0111411
2023-03-19 20:25 vglukhik Status verified => closed
2023-03-19 20:25 vglukhik Fixed in Version => 7.7.0