Remove an object in scene graph

[yangcshen]

Hi

Let's say my root object in the scene graph is vsg::ref_ptr<vsg::Group> scene. Then, I added objects

vsg::ref_ptr<vsg::StateGroup> myObject;
scene->addChild(myObject);

Now I want to remove it. I see there is no public API regarding the removal of a child, but children member variable is public so I directly manipulate it. So my test code is.

if (scene->children.size() == 0)
  return;
scene->children.pop_back();

When I remove the last element in the scene, the application freezes. What am I missing here?

Thanks,
Cam

[robertosfield]

Directly removing the child by accessing group->children is the correct way to remove the child.

However, the timing of when the subgraph is removed from the scene graph and when it's finally deleted is important. If you just remove the child in a background thread and the record traversal is running at the same time you can invalidate the iterators or delete the subgraph that is being traversed. To avoid this issue you need to remove the subgraph during the update phase of the frame and avoid doing when the record traversal is running.

If you remove the subgraph in the update phase you avoid potential for a crash in record traversal but problems can still occur if that subgraph is deleted along with it's Vulkan resources while a previous submitted frame uses that Vulkan resources associated with that subgraph. To prevent this problem you can either do a device wait idle or wait on fence before you do the removal so that you ensure all the rendering is complete, or keep a ref_ptr<> to the subgraph alive for as many frames as may be queued up for rendering - 3 frames will be enough to handle triple buffering.

I have a plan to add a class for scheduling deletion of subgraphs to avoid the second issue, this would enable one to pass a subgraph to be sheduled for deletion and then have a background thread do the deletion after a user controlled number of frames.

I don't have a plan to make access to members of the scene graph generally thread safe to avoid the first issue, mutex locks around all members would be prohibitively expensive and destroy the performance of the scene graph, it's far more efficient to just manage the scene graph at a high level and have certain type of operation done in sequence to avoid race conditions.

For users used to using the OpenSceneGraph these constraints for when and how you can delete subgraphs is the same, though OpenGL's FIFO hides some of the possible threading issues by effectively multi-buffering pars of the data. This means while the same constraints apply you could sometimes getting away with dangerous usage.

[yangcshen]

Hi Robert,

Thanks for your explanation. That makes sense to me now. The deletion happens at record traversal because it is triggered by a button click from ImGui UI which is inherited from vsg::Command. So, my application crashed due to the first reason you mentioned.
I moved the code to a vsg::Operation and execute it in a different thread other than the main thread.
This time it works!

struct DeleteNode : public vsg::Inherit<vsg::Operation, DeleteNode> {
  DeleteNode(vsg::ref_ptr<vsg::Group> in_sceneGraph,
             vsg::ref_ptr<vsg::Node> in_node)
      : sceneGraph(in_sceneGraph), node(in_node) {}

  void run() override {
    auto ref_sceneGraph = sceneGraph.ref_ptr();
    auto ref_node = node.ref_ptr();

    if (ref_sceneGraph && ref_node) {
        auto found =
            std::find(ref_sceneGraph->children.begin(), ref_sceneGraph->children.end(), ref_node);
        if (found != ref_sceneGraph->children.end())
          ref_sceneGraph->children.erase(found);
    }
  }

  vsg::observer_ptr<vsg::Group> sceneGraph;
  vsg::observer_ptr<vsg::Node> node;
};

But I still do not know deterministic this code is. Another thread is spawned to execute this code when the main thread is executing record traversal. I put a break point in void run() override to see where the main thread was paused and found that it still was at record traversal phase within the same frame. So, I do not see any difference between my first approach and this multihreaded approach. But this multithreaded approach works. Why does this approach work?

Thanks,
Cam

[vsg-dev]

Hi Cam.

Thanks for your explanation. That makes sense to me now. The deletion happens at record traversal because it is triggered by a button click from ImGui UI which is inherited from vsg::Command. So, my application crashed due to the first reason you mentioned.

This was probably an issue with invalidating an iterator as the record traversal will have descended down to the ImGui UI node but if you delete a sibling child or a node/sibling in the parental chain then the children vectors being streped through can be invalidated when then containers change size.

Potentially even the self could be deleted.

_I moved the code to a vsg::Operation and execute it in a different thread other than the main thread.
This time it works!

...
But I still do not know deterministic this code is. Another thread is spawned to execute this code when the main thread is executing record traversal. _

You shouldn't need a separate thread, the viewer has an update operations list that you add an operation to and have this called when viewer.update() is called.

include/vsg/app/Viewer.h

[ztef]

Reagrding this issue, how can I set the Node visible or invisible ? This would help to the purpose, hide and unhide the node would e faster.

[yangcshen]

What I did was to write another shader which contains a Boolean variable (say visibility) which I can push as a uniform from vsg. When visibility == false, do discard. So the node will not be displayed. This works as expected.

Another approach I tried is to use vkRasterizationDiscard. This is a dynamic state which you can set up in vsg dynamic pipeline. This is an easier way but I have encountered a bug which I no idea where it comes from. The bug is that the associativity somehow messed up when I have more than two nodes in the scene. For example, I meant to hide the third node, but the second node was hidden. When I have some time I will put an example code and create an issue for this.

[robertosfield]

The vsg::Switch node is designed for switch off the traversal of it's children. Each child of the Switch has a Mask (a 64bit mask( that is combined with the Visitor's traversalMask and if it's not 0 then the child is traversed.

To switch on a child use vsg::MASK_ALL, and switch off a child use vsg::MASK_OFF.