About mesh regressions in OCC 6.5.0

[Denis Barbier]

Hello,

My understanding of the discussion
http://www.opencascade.org/org/forum/thread_20076/
on the OCC forum is that there is a bug in the new mesher, and I want
to investigate this issue.

If you notice this behavior, please send shapes which produce much
more triangles with 6.5.0 than with 6.3.0. If possible, try to
produce a minimal working example.
Thanks

Denis

[Jerome Robert]

Hi Denis,

Here is a simple program to reproduce the bug. It meshes a torus with
different radius, as a prim surface and as nurbs surface.

out-vanilla.txt is the output of the program with the vanilla occ 6.5
and out-patched.txt is the output with this patch applied:
http://git.debian.org/?p=debian-science/packages/opencascade.git;a=blob_plain;f=debian/patches/submitted/workaround-bug-mesher.patch;hb=HEAD

Jerome

[Thomas Paviot]

Hi Jérôme,

Thanks for this interesting feedback. For your information, I ported your program to python and executed it with pythonocc-0.5 (based upon occ 6.3.0). The program name is 'bugocc.py', the output is attached as 'out-vanilla-occ630.txt'.

I attached as well the diff from the 6.3.0 version of BRepMesh_FastDiscret.cxx to the 6.5.0 version.

No idea about what's wrong however.

Thomas

[Thomas Paviot]

Note that the results I get are *very* similar to yours when running the patched BRepMesh_FastDiscret (I can't explain the small difference in the number of triangles though).

Can we conclude that your workaround *fix* the issue?

Thomas

2011/4/26 Thomas Paviot <tpa...@gmail.com>

[Jerome Robert]

Not realy, I disabled the BSpline mesher and now it fallback to the
generic mesher. I guess that OCC guys wrote a specific BSpline mesher
for performance reasons. As most of faces are BSpline in today's
geometries, it was probably a good idea. That's why I call this a
workaround and not a fix.

Diffing 6.3 and 6.5 on this file won't help much as it's a complete
rewrite. Finding a good fix will require to go deeply into the code.
Anyway this workaround satisfies me for now, so I don't think I will
investigate more.

Unless someone find something better, this workaround should probably
be included in OCE.

Jerome

On Tue, Apr 26, 2011 at 4:15 PM, Thomas Paviot <tpa...@gmail.com> wrote:
> Note that the results I get are *very* similar to yours when running the
> patched BRepMesh_FastDiscret (I can't explain the small difference in the
> number of triangles though).
>
> Can we conclude that your workaround *fix* the issue?
>
> Thomas
>
> 2011/4/26 Thomas Paviot <tpa...@gmail.com>
>>
>> Hi Jérôme,
>>
>> Thanks for this interesting feedback. For your information, I ported your
>> program to python and executed it with pythonocc-0.5 (based upon occ 6.3.0).
>> The program name is 'bugocc.py', the output is attached as
>> 'out-vanilla-occ630.txt'.
>>
>> I attached as well the diff from the 6.3.0 version of
>> BRepMesh_FastDiscret.cxx to the 6.5.0 version.
>>
>> No idea about what's wrong however.
>>
>> Thomas
>>

>> 2011/4/26 Jerome Robert <jrobe...@gmail.com>

[Denis Barbier]

On 2011/4/26 Thomas Paviot wrote:
> Note that the results I get are *very* similar to yours when running the
> patched BRepMesh_FastDiscret (I can't explain the small difference in the
> number of triangles though).
>
> Can we conclude that your workaround *fix* the issue?

Hello,

BRepMesh_FastDiscretFace::InternalVertices looks like this pseudo-code:
if (planar face without relimitation)
<compute method 1>;
else if (sphere)
<compute method 2>;
else if (cylinder)
<compute method 3>;
else if (cone)
<compute method 4>;
else if (torus)
<compute method 5>;
else if (Bspline or Bezier surface)
<compute method 6>;
else
<compute method 7>;

Results are degraded (and meshing may even fail) when method 6 is
used. If you carefully look at bugocc.cxx, you will see that Jerome
had to convert the torus into a nurbs to exhibit this bug, otherwise
method 5 would be used.
The proposed workaround is to never use method 6 and always fall back
to the more general case with method 7. This should work fine (which
is why I applied his patch in Debian), but results would hopefully be
better (ie. lower number of triangles with the same deflection) if we
can fix method 6 instead.

Denis

[QbProg]

In my experience (using the tweak in production code) disabling method
6 is not enough, it still generates too many triangles in most cases
(surely it mitigates the problem a bit, but doesn't solve it).

In BRepMesh_FastDiscretFace , at line 1270 there is a
Standard_Integer myNbIterations = 11;

I don't know where 11 came from, but lowering it to 5-6 makes the
result much similar to 6.3 (time+triangle count).
This and possibly the other tweak let the mesher perform much better,
at least for visualization. Surely there's a loss in precision that
can be solved with a bit stricter tolerance.

{
It seems that myNbIterations is the count of successive triangle
collapse iterations (still not done on the final mesh, but on a simple
single-triangle basis). At each iteration more vertexs are inserted
until the desired precision if found. From my POV this criteria is not
really working , since more (possibly useless) vertexs are inserted
each time, even if not required. Finally , all the vertexs are passed
to the delaunay algorithm.
}

The dramatic bottlenek is the delaunay algorithm, that could not
handle more than 20000 triangles without a huge performance penalty.
I wonder if other implementation could perform better...

I won't disable method 6 by default, maybe we can #ifdef all the
mesher tweaks until we get a reasonable solution?

Qb

2011/4/26 Denis Barbier <bou...@gmail.com>: