DiscussionsIssue archiveOCCT:Visualization

Archived issue #0024926

MeshVS - improve generation of primitive arrays

Open CASCADEOCCT:Visualizationclosed17 public notes

Search issues

Description

The major issue regarding the current implementation of PrsBuilders in MeshVS package is that they produce primitive arrays that result in exactly N calls to glDrawArrays() OpenGL function in wireframe and shading modes, where N is the number of mesh faces.
And this number becomes 2*N when mesh face outlines are visible in shading mode (the default).
An example is MeshVS_MeshPrsBuilder::BuildElements() method, however other builders follow the same practice.
Such a huge number of OpenGL rendering calls is a bad practice.

The following MeshVS improvements are required:

1. Decompose mesh faces into triangles at MeshVS level and use arrays of triangles rather than arrays of polygons with arbitrary vertex number for shaded mesh representation, and arrays of lines instead of arrays of polylines in wireframe mode. Like this, the whole mesh will be drawn with 1-2 OpenGL calls (like it is done in AIS_Shape now).

The array of lines should avoid duplication of the same edges - hash map with pair of integer keys and symmetric hasher can be used for this purpose.

2. Avoid duplication of mesh vertex coordinates data and use glDrawElements() rather than glDrawArrays() - this point is less critical but still it should be analyzed (at least).

Classes to be revised:
MeshVS_ElementalColorPrsBuilder
MeshVS_MeshPrsBuilder
MeshVS_NodalColorPrsBuilder
MeshVS_VectorPrsBuilder (to be checked at least)

Additional information

Results of performance improvement can be found in Attachment 1 (PDF) attached.

Public activity

17 archived notes

Participants are labeled by their role within this record.

01Commenter 1
Dear san,

please review the patch in branch CR24926_1.
02Commenter 2
Branch CR24926_1 reviewed with the following remarks:
1. As agreed, please add a comment to related MeshVS_*PrsBuilder.cxx (or .cdl) explaining why indexed arrays of primitives are not efficient here.
2. MeshVS_VectorPrsBuilder class still uses polylines and bounds - should be optimized.
03Commenter 3
Dear san,

please review the patch in branch CR24926_2.
04Commenter 4
Branch CR24926_2 reviewed without remarks, ready for testing.
05Commenter 5
Performance comparison is available in attached file 'Attachment 1 (PDF)'.
06Commenter 6
Dear Commenter 1,

Branch CR24926_2 (and products from GIT master) was compiled on Linux platform.
[revision removed]

Number of compiler warnings:
occt component :
Linux: 33 (16 on master)

There are new additional compilation warnings:

Handle_Standard_Transient.hxx:145, GNU C Compiler 4 (gcc), Priority: Normal
dereferencing pointer ‘aSVer’ does break strict-aliasing rules

MeshVS_SymmetricPairHasher.hxx:19, GNU C Compiler 4 (gcc), Priority: Normal
suggest parentheses around ‘&&’ within ‘||’

MeshVS_ElementalColorPrsBuilder.cxx:279, GNU C Compiler 4 (gcc), Priority: Normal
enumeration value ‘MeshVS_ET_0D’ not handled in switch

MeshVS_ElementalColorPrsBuilder.cxx:279, GNU C Compiler 4 (gcc), Priority: Normal
enumeration value ‘MeshVS_ET_Node’ not handled in switch

MeshVS_ElementalColorPrsBuilder.cxx:279, GNU C Compiler 4 (gcc), Priority: Normal
enumeration value ‘MeshVS_ET_NONE’ not handled in switch

MeshVS_ElementalColorPrsBuilder.cxx:279, GNU C Compiler 4 (gcc), Priority: Normal
enumeration value ‘MeshVS_ET_All’ not handled in switch

MeshVS_ElementalColorPrsBuilder.cxx:279, GNU C Compiler 4 (gcc), Priority: Normal
enumeration value ‘MeshVS_ET_Element’ not handled in switch

MeshVS_MeshPrsBuilder.cxx:266, GNU C Compiler 4 (gcc), Priority: Normal
enumeration value ‘MeshVS_ET_NONE’ not handled in switch

MeshVS_MeshPrsBuilder.cxx:266, GNU C Compiler 4 (gcc), Priority: Normal
enumeration value ‘MeshVS_ET_All’ not handled in switch

MeshVS_MeshPrsBuilder.cxx:266, GNU C Compiler 4 (gcc), Priority: Normal
enumeration value ‘MeshVS_ET_Element’ not handled in switch

MeshVS_MeshPrsBuilder.cxx:266, GNU C Compiler 4 (gcc), Priority: Normal
enumeration value ‘MeshVS_ET_0D’ not handled in switch

MeshVS_MeshPrsBuilder.cxx:266, GNU C Compiler 4 (gcc), Priority: Normal
enumeration value ‘MeshVS_ET_Node’ not handled in switch

MeshVS_NodalColorPrsBuilder.cxx:245, GNU C Compiler 4 (gcc), Priority: Normal
enumeration value ‘MeshVS_ET_All’ not handled in switch

MeshVS_NodalColorPrsBuilder.cxx:245, GNU C Compiler 4 (gcc), Priority: Normal
enumeration value ‘MeshVS_ET_Element’ not handled in switch

MeshVS_NodalColorPrsBuilder.cxx:245, GNU C Compiler 4 (gcc), Priority: Normal
enumeration value ‘MeshVS_ET_0D’ not handled in switch

MeshVS_NodalColorPrsBuilder.cxx:245, GNU C Compiler 4 (gcc), Priority: Normal
enumeration value ‘MeshVS_ET_Node’ not handled in switch

MeshVS_NodalColorPrsBuilder.cxx:245, GNU C Compiler 4 (gcc), Priority: Normal
enumeration value ‘MeshVS_ET_NONE’ not handled in switch


There is extraction error in products part:

Error : the deferred method TDF_Attribute::Paste(TDF_Attribute,TDF_RelocationTable) must
Error : have an implementation in class OMFCAF_TMesh
Error : Check of OMFCAF has failed
Error : Failed during execution

Info : Failed OMFCAF (xcpp.fill xcpp.src xcpp.header xcpp.template obj.inc obj.comp obj.idep )
07Commenter 7
Dear san,

compilation warnings were fixed. Please check the patch in branch CR24926_2.
08Commenter 8
Branch CR24926_2 reviewed without remarks, ready for testing.
09Commenter 9
Dear Commenter 1,

Branch CR24926_2 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested.
[revision removed]

Number of compiler warnings:

occt component :
Linux: 15 (15 on master)
Windows: 0 (0 on master)
MacOS: 199 (199 on master)

products component :
Linux: 11 (11 on master)
Windows: 2 (2 on master)

Regressions/Differences:
http://occt-tests/CR24926-2-master-occt/Debian60-64/bugs/xde/bug23193.html
http://occt-tests/CR24926-2-master-occt/Windows-32-VC9/bugs/xde/bug23193.html
bugs xde(005) bug23193: FAILED

Testing cases:
Not needed

Testing on Linux:
Total MEMORY difference: 350273556 / 349917692
Total CPU difference: 54457.35999999988 / 52501.220000000074

Testing on Windows:
Total MEMORY difference: 376895600 / 377431628
Total CPU difference: 39075.609375 / 39670.796875

There are following differences in images found by testdiff.
http://occt-tests/CR24926-2-master-occt/Debian60-64/diff-Debian60-64.html
http://occt-tests/CR24926-2-master-occt/Windows-32-VC9/diff-Windows-32-VC9.html
IMAGE bugs xde bug2: bug23193_Driver1_Viewer1_View1.png differs
10Commenter 2
Branch [archived branch] has been updated by Participant.

[revision removed]
11Commenter 11
Dear san,

please review bug fix in branch CR24926_2.
12Commenter 12
Branch CR24926_2 reviewed without remarks, ready for testing.
13Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
14Commenter 14
Dear Commenter 1,

Branch CR24926_2 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested.
[revision removed]

Number of compiler warnings:

occt component :
Linux: 15 (15 on master)
Windows: 0 (0 on master)
MacOS: 196 (196 on master)

products component :
Linux: 11 (11 on master)
Windows: 1 (1 on master)

Regressions/Differences:
No regressions/differences

Testing cases:
Not needed

Testing on Linux:
Total MEMORY difference: 351460552 / 351968492
Total CPU difference: 47571.94999999992 / 46305.24

Testing on Windows:
Total MEMORY difference: 238740824 / 239134364
Total CPU difference: 34843.328125 / 35090.21875

There are no differences in images found by testdiff.
15Commenter 2
Branch [archived branch] has been deleted by Participant.

[revision removed]
16Commenter 2
Branch [archived branch] has been deleted by Participant.

[revision removed]
17Commenter 2
Branch [archived branch] has been deleted by Participant.

[revision removed]

Related records