View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0030689 | Community | OCCT:Visualization | public | 2019-05-02 17:14 | 2019-06-04 17:58 |
| Reporter | BenjaminBihler | Assigned To | bugmaster | ||
| Priority | normal | Severity | minor | ||
| Status | closed | Resolution | no change required | ||
| Platform | A | OS | L | ||
| Product Version | 7.3.0 | ||||
| Target Version | 7.4.0 | ||||
| Summary | 0030689: Visualization - Free edges disappear depending on viewing perspective | ||||
| Description | I have tried to subclass AIS_Shape to display free edges (as proposed by kgv within issue 0030309). Everything works fine except that coincident edges of different shapes within a TopoDS_Compound disappear as soon as the shape is viewed from the top or bottom perspective. This "feels like" an OCCT visualization error. I hope very much that I do not keep you busy with errors of my own code. I have struggled a lot to create a minimum example showing the problem. Therefore I have modified the Qt Tutorial sample. Please check the steps to reproduce. | ||||
| Steps To Reproduce | - Replace DocumentTut.cxx of the Qt Tutorial sample with the uploaded file. - Compile and run the sample. - Press the bottle creation button. Now four shells are displayed including there free edges. - Switch to the "Top" or "Bottom" viewing perspective. The free edges within the compound disappear (they are still free edges of the respective shells). - When using "Dynamic Rotation" to rotate the scene slightly, the free edges reappear immediately. pload MODELING VISUALIZATION box b1 -10 0 0 10 10 1 box b2 0 0 0 10 10 1 box b3 20 0 0 10 10 1 box b4 30 0 0 10 10 1 explode b1 F explode b2 F compound b1_5 b2_5 c1 compound b1_5 b2_5 c2 explode b3 F explode b4 F vclear vinit View1 -width 1000 -height 390 vcamera -persp vdisplay -dispMode 0 c1 vdisplay -dispMode 1 c2 b3_5 b4_5 vtop vfit vaspects b3_5 b4_5 -faceBoundaryDraw 1 -faceBoundaryColor RED -faceBoundaryWidth 1 #vpolygonoffset c2 1 1 1 #vdisplay -dispMode 1 -redisplay c2 | ||||
| Tags | No tags attached. | ||||
| Test case number | |||||
|
|
DocumentTut.cxx (8,069 bytes) |
|
|
From description it looks like you see the issue visually. If it is the case - please attach screenshots with the problem. |
|
|
AxoPerspective.jpg (62,317 bytes) |
|
|
TopPerspective.jpg (48,286 bytes) |
|
|
The screenshot "AxoPerspective.jpg" is as expected. The screenshot "TopPerspective.jpg" shows the problem: the coincident free edges of the compound disappear completely in this perspective. |
|
|
I suppose that you observe issue only on flat 2D geometry? |
|
|
Up to now I have observed in only on flat 2D geometry, yes. |
|
|
Then this is a duplicate of 0026154. The problem is that Z-fit creates a too tight Z Range on 2D geometry leading to frustum clipping (rotating camera or adding some dummy geometry at the different depth reveals clipped elements). The formula within ZFit should be reconsidered or extended with some minimal values to avoid this issue - you can take a look onto Graphic3d_Camera::ZFitAll() implementation. |
|
|
Are you sure? If it was a frustum clipping problem, then shouldn't all 2D objects in the same plane be treated equally, if I am looking onto that plane from a top view? But all edges are displayed correctly as long as they are not coincident edges within one compound. As a quick test I have added or subtracted test values (1.0 and 100.0) from theZNear and theZFar in Graphic3d_Camera::ZFitAll(), but that hasn't changed anything. |
|
|
Besides, I have an installation of OCE (the community edition) based upon OCCT 6.8.0 here. With that library my real application (I have not tested the Tutorial sample) doesn't show this error. |
|
|
> Besides, I have an installation of OCE (the community edition) > based upon OCCT 6.8.0 here. The issue is reproducible on vanilla OCCT 6.8.0 in Draw Harness (see test script) and I don't recall any visualization-specific corrections in OCE. |
|
|
> Are you sure? > If it was a frustum clipping problem, then shouldn't all 2D objects > in the same plane be treated equally, if I am looking onto that plane > from a top view? But all edges are displayed correctly as long > as they are not coincident edges within one compound. I agree, this issue is unrelated to Z-Range - it is related to polygon offset settings. https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glPolygonOffset.xhtml http://www.glprogramming.com/red/chapter06.html#name4 Polygon offsets is a hack in graphics to workaround rendering issues of objects on the same depth. Triangles+lines combination makes this issue very nasty, because depth values for lines are computed differently by graphics than for triangles, so that even when you draw line edges on exact triangle nodes, the depth might not match and lines are often overlapped by triangles. This is why OCCT enables polygon offset by default. Default polygon offset settings within OCCT are [Mode: Aspect_POM_Fill, Factor: 1.0; Units: 0.0]. Understanding polygon offset parameters is difficult, but if you take a look onto referred article, you will see how they hit in our case: > For polygons that are parallel to the near and far clipping planes, > the depth slope is zero. For the polygons in your scene > with a depth slope near zero, only a small, constant offset is needed. So that since OCCT defines only Factor (which becomes 0 in Top view) while Units is 0, the polygon offset has no effect on rendered primitives. In your test case this means that triangles and lines are rendered with exact same depth, so that visual result depends on rendering order - the last rendered object overwrites previously drawn. And your code explicitly draws free edges first and then triangles (by the way, StdPrs_ShadedShape adds Face Boundaries after Triangulation, so that this issue doesn't occur). So the possible solutions: - Adjust polygon offset parameters (define Units to non-zero value). Beware that polygon offset produces various visual artifacts depending on camera position and scene content, so that values should be played carefully. - Manually order rendered elements. If edges are expected to be drawn by the same presentation, it is obviously preferred defining the order explicitly within Compute() routine. Ordering different presentation is more tricker - it can be done via Display Priorities, ZLayers and artificial Z shift in case of 2D objects. |
|
|
Dear Kirill, both of your proposals indeed solve the problem. I have changed the ordering now, since this is obviously more elegant. This has also been the reason, why my application based on OCCT 6.8.0 didn't show the error. In OCCT 6.8.0 the code of Prs3d_WFShape looks different and when doing the different adaption I have by chance chosen the correct ordering. I have learned a lot about the internal rendering and I would have never been able to spot the problem without your help. Thank you very, very much. Since this is no OCCT bug, the issue probably should be closed. |
|
|
I have another display problem that seems to be closely related to your explanations above. My example is very similar to the Tutorial sample, but in the background there is an OCAF TDocStd_Document document. I have a shaded flat TNaming_NamedShape shell and several TPrsStd_AISPresentation presentations and child instances of TPrsStd_Driver that create AIS_InteractiveObject instances actually made up of wires for these presentations. The wires from the custom presentations are in the plane of the TNaming_NamedShape shell. When switching to the top perspective, then very often the wires are not correctly displayed. It has nothing to do with issue 0026154 which can be proved by hardcoding extreme values in Graphic3d_Camera::ZFitAll() implementation (which "solves" issue 0026154). Instead it obviously is caused by the rendering order. All of your proposals do not work here. Is it because OCAF presentations have other mechanisms that define the rendering order? I have found a solution: after switching to the top or bottom perspective, I have to iterate over all labels of my document and erase all presentations based upon wires. Then I have to iterate over the labels again and display all presentations. Then after repainting the view, the wires are correctly displayed. Erasing presentations and displaying them within the same loop does not help. Even though this sounds crazy, it is actually a workaround that I can live with. Still, it seems as if there should be a better way. Is my impression right, that the rendering order mechanisms of OCAF documents are different from those of a "pure" AIS_InteractiveContext? Are there mechanisms for defining the rendering order in OCAF documents? Or should I create a new issue for that? Thank you for your answer. |
|
|
> I have another display problem that seems to be > closely related to your explanations above. Do you have some reproducible document / Draw Harness test script? XShow currently uses TPrsStd, so that it should be technically possible reproducing the problem having an XDE document definition (exported into XBF, for example, if it is not trivial generating such in Draw Harness). I'm not familiar with TPrsStd, but I can take a look to see what happens. From my point of view, properly defined polygon offset should work regardless TPrsStd / normal AIS logic. |
|
|
Would it be okay to again modify the Tutorial sample to reproduce the problem? This probably would mean the least effort to me. I have not used XDE yet, but if it is necessary, I could try it. One statement in my former comment was wrong: introducing an artificial Z shift would obviously solve the problem. That one of your solution proposals I have not implemented, since I had the workaround. |
|
|
Okay, the solution of issue 0030716 seems to solve my visualization problem. I do not fully understand, why setting the polygon offsets has not worked here. I am creating several AIS_Shape instances and connecting them to an AIS_MultipleConnectedInteractive. Neither setting the polygon offsets of the AIS_Shapes nor setting them of the AIS_MultipleConnectedInteractive works. Maybe they are they overwritten or ignored somewhere on the way to the rendering? Anyway, I have a workaround and as soon as I use an OCCT version with the solution of 0030716, I can even omit the workaround. |
|
|
> Maybe they are they overwritten or ignored somewhere on the way to the rendering? I think there is some break between Prs3d_Drawer happening in your chain, so that indeed, Polygon Offset settings are lost. It is difficult, though, to track this issue visually, since in most cases Polygon Offset affects presentation in very different way then other attributes like colors. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-05-02 17:14 | BenjaminBihler | New Issue | |
| 2019-05-02 17:14 | BenjaminBihler | Assigned To | => kgv |
| 2019-05-02 17:14 | BenjaminBihler | File Added: DocumentTut.cxx | |
| 2019-05-02 17:15 | BenjaminBihler | Relationship added | related to 0030309 |
| 2019-05-02 22:03 | kgv | Note Added: 0084108 | |
| 2019-05-06 12:14 | BenjaminBihler | File Added: AxoPerspective.jpg | |
| 2019-05-06 12:14 | BenjaminBihler | File Added: TopPerspective.jpg | |
| 2019-05-06 12:17 | BenjaminBihler | Note Added: 0084187 | |
| 2019-05-06 12:19 | kgv | Relationship added | related to 0026154 |
| 2019-05-06 12:19 | kgv | Note Added: 0084188 | |
| 2019-05-06 12:21 | BenjaminBihler | Note Added: 0084189 | |
| 2019-05-06 12:28 | kgv | Note Added: 0084192 | |
| 2019-05-06 16:46 | BenjaminBihler | Note Added: 0084197 | |
| 2019-05-06 17:15 | BenjaminBihler | Note Added: 0084198 | |
| 2019-05-06 21:27 | kgv | Steps to Reproduce Updated | |
| 2019-05-06 21:59 | kgv | Steps to Reproduce Updated | |
| 2019-05-06 22:06 | kgv | Note Added: 0084202 | |
| 2019-05-06 22:25 | kgv | Note Added: 0084203 | |
| 2019-05-06 22:28 | kgv | Note Edited: 0084203 | |
| 2019-05-06 22:29 | kgv | Note Edited: 0084203 | |
| 2019-05-07 11:05 | BenjaminBihler | Note Added: 0084214 | |
| 2019-05-07 11:08 | kgv | Assigned To | kgv => bugmaster |
| 2019-05-07 11:08 | kgv | Status | new => feedback |
| 2019-05-07 11:09 | kgv | Resolution | open => no change required |
| 2019-05-13 15:06 | BenjaminBihler | Note Added: 0084307 | |
| 2019-05-13 20:22 | kgv | Note Added: 0084318 | |
| 2019-05-13 20:22 | kgv | Note Edited: 0084318 | |
| 2019-05-14 10:00 | BenjaminBihler | Note Added: 0084326 | |
| 2019-05-17 12:19 | kgv | Relationship added | related to 0030716 |
| 2019-05-20 12:34 | BenjaminBihler | Note Added: 0084478 | |
| 2019-05-20 12:59 | kgv | Note Added: 0084480 | |
| 2019-06-04 17:58 | bugmaster | Status | feedback => closed |
| 2019-07-29 22:13 | kgv | Relationship deleted | related to 0026154 |
