Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0023519Community[OCCT] OCCT:Visualizationpublic2012-11-07 15:382016-12-09 16:39
Assigned Tobugmaster 
PlatformWindowsOSVC++ 2008OS Version32 bit
Product Version[OCCT] 6.5.4 
Target Version[OCCT] 7.1.0Fixed in Version[OCCT] 7.1.0 
Summary0023519: Mixing wireframe and shaded visualization impacts performance
DescriptionAs stated in subject, when displaying shaded objects either with face outlines (introduced in 23407) or along with some other wireframe objects slows down the visualization. I think this is due to the fact that the shaded objects are displayed using VBO while the others not.

I think it would be great if wireframe objects could also be visualized using VBO.
Steps To ReproduceI have attached a file demonstrating the problem: 20 x 20 x 20 = 8000 cubes.

Load the file in draw and try to navigate (rotate, move, zoom) in the viewer in the following cases:

1) shaded mode -> result: very good performance
2) shaded mode with 'SetFaceBoundaryDraw(Standard_True)' -> result: poor performance, cannot navigate smoothly in the viewer
3) wireframe mode -> result: poor performance, cannot navigate smoothly in the viewer

By the way, the CPU usage is 100%/1 core (one core of a multicore processor is used completely) in all three cases.

Code to create the sample model:
        int iMax, jMax, kMax;
    iMax = jMax = kMax = 20;
    Standard_Real xL = 10., yL = 10., zL = 10.;

    for(int i = 0; i < iMax; i++)
        for(int j = 0; j < jMax; j++)
            for(int k = 0; k < kMax; k++)
                TopoDS_Shape box = BRepPrimAPI_MakeBox(gp_Pnt(i * xL, j * yL, k * zL), xL, yL, zL);
Handle (AIS_InteractiveObject) AISshape = new AIS_Shape(box);
                myAISContext->Display(AISshape, Standard_False);
                myAISContext->SetDisplayMode(AISshape, AIS_Shaded, Standard_False);

vinit View1
vsetdispmode 0
chrono t reset
chrono t start
set dim 20
for {set x 1} {$x < $dim} {incr x} { for {set y 1} {$y < $dim} {incr y} { for {set z 1} {$z < 
$dim} {incr z} { box b${x}_${y}_${z} $x $y $z 0.5 0.3 0.2 } } }
chrono t stop
chrono t show
chrono t reset
chrono t start
for {set x 1} {$x < $dim} {incr x} { for {set y 1} {$y < $dim} {incr y} { for {set z 1} {$z < 
$dim} {incr z} { vdisplay -noredraw b${x}_${y}_${z} } } }
chrono t stop
chrono t show
vsetdispmode 1

for {set x 1} {$x < $dim} {incr x} { for {set y 1} {$y < $dim} {incr y} { for {set z 1} {$z < 
$dim} {incr z} { vshowfaceboundary b${x}_${y}_${z} 1 1 1 1 } } }

TagsNo tags attached.
Test case number
Attached Files7z file icon test_boxes.7z (1,521,463 bytes) 2012-11-08 17:05

- Relationships
related to 0023457closedkgv Community Slow text rendering 
related to 0023474closedbugmaster Community Changing material/color/transparency of a shaded AIS_Shape requires 'Redisplay' 
related to 0024307closedapn Open CASCADE TKOpenGl - efficient culling of large number of presentations 
related to 0022618assignedsan Open CASCADE Tool for building generic wireframe representation of a face 
related to 0025463assignedkgv Open CASCADE Visualization - MeshVS_ElementalColorPrsBuilder produces inefficient structures for elements with unique colors 
related to 0027596closedbugmaster Open CASCADE Visualization, StdPrs_WFShape - pack isolines into single group of primitives 

-  Notes
san (developer)
2012-11-08 11:09

Dear Pawel,

Could you please provide some details about the scenario that can be used to reproduce the problem?
Is it possible to estimate the scene complexity in terms of the numbers of triangles and line segments:
- for shaded object(s) only
- for shading with boundaries or shading + wireframe

Also some - at least rough - CPU time measurements would be appreciated a lot.

Performance problems are of the kind that is sometimes difficult to diagnose, due to lots of various aspects that affects this (including the execution environment, current system load, etc.). Thus I am afraid we will not be able to analyze the issue without the above-mentioned information.

By the way, is not it logical that adding a number (that can be large!) of line primitives to the 3D scene slows it down? Expecting zero impact on performance is disputable, indeed.

And after all, just for your information, all AIS_Shape presentations are drawn using primitive arrays (and VBOs if they are available).
Pawel (developer)
2012-11-08 17:23
edited on: 2012-11-08 17:26

Dear Sergey,

thanks for your comments and sorry for not being precise.

If the wireframe presentation is also rendered using VBO then the bottleneck must be somewhere else. But I'm afraid there is definitely one.

The point is that rendering lines seems to be rather slow. (In a way it is similar to the problem with text rendering but I can't tell if the reason is the same).

I have updated the issue description and uploaded a test model to let you diagnose the case.

Tested on WinXP 32bit/Win7 64bit with NVIDIA Quadro(s).

Hope this helps.
If you have any questions or can't reproduce the bahaviour, please let me know.

san (developer)
2012-11-15 20:32
edited on: 2012-11-15 20:35

Dear Pawel,

Your sample model contains N=8000 boxes, or 6*N=48000 rectangular planar faces, or 12*N=96000 unique edges (line segments).

Shaded presentation contains 2*6*N=96000 triangles. Even for low-end graphic hardware it is not at all a challenge to render 100K triangles. In particular, triangle rasterization takes the current zoom level into account, thus if some triangles become too small, only some of them are drawn, depending on pixel coverage for adjacent triangles. So if shaded geometry is zoomed out, the frame rate increases significantly, as a rule.

Wireframe presentation contains 12*N=96000 line segments minimum. If you turn isolines on, you end up with (Uisos+Visos)*Nbfaces extra line segments. So even without isolines you have the same number of primitives to be rasterized. And unlike triangles, line segments are rasterized with a constant pixel width, irrespective of the current zoom level, and also a line should always "look like a line" that obviously implies extra computations for the graphic hardware.
As a matter of fact, wireframe geometry is drawn significantly slower by mainstream hardware.

On the other hand, after having a deeper look inside StdPrs_ShadedShape.cxx and Prs3d_WFShape.gxx, the following points can be noticed:

1. Shading - a single Graphic3d_ArrayOfTriangles instance is created for the whole shape's triangulation, the code looks optimal here.

2. Shading + face boundaries on - additional Graphic3d_ArrayOfSegments instance is created to hold the boundaries geometry. At TKOpenGl level, such an array is drawn using a single glDrawElements() call so the code looks optimal.

3. Wireframe - edges are grouped into standalone ones, free boundary edges and shared edges. Each group is drawn using a single Graphic3d_ArrayOfPolylines instance. But geometry is put to the array as a set of "boundaries", not as vertex indices ("edges") - one "boundary" per edge. As a result, shared vertices are passed several times to the graphic card, so instead of 8*N=64000 vertices 3*8*N=192000 vertices are passed (each vertex is shared by three edges). Fortunately, this happens only once when VBO is created. And to kill performance completely, at TKOpenGL level each "boundary" is drawn as a separate glDrawArrays() call so we have 96000 glDrawArrays() calls for your shape.

So the preliminary conclusion is that in general you should not expect too much from line rasterization with respect to performance, in particular when you turn the face boundaries on. But Prs3d_WFShape class deserves revision and certain optimization.

Pawel (developer)
2013-11-05 13:35

I've just checked the performance with IR-2013-10-24 and I think there is a noticeable improvement. Although the viewer navigation using wireframe presentation is still slower than the shaded option.
kgv (developer)
2014-04-11 15:14
edited on: 2014-04-11 15:19

*san wrote*
>> And to kill performance completely, at TKOpenGL level each "boundary" is drawn as a separate glDrawArrays() call
To slightly reduce CPU usage, polylines array with boundaries might be changed to:
- Indexed segments array (would require +50% extra memory for uint32_t indices).
- Indexed polylines array (+33% extra memory for uint32_t indices) with extra restart indices (+ extra memory depending on number of groups in array) using OpenGL3.1 features (glPrimitiveRestartIndex()).
This would possible only when no colors attached to boundaries, and might be processed automatically (with some extra time loss at VBO initialization stage).

Here is theoretical benefit statistics. Current scheme:
FPS: 25.475341387933419
CPU: 41.964268999999987 msec

Bounds disabled:
FPS: 29.921013612929649
CPU: 37.12823800000001 msec

or about +17% boost in case when performance is CPU-limited.

kgv (developer)
2016-06-17 15:09

Patch for 0027596 implements several performance improvements for Wireframe presentation.
kgv (developer)
2016-09-29 13:45

Dear bugmaster,

please switch bug into VERIFIED state (considering improvements in scope of 0027596).

- Issue History
Date Modified Username Field Change
2012-11-07 15:38 Pawel New Issue
2012-11-07 15:38 Pawel Assigned To => bugmaster
2012-11-07 15:38 Pawel Relationship added related to 0023457
2012-11-07 15:40 Pawel Relationship added related to 0023474
2012-11-08 11:09 san Note Added: 0022140
2012-11-08 11:11 san Assigned To bugmaster => Pawel
2012-11-08 11:48 abv Status new => feedback
2012-11-08 17:05 Pawel File Added: test_boxes.7z
2012-11-08 17:15 Pawel Steps to Reproduce Updated View Revisions
2012-11-08 17:23 Pawel Note Added: 0022157
2012-11-08 17:23 Pawel Status feedback => assigned
2012-11-08 17:25 Pawel Steps to Reproduce Updated View Revisions
2012-11-08 17:26 Pawel Note Edited: 0022157 View Revisions
2012-11-08 17:26 Pawel Assigned To Pawel => san
2012-11-08 17:26 Pawel Status assigned => feedback
2012-11-15 20:32 san Note Added: 0022274
2012-11-15 20:32 san Status feedback => assigned
2012-11-15 20:35 san Note Edited: 0022274 View Revisions
2012-11-15 20:36 san Relationship added related to 0022618
2013-02-20 19:28 kgv Target Version 6.6.0 => 6.7.0
2013-11-05 13:35 Pawel Note Added: 0026453
2013-12-12 10:55 san Target Version 6.7.0 => 6.7.1
2014-02-17 15:24 kgv Target Version 6.7.1 => 7.0.0
2014-04-11 09:15 kgv Steps to Reproduce Updated View Revisions
2014-04-11 09:32 kgv Relationship added related to 0024307
2014-04-11 15:14 kgv Note Added: 0028796
2014-04-11 15:15 kgv Note Edited: 0028796 View Revisions
2014-04-11 15:16 kgv Note Edited: 0028796 View Revisions
2014-04-11 15:19 kgv Note Edited: 0028796 View Revisions
2014-11-12 08:17 kgv Relationship added related to 0025463
2015-11-17 16:17 kgv Target Version 7.0.0 => 7.1.0
2016-06-13 01:07 kgv Relationship added related to 0027596
2016-06-17 15:09 kgv Note Added: 0055180
2016-09-29 13:45 kgv Note Added: 0058316
2016-09-29 13:45 kgv Assigned To san => bugmaster
2016-09-29 13:45 kgv Status assigned => feedback
2016-09-29 13:45 kgv Resolution open => fixed
2016-10-04 11:45 bugmaster Status feedback => tested
2016-10-04 11:45 bugmaster Status tested => verified
2016-12-06 09:24 kgv Relationship added related to 0027508
2016-12-09 16:30 aiv Status verified => closed
2016-12-09 16:39 aiv Fixed in Version => 7.1.0

Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker