Dynamically adding/removing vsg::Window with their own vsg::CommandGraphs

[nolankramer]

Is dynamic window adding/removal well-supported? I'd like to have multiple windows with their own vsg::CommandGraph (they each render a separate scene).

I've been getting odd rendering issues and crashes when adding & removing vsg::Windows to a vsg::Viewer.

I do use the viewer's vsg::CompilerManager across my scenes - so perhaps that sharing of context is bad. Should I be using a vsg::CompileManager per-window/per-scene?

[robertosfield]

CompileManager has support for multiple views/multiple windows. It's meant to handle all the needs for a Viewer.

When adding/removing windows it's important to stop threading and wait for all the work on the GPU to complete. The vsgdynamicwindows example will illustrate this.

If there are crashes then get a stack trace and share this so others can see what might be able to happen. Better yet modify an existing VSG example to illustrate the crash so that if there is a bug/limitation in the VSG the community can work together to find the best way to resolve it.

[robertosfield]

Can you even load openstreetmap.vsgt with vsgviewer? Looks like an error related to loading http which suggests vsgXchange hasn't been compiled with libcurl.

…

On Fri, 15 Aug 2025, 19:14 Nolan Kramer, ***@***.***> wrote: I could not get the vsgdynamicwindows example to run without segfaulting on my machine. Ubuntu 25.04 x86_64. Ran with ./bin/vsgdynamicwindows --resource ../data/models/openstreetmap.vsgt: (lldb) run --resource ../data/models/openstreetmap.vsgt Process 21161 launched: '/home/nolan/Development/vsgExamples/build/bin/vsgdynamicwindows' (x86_64) Warning: tile::read_root() unable read image data, imagePath = http://a.tile.openstreetmap.org/0/0/0.png Warning: TileDatabase::readDatabase() imageLayer = http://a.tile.openstreetmap.org/{z}/{x}/{y}.png failed to load. Error: vsg::tile::read_root(..) no support available for protocol. Process 21161 stopped * thread #1, name = 'vsgdynamicwindo', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x0) frame #0: 0x0000555555698820 vsgdynamicwindows`main(argc=1, argv=0x00007fffffffd338) at vsgdynamicwindows.cpp:189:20 186 187 // compute the bounds of the scene graph to help position the camera 188 vsg::ComputeBounds computeBounds; -> 189 vsg_scene->accept(computeBounds); 190 vsg::dvec3 centre = (computeBounds.bounds.min + computeBounds.bounds.max) * 0.5; 191 double radius = vsg::length(computeBounds.bounds.max - computeBounds.bounds.min) * 0.6; 192 double nearFarRatio = 0.001; I did notice there is some special care given to adding context to the CompileManager - is this simply to support threading? Or does it also prevent issues with mixing resources when a window is removed? — Reply to this email directly, view it on GitHub <#1565 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKEGUCZG7KFXMA6S4HRGUL3NYPQ5AVCNFSM6AAAAACD6JQEOCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMJRHE3TKNA> . You are receiving this because you commented.Message ID: ***@***.*** com>

[nolankramer]

I think that was the error. I resolved the crash by setting environment variables correctly.

I'm in the middle of investigating the source of error in my code - will report back once I understand what I did wrong - so far I think it has to do with setting up context correctly for each view.

[nolankramer]

Just so I can move forward a bit faster, since I feel like I'm losing my mind here: I'm trying to set-up a multi-window system with some windows having multiple renderpasses in them. This means that a given window could have multiple vsg::View in it.

This is for an application that requires multiple passes to complete a scene (and yes - there is a compositing pass). I wonder what the recommended architecture here is and how to integrate it with vsg::CompileManager in a sane way.

So far, what I have is: each vsg::Window contains a single vsg::CommandGraph, which contains multiple vsg::RenderPass - each render pass also has it's own associated vsg::View. Some renderpasses just render a single quad, while others can render the entire scene (which is shared among each render pass via a vsg::ref_ptr<vsg::Group>).

This had worked fine in the past, but with multi-window and needing to provide context to the vsg::CompileManager, everything has broken - I presume due to the vsg::ref_ptr<vsg::Group> no longer being sharable since each vsg::View has it's own Context in the CompileManager.

[robertosfield]

With complex viewer usage it's very hard to others without that viewer usage infront of them to be able to know what might be amiss in your usage case.

Could you modify one of the existing example to illustrate your usage case and demonstrate how it's failing? Sharing such a test case would allow others to run the test, see the failure, review the code and spot the problems in the setup or spot issues in the core VSG that might be making your usage case awkward to achieve.

[nolankramer]

I've created a PR to vsgExamples here: vsg-dev/vsgExamples#369

I created a new example to illustrate the functionality. It's not multi-threaded. I did that on-purpose to simplify it.

I haven't yet added functionality to have multiple vsg::View, but it's already crashing when removing a vsg::Window. I can add a multi-view Window once the current crashes have been resolved.