Mantis Bug Tracker
Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0023200Community[OCCT] OCCT:Visualizationpublic2012-06-13 19:292014-09-11 09:26
ReporterPawel 
Assigned Tosan 
PrioritynormalSeverityminor 
StatusnewResolutionopen 
PlatformWindowsOSVC++ 2008OS Version32 bit
Product Version[OCCT] 6.5.3 
Target Version[OCCT] 7.1.0Fixed in Version 
Summary0023200: Visualization - 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.

AIS_InteractiveContext::Display
AIS_InteractiveContext::Redisplay

As the deflection criterion is not met the shape will be triangulated twice.
TagsNo tags attached.
Test case number
Attached Files? file icon noTriangulation01.brep (45,362 bytes) 2012-06-13 19:29

- Relationships
related to 0023501closedPawel Redundant triangulation cleaning/generation (1) in AIS_Shape.cxx 
related to 0023966closedPawel Voxel_FastConverter performs unnecessary triangulation. 
related to 0024013closedPawel Voxel_FastConverter is able to use existing triangulation 

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

Just an observation: Methods like:

XCAFPrs_AISObject::SetMaterial
XCAFPrs_AISObject::SetColor
XCAFPrs_AISObject::SetTransparency

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.
(0022088)
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.
(0024002)
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.
(0024004)
abv (manager)
2013-04-05 08:53

Yes that's pretty logical, just Poly_Triangulation is better candidate for adding this field.
(0024005)
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.
(0024012)
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.
(0024514)
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.
(0024515)
Pawel (developer)
2013-05-26 17:26

Dear Roman,

thanks for supporting the idea!
(0024516)
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,
                                                                                     aDeflection,
                                                                                     theDrawer->HLRAngle());
if (!aMeshAlgo.IsNull() && !aMeshAlgo->AcceptTriangulation (theShape, aDeflection)) {
  BRepTools::Clean (theShape);
  aMeshAlgo->Perform();
}

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.

- 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


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker