Rendering issues on GL4RenderWindow with multiple GL4Viewports
Summary
In some systems, having a GL4RenderWindow with 2 or more GL4Viewports shows severe flickering on screen and/or extra objects in the frame. This may be observed by running the MultiViewportTest.
Expected Behavior
The scene should be rendered correctly into each individual Viewport. Scenes rendered into one Viewport should not interfere with scene rendered into other Viewports. (See reference.)
Observed Behavior
The scene is rendered incorrectly, sometimes showing objects in a Viewport that are not supposed to be in it, incorrect Viewport divisions, or just a severe amount of flickering. (See reference.)
Steps to Reproduce
Normally launch the MultiViewportTest. There're no specific steps to reproduce this issue. If the system is affected, the issue will be noticeable upon launching the test case.
Environment and System Information
| Field | Value |
|---|---|
| Most Recent Engine Version without the Issue | d8b0fdcded59b1c165fd89de3c519d36ec5b019a |
| Engine Version that introduced the Issue | 49e879f5263ee1d15a479cbd51b9ea068629f8e0 |
| OS Name/Version/Architecture | Several. See Notes section. |
| Java Version (JDK) | Several. See Notes section. |
| Java Version (JVM) | Several. See Notes section. |
| GPU Name/Memory (in GBs) | Several. See Notes section. |
| GPU Driver Version | Several. See Notes section. |
Other Notes and/or Workarounds
The issue is only visible when there're multiple Viewports in a RenderWindow, so the workaround is to use only one Viewport. It's been suggested that it's due to a buffer-clearing issue, although nothing in the documentation/discussions suggested the original process for manual buffer clearing/swapping was incorrect, and it was indeed working in some systems. It was discovered during routine testing by moving from the laptop to the desktop.
The issue does not always look the same. The actual artifacts observed are known to vary based on details such as
- operating system
- JVM implementation
- GPU chipset
The issue has been observed in some software/hardware platform combinations, so I've added them to the tables below.
Configurations with Issues Confirmed
| OS1 | GPU ID | Driver ID | Java ID |
|---|---|---|---|
| K/Ubuntu 16.10 | 1,4 | 3,6 | 1,3 |
| Windows 7 | 1 | 2 | 2 |
| Windows 8 | 4 | 5 | 3 |
Configurations with Issues Not Confirmed2
| OS1 | GPU ID | Driver ID | Java ID |
|---|---|---|---|
| K/Ubuntu 16.10 | 2,3 | 1,4 | 1,3 |
Dependencies
| GPU ID | GPU |
|---|---|
| 1 | NVIDIA GTX-770 2GB |
| 2 | NVIDIA GTX-960M 2GB |
| 3 | NVIDIA GTX-580 2GB |
| 4 | AMD RADEON R5 |
| Driver ID | Vendor | Driver (Platform) |
|---|---|---|
| 1 | NVIDIA | 367.57 (Laptop) |
| 2 | NVIDIA | 373.06 (Desktop) |
| 3 | NVIDIA | 375.26 (Desktop) |
| 4 | NVIDIA | 375.39 (Laptop) |
| 5 | ATI | 15.200.1062.1004 |
| 6 | MESA3D | 3.0 Mesa 17.1.0-devel |
| Java ID | JDK | JVM | JRE |
|---|---|---|---|
| 1 | openjdk version "1.8.0_121" | OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode) | OpenJDK Runtime Environment (build 1.8.0_121-8u121-b13-0ubuntu1.16.10.2-b13) |
| 2 | Java 8 Update 66 (build 1.8.0_66-b18) | Java HotSpot 64-Bit Server VM (build 25.66-b18, mixed mode) | Java SE Runtime Environment (build 1.8.0_66-b18) |
| 3 | Java Version: 1.8.0_121 (1.8.0u121) | OpenJDK 64-Bit Server | OpenJDK Runtime Environment |
References
There was some discussion about this issue in this JOGL forum thread
Error Logs and/or Screenshots
Picture samples include errors and correct reference.
Issue Sample 1
Issue Sample 2
Correct Scene Reference
-
All are 64-bit systems.
-
No observations during tests (yet?).
Activity
Based on what I could test, commit 14c681b408c1a81c4551db4d97dcb7ff775bd8d1 seems to have resolved the problem, at least on the OS/GPU combinations I have available:
- GTX-960M + GNU/Linux (Ubuntu 17.04 amd64)
- GTX-960M + Windows 10
- GTX-770 + GNU/Linux (Ubuntu 17.04 amd64)
- GTX-770 + Windows 7
The odd thing is that this simply reverts commit 55bcea2efd78fb2272aaffea161a1e5c4f6d2690, which always seemed correct and consistent with available documentation, begging the question as to why the issue even showed up in the first place.
-
The issue was recently observed again in my GTX-770 + GNU/Linux (Ubuntu 17.04 amd64).
It's not clear why the issue was not observed after several attempts to reproduce it before closing this, but it was traced back to commit 14c681b408c1a81c4551db4d97dcb7ff775bd8d1.
However, simply reverting this commit is not enough. It causes the
GLEventListenerto automatically swap buffers multiple times per frame, which was the reason for the change in the first place, and makes animations look choppy in the GTX-770/Linux combination above.I'll wait until any commits addressing the issue have been tested in a wider array of OS/GPU combinations before closing the issue.
-
The Linux/GTX-960M and Windows 7/10 setups (even in GTX-770) are not (yet?) showing the issue and I've been unable to reproduce it there since the issue was re-opened.
The names and content of some tests have changed. The test cases below are those who've exhibited the issue before, and include reference screenshots of what they're supposed to look like (taken in Linux/GTX-960M).
MultiCameraSceneTest
HierarchicalNodeTransformTest
CameraNodeMovementTest
Edited by username-removed-557373