View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0023519 | Community | OCCT:Visualization | public | 2012-11-07 15:38 | 2016-12-09 16:39 |
Reporter | Pawel | Assigned To | bugmaster | ||
Priority | normal | Severity | minor | ||
Status | closed | Resolution | fixed | ||
Platform | Windows | OS | VC++ 2008 | ||
Product Version | 6.5.4 | ||||
Target Version | 7.1.0 | Fixed in Version | 7.1.0 | ||
Summary | 0023519: Mixing wireframe and shaded visualization impacts performance | ||||
Description | As 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 Reproduce | I 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); } } } myAISContext->UpdateCurrentViewer(); pload MODELING VISUALIZATION vinit View1 vclear vaxo 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 vfit vfps vsetdispmode 1 vfps 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 } } } vfps | ||||
Tags | No tags attached. | ||||
Test case number | |||||
related to | 0023457 | closed | kgv | Community | Slow text rendering |
related to | 0023474 | closed | bugmaster | Community | Changing material/color/transparency of a shaded AIS_Shape requires 'Redisplay' |
related to | 0024307 | closed | apn | Open CASCADE | TKOpenGl - efficient culling of large number of presentations |
related to | 0022618 | assigned | Open CASCADE | Visualization - Tool for building generic wireframe representation of a face | |
related to | 0025463 | assigned | Open CASCADE | Visualization - MeshVS_ElementalColorPrsBuilder produces inefficient structures for elements with unique colors | |
related to | 0027596 | closed | bugmaster | Open CASCADE | Visualization, StdPrs_WFShape - pack isolines into single group of primitives |
|
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). |
|
test_boxes.7z (1,521,463 bytes) |
|
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. |
|
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. |
|
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. |
|
*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. |
|
Patch for 0027596 implements several performance improvements for Wireframe presentation. |
|
Dear bugmaster, please switch bug into VERIFIED state (considering improvements in scope of 0027596). |
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 |
|
Note Added: 0022140 | |
2012-11-08 11:11 |
|
Assigned To | bugmaster => Pawel |
2012-11-08 11:48 |
|
Status | new => feedback |
2012-11-08 17:05 | Pawel | File Added: test_boxes.7z | |
2012-11-08 17:15 | Pawel | Steps to Reproduce Updated | |
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 | |
2012-11-08 17:26 | Pawel | Note Edited: 0022157 | |
2012-11-08 17:26 | Pawel | Assigned To | Pawel => san |
2012-11-08 17:26 | Pawel | Status | assigned => feedback |
2012-11-15 20:32 |
|
Note Added: 0022274 | |
2012-11-15 20:32 |
|
Status | feedback => assigned |
2012-11-15 20:35 |
|
Note Edited: 0022274 | |
2012-11-15 20:36 |
|
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 |
|
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 | |
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 | |
2014-04-11 15:16 | kgv | Note Edited: 0028796 | |
2014-04-11 15:19 | kgv | Note Edited: 0028796 | |
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-09 16:30 |
|
Status | verified => closed |
2016-12-09 16:39 |
|
Fixed in Version | => 7.1.0 |