Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0023200Community[OCCT] OCCT:Visualizationpublic2012-06-13 19:292015-02-13 12:29
Assigned Tokgv 
PlatformWindowsOSVC++ 2008OS Version32 bit
Product Version[OCCT] 6.5.3 
Target Version[OCCT] 6.8.1Fixed in Version 
Summary0023200: Visualization - prevent multiple triangulating of a shape that already has been triangulated
DescriptionWhen the AIS_InteractiveContext processes a shaded shape (e.g. Displaying) it checks whether the triangulation of the shape exists. This is performed in

StdPrs_ShadedShape::Add, line 274 using the BRepTools::Triangulation method.

There are three reasons (see BRepTools::Triangulation) why this function decides there is no valid triangulation. Those cases are:
- Poly_Triangulation is Null for a face of the checked shape
- the deflection of the Poly_Triangulation of a face is greater than the provided one
- Poly_PolygonOnTriangulation is Null for one edge of the checked shape

If one of the above occurs the triangulation of the shape is re-computed.

However, since the re-computation does not guarantee that the above conditions are met this might result in a repetitive re-computing of a shape triangulation.

This effect can be observed when displaying and then redisplaying again large models.
Steps To ReproduceAIS_InteractiveContext::SetDeviationCoefficient(0.0001)

Load the attached model.


As the deflection criterion is not met the shape will be triangulated twice.
Additional information
and documentation updates
New flag IsAutoTriangulated was added to Prs3d_Drawer. It is True by default.
If this flag is True automatic re-triangulation with deflection-check logic will be applied (previous behavior).
Else this feature will be disable and triangulation is expected to be computed by application itself.

Special wireframe presentation (with more U and V isoparametric curves) for faces without triangulation was added.

Syntax of "vdefalts" command was changed and new parameter -autoTriang was added for check of new AutoTriangulated functionality. Now it looks like this:
   vdefaults [-absDefl value] [-devCoeff value] [-angDefl value] [-autoTriang {off/on | 0/1}]
TagsNo tags attached.
Test case number
Attached Files? file icon noTriangulation01.brep (45,362 bytes) 2012-06-13 19:29
? file icon shape01.brep (2,434,558 bytes) 2014-12-16 16:08

- Relationships
related to 0023501closedPawel Community Redundant triangulation cleaning/generation (1) in AIS_Shape.cxx 
related to 0023966closedPawel Community Voxel_FastConverter performs unnecessary triangulation. 
related to 0024013closedPawel Community Voxel_FastConverter is able to use existing triangulation 
related to 0025825assignedakz Open CASCADE Draw Harness, XSDRAWSTLVRML - drop command tovrml and XSDRAWSTLVRML_ToVRML 

-  Notes
Pawel (developer)
2012-07-03 17:25

Just an observation: Methods like:


force the recomputation of the presentation for the corresponding XCAFPrs_AISObject which leads to the recomputation of the triangulation of an object under the conditions mentioned above.
Pawel (developer)
2012-11-02 17:51

I have pushed the branch CR23200 onto the server. I do not mark the issue as solved, though.

The committed change only comments out the code portion responsible for repetitive triangulation calls (this happens especially when using XDE). Additionally, I had to make sure that within our application the triangulation is generated/updated each time a shape is created/changed.

So this is rather a workaround than a solution but it might be interesting for those willing to optimize the performance in their XDE-based application.
Roman Lygin (developer)
2013-04-04 20:11

Pawel brings a valid concern and this is a case that sometimes happens indeed. OCC should foresee the way to avoid re-triangulating the face if a previous attempt with exact same input parameters failed.

My guess is that introducing an extra Standard_Real field into BRep_TFace, named something like myUsedDeflection or alike would address this issue. A value of <=0. would mean that no attempts have been made yet, while a positive value would store a value used in a previously attempt.
BRepMesh would compare a cached value against its input parameter and would skip the face if myUsedDeflection is less than or equal to that parameter.

This would add 8 bytes * Number_of_faces extra memory footprint but this should hopefully be acceptable.
Perhaps, myLocation could be removed from the BRep_TFace as locations are attached to TopoDS_Shapes anyway. This would save at least 4 or 8 bytes depending on the architecture.
abv (manager)
2013-04-05 08:53

Yes that's pretty logical, just Poly_Triangulation is better candidate for adding this field.
Roman Lygin (developer)
2013-04-05 10:07

Not quite. Poly_Triangulation can be null if the triangulation failed. So the value has to be stored upstream - that's why BRep_TFace has been suggested.
Pawel (developer)
2013-04-05 12:52

Well, to tell the truth this issue is really critical in my opinion.

We use XDE to handle complete car bodies in our application. It takes ages in that case to just change a color of a face/shape because the triangulation for the whole assembly has to be recomputed.
Roman Lygin (developer)
2013-05-26 16:53

A side note. Prior to version 6.5.2 it was possible to avoid re-computation: Prs3d_ShadedShape::Add() always invoked an algorithm registered in BRepMesh_DiscretFactory. One could register a void algorithm (a subclass of BRepMesh_DiscretRoot with empty Perform() implementation) and thus no re-computation took place. Actual triangulation took place prior to visualization. This was an approach used by CAD Exchanger, for example.

As of version 6.5.2 the Prs3d_ShadedShape (which then moved to StdPrs_ShadedShape) there is an attempt to avoid re-triangulation by checking with BRepTools::Triangulation(). However in the case when already computed triangulation is more coarse than requested, it now enforces cleanup (BRepTools::Clean()) and tries to recompute. Very often this will repeatedly fail, as initial requested deflection was likely the same as current and the algorithm already failed to respect it.

Thus, in some cases (which are typically more difficult for the mesher) this optimization turns out to be a regression. The bad news is that now there is no work-around against this and one cannot avoid recomputation at all. So a fix is definitively welcome.
Pawel (developer)
2013-05-26 17:26

Dear Roman,

thanks for supporting the idea!
Roman Lygin (developer)
2013-05-26 17:57

For the XDE-based apps the negative effect of this optimization attempt (check of BRepTools::Triangulation()) is even worse.
Imagine, one has precomputed a triangulation for the entire shape S and then displays with the help of XDE (XCAFPrs_AISObject). XCAFPrs_AISObject::Compute() classifies subshapes into groups with the same attributes. A bounding box (and hence computed deflection) for each of this subshape will be less than of an entire S, so Prs3d_ShadedShape will clean up the triangulation of each group and recompute. Moreover, the polygonization of the edge shared by two faces from two different groups can be cleaned up and hence will invalidate one group. The latter will clean up all the edges inside that group and hence will propagate to the entire S. This will repeat over and over again, with every display, as deflection computed and successfully respected for a group k may be not enough for some further group k+s.
Perhaps, this is what Pawel is observing on his large assemblies.

Thinking about a possible fix, I tend to think that the verification algorithm should be user-parametrized. In some cases, it should be strict and clean up the triangulation if at least one face does not meet it. In other cases, when a developer is certain that if the triangulation is in place then it is good and it is enough to find at least one face with triangulation than to scan 100+K faces.

To achieve that the following options are possible:
1. The easiest would be to roll back to pre-6.5.2 behavior and let decision-making be a part of user-defined subclass of BRepMesh_DiscretRoot::Perform().
2. Extend BRepMesh_DiscretRoot API to explicitly support decision-making
With 0000002, Prs3d_ShadedShape would look like:

Handle(BRepMesh_DiscretRoot) aMeshAlgo = BRepMesh_DiscretFactory::Get().Discret (theShape,
if (!aMeshAlgo.IsNull() && !aMeshAlgo->AcceptTriangulation (theShape, aDeflection)) {
  BRepTools::Clean (theShape);

Default implementation of AcceptTriangulation() could call BRepTools::Triangulation() as now. XDE-based apps would have to take care to redefine this root and prebuild triangulation in advance. Not a silver bullet but still more efficient than current 6.6.0.
san (developer)
2014-09-24 16:35

Dear Pawel,

Can you please check if the patch from Git branch CR25142 resolves the issue?
My feeling is that now it should work as expected, as the triangulation is no longer cleaned if BRepTools::Triangulation() returns Standard_False.
Pawel (developer)
2014-10-15 14:27

Dear Sergey,

unfortunately I cannot confirm fixing this issue.

One problem still remains: When the deflection of the existing Poly_Triangulation of a face is greater than the provided one re-computation is still forced.

If the (re)computation fails to create a triangulation with the desired deflection it will be triggered again and again.
san (developer)
2014-12-12 16:53
edited on: 2014-12-12 17:21

Dear Pawel,

I have tried the following simple test with the shape attached to this issue:

pload ALL
restore noTriangulation01.brep s
vsetdispmode 1
vdisplay s
trinfo s
# Max deflection = 0.087

# Using 10x less deflection
incmesh s 0.01
trinfo s
# Max deflection = 0.0071

# Attach to DRAWEXE with a debugger and set a 
# breakpoint in StdPrs_ShadedShape::Tessellate() 
vdisplay s
# BRepTools::Triangulation (theShape, aDeflection) returns True -> 
# triangulation is not redone!

So I do not see any problems with the current Git master.

Thus can you please attach a shape that could be used to reproduce the problem described by you - i.e. when BRepMesh fails to create a tessellation with requested deflection and so re-triangulates the shape each time.

Or please formulate the remaining problem(s) precisely, with relevant test case(s).
We need to understand clearly what should be corrected, otherwise we cannot proceed with this issue.

Thanks in advance!
Best regards,

Pawel (developer)
2014-12-16 16:18

Dear Sergey,

I have uploaded a file to demonstrate the problem.

Running the script in DRAW shows that meshing does not result in the given deflection and so the shape might be re-meshed over and over.

trinfo s
#This shape contains 25559 triangles.
# 17138 nodes.
#Maximal deflection 0.26360344286498899

incmesh s 0.026
#Incremental Mesh, multi-threading OFF
#Meshing statuses: NoError

trinfo s
#This shape contains 47189 triangles.
# 28002 nodes.
#Maximal deflection 0.051743440306355422
kgv (developer)
2015-02-10 18:48

It is suggested to introduce new flag in Drawer to perform or not automatic triangulation.

By default, this flag would be set ON to preserve current behavior - automatic re-triangulation with messy deflection-check logic (which might be improved in future).

New applications would better switch this flag OFF to disable feature. In this case triangulation is expected to be computed by application itself (and NO shading presentation at all if unavailable).
Roman Lygin (developer)
2015-02-10 19:04

Sounds reasonable. Thank you.
git (administrator)
2015-02-13 10:18

Branch CR23200_1 has been created by osa.

SHA-1: 21c0467e48a7beef072d82979094baa56c0f5d47

Detailed log of new commits:

Author: osa
Date: Fri Feb 13 10:17:19 2015 +0300

    0023200: Visualization - multiple triangulating of a shape that already has been triangulated
osa (developer)
2015-02-13 10:20

Dear Kirill,
the patch is ready (branch CR23200_1). Please review.
kgv (developer)
2015-02-13 10:52

Please extend description of the patch in the commit.
git (administrator)
2015-02-13 11:39

Branch CR23200_1 has been updated forcibly by osa.

SHA-1: db0bdfe9af2333c26dfaded04232a2d228092826
git (administrator)
2015-02-13 12:27

Branch CR23200_2 has been created by osa.

SHA-1: 04f396865290bd68d48325b77282873538c79db4

Detailed log of new commits:

Author: osa
Date: Fri Feb 13 12:22:14 2015 +0300

    0023200: Visualization - prevent multiple triangulating of a shape that already has been triangulated
    Add new flag IsAutoTriangulated to Prs3d_Drawer. It is True by default.
    If this flag is True automatic re-triangulation with deflection-check logic will be applied.
    Else this feature will be disable and triangulation is expected to be computed by application itself.
    Change the syntax of vdefalts command.
    Add new parameter -autoTriang for check of AutoTriangulated functionality.
osa (developer)
2015-02-13 12:29

Dear Kirill,
the patch was updated (branch CR23200_2). Please review.

- Issue History
Date Modified Username Field Change
2012-06-13 19:29 Pawel New Issue
2012-06-13 19:29 Pawel Assigned To => bugmaster
2012-06-13 19:29 Pawel File Added: noTriangulation01.brep
2012-06-13 19:31 Pawel Description Updated View Revisions
2012-06-13 19:31 Pawel Steps to Reproduce Updated View Revisions
2012-06-28 18:40 Pawel Description Updated View Revisions
2012-06-28 18:40 Pawel Steps to Reproduce Updated View Revisions
2012-07-03 17:25 Pawel Note Added: 0020852
2012-11-02 17:45 Pawel Relationship added related to 0023501
2012-11-02 17:51 Pawel Note Added: 0022088
2013-04-04 20:11 Roman Lygin Note Added: 0024002
2013-04-05 08:53 abv Note Added: 0024004
2013-04-05 10:07 Roman Lygin Note Added: 0024005
2013-04-05 12:52 Pawel Note Added: 0024012
2013-05-15 19:35 Pawel Relationship added related to 0023966
2013-05-26 16:53 Roman Lygin Note Added: 0024514
2013-05-26 17:26 Pawel Note Added: 0024515
2013-05-26 17:57 Roman Lygin Note Added: 0024516
2013-06-05 14:59 Pawel Relationship added related to 0024013
2014-02-17 15:04 kgv Assigned To bugmaster => san
2014-02-17 15:04 kgv Target Version => 6.7.1
2014-02-17 15:04 kgv Summary Multiple triangulating of a shape that already has been triangulated => Visualization - multiple triangulating of a shape that already has been triangulated
2014-04-04 18:09 abv Target Version 6.7.1 => 6.8.0
2014-09-11 09:26 abv Target Version 6.8.0 => 7.1.0
2014-09-24 16:30 san Relationship added related to 0025142
2014-09-24 16:35 san Note Added: 0032098
2014-09-24 16:35 san Assigned To san => Pawel
2014-09-24 16:35 san Status new => feedback
2014-09-24 16:35 san Target Version 7.1.0 => 6.8.0
2014-10-15 14:27 Pawel Note Added: 0033133
2014-10-15 14:27 Pawel Assigned To Pawel => san
2014-10-15 14:27 Pawel Status feedback => assigned
2014-10-17 09:07 kgv Target Version 6.8.0 => 7.1.0
2014-12-12 16:53 san Note Added: 0035375
2014-12-12 16:53 san Assigned To san => Pawel
2014-12-12 16:53 san Status assigned => feedback
2014-12-12 17:21 san Note Edited: 0035375 View Revisions
2014-12-16 16:08 Pawel File Added: shape01.brep
2014-12-16 16:18 Pawel Note Added: 0035420
2014-12-16 16:18 Pawel Assigned To Pawel => san
2014-12-16 16:18 Pawel Status feedback => assigned
2015-02-10 18:48 kgv Note Added: 0037320
2015-02-10 18:48 kgv Assigned To san => osa
2015-02-10 18:48 kgv Target Version 7.1.0 => 6.8.1
2015-02-10 19:04 Roman Lygin Note Added: 0037324
2015-02-13 10:18 git Note Added: 0037474
2015-02-13 10:20 osa Note Added: 0037476
2015-02-13 10:20 osa Assigned To osa => kgv
2015-02-13 10:20 osa Status assigned => resolved
2015-02-13 10:52 kgv Note Added: 0037492
2015-02-13 10:52 kgv Assigned To kgv => osa
2015-02-13 10:52 kgv Status resolved => assigned
2015-02-13 11:39 git Note Added: 0037497
2015-02-13 11:56 kgv Summary Visualization - multiple triangulating of a shape that already has been triangulated => Visualization - prevent multiple triangulating of a shape that already has been triangulated
2015-02-13 11:57 kgv Relationship added related to 0025825
2015-02-13 12:05 osa Additional Information Updated View Revisions
2015-02-13 12:27 git Note Added: 0037499
2015-02-13 12:29 osa Note Added: 0037500
2015-02-13 12:29 osa Assigned To osa => kgv
2015-02-13 12:29 osa Status assigned => resolved

Copyright © 2000 - 2015 MantisBT Team
Powered by Mantis Bugtracker