Mesh - The refactored Mesher fails to mesh correctly scaled (planar) faces

Branch [archived branch] has been created by Author.

[revision removed]


Detailed log of new commits:

Author: Dzmitry Razmyslovich
Date: Sat Mar 27 19:38:16 2021 +0100

    0032253: Fix the incorrect parameters for end points - get parameters directly from curve instead of relying on the parameter provider

Hello, Oleg.

I am not sure if the fix I propose is the best one. Most probably, it is better to fix the parameter provider to gracefully handle the scaled (at least) planes. As far as I understand, currently for planes the parameters provider just projects a point on plane without taking the scaling into account which results in an error.

My fix demonstrates where the problem is located and fixes the problem in my particular case, therefore I haven't investigated it further.

[signature removed]
Dima

Hello Dmitry,

Please see the bug #0027457. We are going to forbid storing a location with scale factor in shapes. Instead, when one wants to scale a shape he should use the algorithm BRepBuilderAPI_Transform that will modify the geometry.

Even if your current patch fixes this particular problem with a scaled shape, you may face the same-cause problem in many other OCCT algorithms.

So, please think about using BRepBuilderAPI_Transform instead of patching OCCT codes against this issue.

[signature removed]
Mikhail

Hello, Mikhail,

thank you very much for providing this valuable information. We will adapt our code to have no scaling in the transformation matrices.

Do you also plan in the context of 0027457 to add some compatibility code for 'old' native occ files, which contain shapes with scaling transforms? Or should we develop such compatibility code ourselves? Our customers have definitely tons of projects with such xbf files.

[signature removed]
Dima

I will pass this wish into that ticket. We will try to consider it.

Dear Commenter 1, please close this bug.

Oleg,

could you please take a look onto proposed patch and comment if it looks reasonable / should be moved to another location?

I would prefer integrating a fix into BRepMesh if it would not require dramatic rewriting, as preventing scale factor in TopLoc_Location by #0027457 could take much time and we do not have yet elaborated when and how it will be raised.

DC,

Patch looks appropriate for this particular issue.
As I can see, in general case there are only two points for each edge in this case and modification works pretty well.

However, personally, I am concerned about scaled non-planar cases, i.e. NURBS when more than two points exist for each edge.

Dima, do you have any use cases of such shapes?

I will check and either find such a model or ask to create one.

Branch [archived branch] has been created by Commenter 4.

[revision removed]


Detailed log of new commits:

Author: Commenter 4
Date: Wed Mar 31 14:54:00 2021 +0300

    0032253: Mesh - The refactored Mesher fails to mesh correctly scaled (planar) faces
    
    IMeshTools_ShapeExplorer: process face without any transformation

Branch [archived branch] has been updated forcibly by Commenter 4.

[revision removed]

Branch [archived branch] has been updated forcibly by Commenter 4.

[revision removed]

Branch [archived branch] has been updated by Commenter 4.

[revision removed]


Detailed log of new commits:

Author: Commenter 4
Date: Fri Apr 2 11:46:35 2021 +0300

    0032253: Mesh - The refactored Mesher fails to mesh correctly scaled (planar) faces
    
    IMeshTools_ShapeExplorer: use transformation without scale factor

Branch [archived branch] has been created by Commenter 4.

[revision removed]


No new revisions were added by this update.

Hello Dima,

I have checked your patch and added two alternative variants to fix the problem on common level (see commits in CR32253_base and CR32253).

However, all of them contain regressions due to which they could not be integrated yet.

The most stable is CR0032253 - leads mostly to absence of some triangles in the mesh along the frontier edges.

CR32253_base - it contains mostly async edges problem when points related to shared edges do not coincide on adjacent faces. In some specific cases where face has huge gaps between ends of the edges, triangulation could be absent.

CR32253 - produces the most number of regressions of the same nature as previous one.

Mikhail,

could you please have a look at the testing results for the aforementioned changes:

CR0032253:
http://vm-jenkins-test-12.nnov.opencascade.com:8080/view/master-CR0032253-OAN/view/COMPARE/

CR32253_base:
http://vm-jenkins-test-12.nnov.opencascade.com:8080/view/master-CR32253_base_OAN/view/COMPARE/

CR32253:
http://vm-jenkins-test-12.nnov.opencascade.com:8080/view/master-CR32253-OAN/view/COMPARE/

According to the test results, none of the proposed patches passed the tests.

Yes, what do you think about further steps, should we wait for the patch #0027457 as a common solution or, maybe, some ideas regarding finalization of this one?

So, I again propose to close this bug.

> So, I again propose to close this bug.
OK, if solving the issue requires unjustified efforts for use case, that we would like to disallow at all, then it looks unreasonable pushing it forward.

Dear Commenter 1, please close this bug.

Dear Mikhail, Oleg and kgv,

thanks a lot for looking into the issue, considering my fix and proposing other fixes. We will then fix the issue on our end avoiding the scaled shapes to be produced.

[signature removed]
Dima

Branch [archived branch] has been deleted by Commenter 4.

[revision removed]

Branch [archived branch] has been deleted by Commenter 3.

[revision removed]

Branch [archived branch] has been created by [email removed] in OCCT Products internal repository.

[revision removed]

Branch [archived branch] has been updated by [email removed] in OCCT Products internal repository.

[revision removed]

Branch [archived branch] has been deleted by Participant.

[revision removed]