Node/subgraph (re)compilation

[PowerOfNames]

I got some behaviour I dont understand in my scene graph.

Case: I got a window and its scene. The Graph when compiling the Viewer that own the window looks like this:

Visiting vsg::Group
___Visiting vsg::DirectionalLight

Then the render loop starts.

We then add another vsg::Group as the actual Scene root (parent to all other children) and add to it a debug .stl cube.:

Visiting vsg::Group (root)
__Visiting vsg::DirectionalLight
___ Visiting vsg::Group (sceneRoot)
______Visiting vsg::MatrixTransform (cube transform)
________Visiting vsg::CullNode (cube)
__________Visiting vsg::Group
___________ Visiting vsg::StateGroup
______________Visiting vsg::BindGraphicsPipeline { }
________________Visiting vsg::BindDescriptorSet
__________________Visiting vsg::PipelineLayout
____________________Visiting vsg::DescriptorSet
_____________________Visiting vsg::DescriptorSetLayout
_____________________Visiting vsg::DescriptorBuffer
_____________________Visiting vsg::DescriptorBuffer
___________________Visiting vsg::BindViewDescriptorSets { }
_________________Visiting vsg::VertexIndexDraw

So far, so good. The odd stuff happens now, when I add other .stl models to the scene as SIBLING to the cube:

Here, I added two additional models (same model, but no cube)
Visiting vsg::Group (root)
__Visiting vsg::DirectionalLight
___ Visiting vsg::Group (sceneRoot)
______Visiting vsg::MatrixTransform (cube transform)
________Visiting vsg::CullNode (cube)
__________Visiting vsg::Group
___________ Visiting vsg::StateGroup
______________Visiting vsg::BindGraphicsPipeline { }
________________Visiting vsg::BindDescriptorSet
__________________Visiting vsg::PipelineLayout
____________________Visiting vsg::DescriptorSet
_____________________Visiting vsg::DescriptorSetLayout
_____________________Visiting vsg::DescriptorBuffer
_____________________Visiting vsg::DescriptorBuffer
___________________Visiting vsg::BindViewDescriptorSets { }
_________________Visiting vsg::VertexIndexDraw
_____Visiting vsg::MatrixTransform
_______Visiting vsg::Group (modelA_1)
_________Visiting vsg::MatrixTransform
___________Visiting vsg::Group
_____________ Visiting vsg::CullNode
__________________Visiting vsg::Group
____________________Visiting vsg::StateGroup
______________________ Visiting vsg::BindGraphicsPipeline (default pbr)
________________________Visiting vsg::BindDescriptorSet
__________________________Visiting vsg::PipelineLayout
__________________________Visiting vsg::DescriptorSet
_____________________________Visiting vsg::DescriptorSetLayout
_____________________________Visiting vsg::DescriptorBuffer
_____________________________ Visiting vsg::DescriptorBuffer
________________________Visiting vsg::BindViewDescriptorSets { }
________________________Visiting vsg::VertexIndexDraw
_____Visiting vsg::MatrixTransform
_______Visiting vsg::Group (modelA_2)
_________Visiting vsg::MatrixTransform
___________Visiting vsg::Group
_____________ Visiting vsg::CullNode
__________________Visiting vsg::Group
____________________Visiting vsg::StateGroup
______________________ Visiting vsg::BindGraphicsPipeline (default pbr)
________________________Visiting vsg::BindDescriptorSet
__________________________Visiting vsg::PipelineLayout
__________________________Visiting vsg::DescriptorSet
_____________________________Visiting vsg::DescriptorSetLayout
_____________________________Visiting vsg::DescriptorBuffer
_____________________________ Visiting vsg::DescriptorBuffer
________________________Visiting vsg::BindViewDescriptorSets { }
________________________Visiting vsg::VertexIndexDraw

Question: Why does the debug cube dictate the rendering state (pipeline, material descriptors etc) for all models in this case?

Case: When I now recolor the cube (pre-compile or during runtime) the whole scene gets recolored. Using the same method to recolor the other models, the colors get ignored. So I suppose that setting the pbrMaterialValue of the cube does that for its material, but the whole scene graph "thinks" that this is the only material it ever needs to bind to vulkan.

I marked all material descriptors as DYNAMIC_DATA. I would understand if the cube is one color and then all the ModelA models have another color but the same color among each other, because they share the same cull node atm

(pls excuse the formatting)

EDIT:

I just found out that if the cube is culled from the scene, the actual triangle color is rendered. So my thought seems to be correct. The question is: How do I change this behaviour? I want the renderer to reevaluate the materials PER MODEL or rather per StateGroup it finds.
It makes no sense to me that the first traveres stateGroup dictates the pipeline and material for the whole scene...
Any suggestions here?

Also, if I dont add the cube model before the base scene is compiled and therenderloop starts, I cant render the other models at al, which are added to the scene during runtime (even though I update the viewer and then add the node to the attachmentpoint, like suggested in example dynamicload:

struct opAddChild : public vsg::Inherit<vsg::Operation, opAddChild>
{
	opAddChild(vsg::observer_ptr<vsg::Viewer> in_viewer, vsg::observer_ptr<vsg::Group> in_attachmentPoint, vsg::observer_ptr<vsg::Node> in_node) :
		viewer(in_viewer),
		attachmentPoint(in_attachmentPoint),
		node(in_node) {
	}

	vsg::observer_ptr<vsg::Viewer> viewer;
	vsg::observer_ptr<vsg::Group> attachmentPoint;
	vsg::observer_ptr<vsg::Node> node;

	void run() override
	{
		vsg::ref_ptr<vsg::Viewer> ref_viewer = viewer;
		vsg::ref_ptr<vsg::Group> ref_attachmentPoint = attachmentPoint;
		vsg::ref_ptr<vsg::Node> ref_node = node;

		vsg::CompileResult compileResult;
		if (ref_viewer)
			updateViewer(*ref_viewer, compileResult);

		if(ref_attachmentPoint && ref_node)
			ref_attachmentPoint->addChild(ref_node);
	}
};

[AnyOldName3]

It's probably better to share the source code for a minimal app that reproduces the problem, as based on what you've said, the behaviour you're seeing should only be happening if you've made a mistake, and there's not enough code here to illustrate what that mistake would be. If it turns out not to be a mistake but rather a bug in the VSG, then there's not enough code here to reproduce the bug on anyone else's machine.