Visual issues with simQt::ViewWidgets that share simVis::SceneManagers and simVis::ViewManagers

[duhbleA]

I am currently writing a Qt application that will need to use multiple instances of simQt::ViewWidgets across different widgets/windows through the runtime. In some specific cases, the ability to create a mirrored instance of a view widget that displays the previously created artifacts and platforms from a different widget the user was interacting with is needed.

Based on the examples provided in the SDK, I am creating multiple view widgets dynamically, each with their on instance of a simVis::View and sharing the same instance of the simVis::SceneManager. Each simVis::View is added to the same instance of the simVis::ViewManager. This methodology works when any "shared" instances of the view widgets are created very close together in the program execution, like a constructor or main loop. However, in an event-driven scenario where the different view widgets are created apart, I'm seeing some interesting effects.

When creating new simQt::ViewWidgets dynamically some time after the application runtime begins, the tiling of the globe behaves strangely. Specifically the globe shows up black. If you zoom in, re-tiling occurs, but significantly slower than expected. Zooming out returns the globe to black. The first instance of the view widget created in the application always renders correctly with no noticeable issues. All of the subsequent view widgets have the described problem, though.

I've been able to successfully recreate this issue using the Qt Dockable Views test, as well as a modified version of the Qt View Manager Test.

Qt Dockable View Test In this first screenshot, the Qt Dockable View Test renders the first view widget expectedly.

The second screenshot is the result of creating a new Dialog.

Modified Qt View Manager Test To debug the issue that I've been seeing, I modified the Qt View Manager Test to create two view widgets immediately after each other sharing the same instance of the simVis::SceneManager with each simVis::View added to the same simVis::ViewManager. I added a button that invokes a lambda to create a new view widget, attaches its simVis::View to the shared simVis::SceneManager, and adds the view to the same simVis::ViewManager. The same result described in the dockable test occurs.

The only useful logging information I've derived through my testing is a warning that occurs when created the second and third instances of the view widgets in the modified Qt View Manager Test:

CompositeViewer::realize() - No views to realize.

I can recreate this issue on Windows 10, openSUSE 15.2, and Cent OS 8 using these same dependencies versions:

Dependency Versions: osg - 3.6.5 osgEarth - osgearth-simdis-sdk-1.12 osgQt - 91ba61f Qt - 5.13.2

Any help would be greatly appreciated!

[emminizer]

Hi Austin. Thanks for the screenshots and the explanations on the versions. Can you provide more detail on how you have modified the test applications to reproduce the behavior you're seeing? I can take a look against OSG 3.6.5, osgEarth master, and SDK master, with Qt 5.9 to see if I see anything different, but a diff or updated file would be helpful.

Seems like you've got some sort of race condition hitting, but without debugging into OSG itself I'm not sure how much we can help. Seeing more of what you're trying to do in code form might help though.

[duhbleA]

Thanks for getting back to me so soon Daniel!

Slight modification to the dependency version. I'm using osg 3.6.5. Apologies for the mistype.

I only modified Qt View Manager Test. Specifically, TestViewManagerQt.cpp starting at line 157. They begin at the // BEGIN MODIFIED comment. Attached is the file.

TestViewManagerQt_modified.txt

EDIT: I also removed the inset creations.

[emminizer]

Thanks, got the file. The issue is that the realize operations aren't being executed because CompositeViewer::realize() has no views set up. Those realize operations are important in order to initialize certain GL features, and are likely the cause of your glitches. I'm looking now to see if there's an obvious reason why the composite viewer has no views.

[emminizer]

The issue is in the code you added. You're creating multiple view managers (one per MyMainWindow) but every time you create a new simVis::View you add it to the ViewManager associated with the first window, not with the one from your other windows. Updated code blocks:

// ...
  mainview->setSceneManager(sceneMan);
  window2.getViewManager()->addView(mainview.get());
// ...
      auto* newWindow = new MyMainWindow();
      auto* viewWidget = new simQt::ViewWidget(mainview2.get());
      mainview2->setSceneManager(sceneMan);
      newWindow->getViewManager()->addView(mainview2.get()); 
// ...

These look to just be typos.

When fixed, the paging is slower in the other view managers. That looks like an osgEarth issue. It might be due to the number of threads allocated to osgEarth. It might be due to having multiple ViewManager instances. Honestly we have never attempted to run with multiple ViewManager instances, that I can remember. If you stick with one ViewManager that might give you better results.

Hope this helps.

Edit: Forgot one of the most important lines in the copy/paste code

[duhbleA]

I was trying to reuse the view manager created from the first window as a single instances of the View Manager. Looking back, that modified example was very rough around the edges.

The Qt Dockable Views Test packaged with SIMDISSDK is identical to the use case we're trying to implement in our program's software: a single View Manager and Scene Manager for all Views and View Widgets created dynamically. Are you seeing any of the issues I described above on that example with your configuration? I can recreate it consistently with my build configuration on that test.

Edit: I should include that I have not modified the Qt Dockable View Test to see the described issue.

[emminizer]

I am seeing similar behavior in the Qt Dockable Views Test, yes. This looks like an osgEarth issue.

It appears that the sky model associated with the new views is not getting updated to the correct time. That is contributing to the darker-than-normal earth. If you rotate around, you'll notice that the sun's position is different based on the view.

The osgEarth pager appears to be stuck on some of the other views. I am not familiar enough with the underworkings of it to explain what's going on. It appears that the underlying cache is also sometimes returning invalid tiles. See the second main view pane from the left, for example:

I'll point this out to the osgEarth developers to see if they can shed any light on the tiling issues.

[duhbleA]

Sounds good. Hopefully the osgEarth developers have an idea how to alleviate this. Thank you for looking into this @emminizer !

[emminizer]

@AustinA, we have been able to find the underlying cause. When you have multiple graphics contexts (GC) with osgEarth, you need to disable the unref() on image data in the registry and in the database pager. This may use more RAM, but it's a requirement for multi-GC apps because the image needs to be sent to the GPU for each GC.

We don't typically see this issue in SIMDIS because we primarily stick with a single graphics context. The dockable example here uses one graphics context per simQt::ViewWidget.

@gwaldron was able to spot the issue from the description here and was able to come up with the underlying problem and the solution. Thanks Glenn. The fix is available now in https://github.com/USNavalResearchLaboratory/simdissdk/commit/fb81d3e8be9b88280624eb2908ce00a29ef64035 for your review. I only applied the fix to the QtDockableViews example, I'll take a look at other examples later to see if it needs to go anywhere else.

[duhbleA]

@gwaldron @emminizer fb81d3e works like a charm for our application under development and the Qt Dockable widgets example. Thank you both for such a quick turn around!