Failing to dynamically change color.

[PowerOfNames]

Okay, so I've tried for another two days and I think there is one missing piece somewhere...

Setup:

//... initializing the vsg
Options = vsg::Options::create();
Options->sharedObjects = vsg::SharedObjects::create();
Options->add(vsgXchange::all::create());
Options->add(vsgXchange::assimp::create());
Options->add(vsg::glsl::create());
Options->shaderSets["pbr"] = vsg::createPhysicsBasedRenderingShaderSet(Options);
//... window creation, compilation aso

We then add Nodes dynamically to the scene. We do this by using vsgXchange::assimp and we load .stl files (single object, they have no color attached to them, so vsg seems to assign per vertex positon and normal, but per instance UV and color)
Model loading and dynamically adding them to the scene works fine.
We also want to change the color of a Node. I found two different methods (whcih unfortunately both fail and I think the reason might be the same, but I need help finding that reason)

I use a visitor to either: change the instance color value from the default 1.0, 1.0, 1.0, 1.0 (even though its rendered in grey, so that might be the first hint)
Or, we change the pbrMaterial:

struct DynamicColorVisitor : public vsg::Visitor
{
	DynamicColorVisitor() {}

	void apply(vsg::Object& object) override
	{
		object.traverse(*this);
	}

	void apply(vsg::VertexIndexDraw& vid) override
	{			
		for (auto& buffer : vid.arrays) {
			auto data = buffer->data;

			if (data->is_compatible(typeid(vsg::vec4Value))) {
				// Change the property to dynamic
				data->properties.dataVariance = vsg::DYNAMIC_DATA;
				data->dirty();
			}
		}
	}
};


struct ChangeColorVisitor : public vsg::Visitor 
{
	ChangeColorVisitor(vsg::vec4 color)
		: Color(color)
	{ }

	vsg::vec4 Color;

	void apply(vsg::Object& object) override
	{
		object.traverse(*this);
	}

	void apply(vsg::DescriptorSet& ds) override
	{
		for (auto& desc : ds.descriptors)
		{
			auto db = desc.cast<vsg::DescriptorBuffer>();
			if (!db) continue;

			auto mat = db->bufferInfoList.front()->data.cast<vsg::PbrMaterialValue>();
			if (mat)
			{
				mat->value().baseColorFactor = Color;
				mat->dirty();
				return; // found it, stop searching
			}
		}
	}

	void apply(vsg::VertexIndexDraw& vid) override
	{			
		for (auto& buffer : vid.arrays) {
			auto data = buffer->data;
			if (data->is_compatible(typeid(vsg::vec4Value))) {
				
				(*(vsg::vec4*)(data->dataPointer(0))) = Color;					
				data->dirty();
			}
		}
	}
};

I also used the PrintVisitor form the vsg-tutorial, which helps with debugging ALOT :)
This way, I found that the value of both the vertex array (color) and also the material change accordingly. They also seem to end up in the compiler-manager/transfer tasks.
But ultimately, the color does not change in the final render.

I checked (using step-by-step debugging) which pipeline is bound to the nodes StateGroup (which is generated automatically when I load a .stl model (should be somethingl ike CullNode->GroupNode->StateGroup->BindGraphicsPipeline etc)
I dud into the Graphics pipeline shader stages and looked through (both) the stages (Vertex and Index) and it looks like it uses the default vertex and default pbr shaders.

And this is where I#m really confused: If the material is changed during runtime, marked as dirty and seem to end up on the GPU AND the (seemingly) correct shader is used, what might the reason be that the model does not change color?

I also tried changing the material/vertex color immediately after loading the model BEFORE I start the rendering thread or before I compile the viewer and that did nothing as well.

I also tried applying the visitor to both the CullNode as well as the GroupNode that parents that (structure is: GroupNode->MatrixTransform->CullNode->...->VertexIndexDraw). Debugging the data flow here (following the visitor) the data seems to change correctly. Its just either not consumed/updated OR the actually used graphics pipeline is something I do not expect/know...

I'm not sure what information I can provide to you to help me figure it out.
Am I missinterpreting the debug information, and the used shader isnt the pbr, shader set, but phong or flat? If so, where can I check that?

Thanks alot! I really need to figure this out soon, its a crucial part of the renderer we need.

[mp3butcher]

data->properties.dataVariance = vsg::DYNAMIC_DATA; must be called before before viewer compile ressources.
If you change datavariance during runtime, command graph must be compiled again.
(Perhaps a simple call to viewer.compileManager->compile let you change node at runtime but I'm not sure it's the good way to go)
see #604 for more

[robertosfield]

This isn't correct, you don't need to call do a compile on the subgraph that contains the data which you change the dataVariance to DYNAMIC_*.

What you do need to is either assign the BufferInfo that holds the data to vsg::TransferTask each time you update the data to make sure the data is compied from the vsg::Data on the CPU to vsg::Buffer on the GPU, or set dataVariance to DYNAMIC_* and then assign to the TransferTask and you then won't need to add to the TransferTask there after as it'll stay in the list of BufferInfo it actively checks each from till the dataVariance is changed back to STATIC_DATA in which case it'll be trimmed from the active list.

The CompileManager::compile() does the assignment to TransferTask for as well as check to see if any objects need to be compiled/created, so does the above for you but it's way overkill if you know exactly what data now needs to be transferred to the GPU.

[robertosfield]

As a general comment, STL is probably amongst the simplest of model types, so the structure that vsgXchange::assimp will create will likely be on the more simple end of spectrum. The quickest way to the look at the scene graph structure it creates is to convert the file to .vsgt (VSG native ascii file format) using vsgconv:

vsgconv myfile.stl myfile.vsgt

With more complex scene types, such as a gltf model the structure could well be far more complex, with multiple models integrated into a single scene, each one having multiple colours coming from material, vertex colours or texturing. I mention this as a warning that things could get much more complex than a single colour per model.

Now if you load a single model and only need to render one instance of it in the scene then traversing the scene graph looking from materials (look in vsg::StateGroup for vsg::BindDescriptorSet's that have vsg::DescriptorBuffer with a vsg::PbrMaterialValue/PhongMaterialValue data entry, or looking for vertex colours assigned to VertexDraw/VerexIndexDraw/Geometry/BindVertexBuffers nodes.

If you use this approach then you can modify the data value and then let the scene graph be compiled and this will allocated all the Vulkan objects and make sure everything is copied to the GPU.

If you load the model, put into the scene, compile the scene graph then start rendering, then a while later want to modify the colour then you'll need to find the data as before but this time as the associated data on the GPU is already resident a compile is not required, but you still need to tell the vsg::TransferTask (assigned to the Viewer's RecordAndSubmitTasks) that you want to update the data on GPU associated with the colour.. If it's a one off you can call data->dirty() and just assign the data directly to the TransferTask and then it'll be automatically synced for that frame only.

If you want to regularly update the colour, such as on every frame, then you'll need to set the data->dataProperties.dataVarianvce to DYNAMIC_DATA. Doing this will tell the TransferTask that when that data is assigned to it then it'll need to be retained on it's check list so that each subsequent frame it'll be checked to so if it's been dirtied since the last time it was copied, if it's dirty then it'll be copied. This usage approach enables you to set the dataVariance once and won't need to assign to the TransferTask again.

The TransferTask prunes data assigned to with with dataVariance set to STATIC_DATA after it's copied or data that no longer has an external references to it, such as when a subgraph is deleted from the main scene graph, but as the TransferTask still holds a reference to it it prevents it from being deleted from memory. This pruning helps deletes this orphaned data objects automatically for you.

If you have thousands of dynamic data objects you might want to asses which need dataVariance as DYNAMIC_DATA and which should be STATIC_DATA but just assigned to the TransferData when they are changed. Essentially you don't wan the TransferTask to be stuck checking data dirty status on ten's of thousands of objects every frame if only a few are ever dirty.

---

Things get more complicated when you want to instance a loaded model multiple times, but still want unique properties like colours on each instance of the model. In this case diving into the subgraph to change the data values directly won't work, the only way to provide the data is provide that data from above the shared subgraph. A couple of approach are possible in this case:

1. If you shared subgraph is simple enough, like a sphere/box/cone then you can use vsg::Builder and enable GPU instancing by passing in positions and colours. Run the example 'vsgbuilder -n 100 to see this in action.
2. If you go have a shared model and want to modify the material then sharing the subgraph below the StateGroup that has the BindDescriptorSet holding the material would be appropriate. Then have a seperate StateGroup that provides this BindDescriptorSet.
3. Provide a custom ShaderSet to the loader, where the custom ShaderSet has shared that read an additional material property that you provide by each instances StateGroup, with this material property in the shader used to override/modulate the vertex colour.
4. Use the new vsg::InstanceNode/vsg::InstanceDraw functionality, but it's so new it isn't yet supported by vsgXchange::assimp.

The new vsg::InstanceNode functionality allows you to translate, rotate, scale and colour each instance of model that is shared. There are constraints for the types of models it can work with, I outline these constraints in the header doxygen comments.

vsg::InstanceNode is a specialist node enabling GPU instancing in a more flexible way that transitional GPU instance like done with vsg::Builder where all the instance data is assigned to the low level mesh. However, it's still using GPU instancing so there constraints to it's usage we can't escape without introducing mesh or compute shaders to do culling, sorting and binning. This is BIG bleeding edge topic, for future development. For now you'll need to work with the constraints.

Another caveat is the only the vsgXchange::gltf/Tiles3D loaders know about and support vsg::InstanceNode, the vsgXchange::assimp loader predates the existence of InstanceNode by years. It will be possible to support InstanceNode in vsgXchange::assimp but it's not a quick addition. Looking through the commits to vsgXchange::gltf associated with adding InstanceNode support might give you an idea of where to start it you want to implement this yourself and create a PR for it.

[dov]

You may want to examine how assimp and the assimp loader is treating color for a single-color resource like STL (though there are extensions to STL adding 16-bit RGB color to to each triangle). Your ChangeColorVisitor assumes that the color for the entire resource is stored in a single vec4. What you want to verify is that the VkVertexInputRate for your color is VK_VERTEX_INPUT_RATE_INSTANCE and not VK_VERTEX_INPUT_RATE_VERTEX. I have just looked at the vsgt file produced by vsgconv input.stl output.vsgt and you can see in the vsgt file that this is indeed the case! You can see this both from the fact that the VertexIndexDraw array of type vsg::vec4Array (why don't the arrays have names?) only has a single value, as well as by inspecting the inputRate for the vsgColor attribute (location=6, binding=3) and verifying that it is 1, i.e. VK_VERTEX_INPUT_RATE_INSTANCE .

When I needed to load STL, I did not use vsgXchange, nor use any color attribute in the vertex shader. But instead passed the color of the object through a uniform.

[PowerOfNames]

*I wrote the whole scene into a .vsgt and looked through it -> it seems that sharedObjects use the same internal ID? Is that correct?
If yes, then something else leads to the quirks, because the model and the cube do have different pbrMaterialValues attached to them (different IDs, different values) The renderer still uses the same color for the whole scene (the one of the cube), except for when I move the cube out of the cameras frustum, leading it to be culled. Then, the material of the model is actually being used.

[robertosfield]

I wouldn't recommend using push constants for now as the VSG already uses 128 bytes for the projection and modelview matrices and not all hardware supports more than 128.

It's possible to create your own extra material using a custom shader set. Please look at the vsgcustomshaderset example, this one implements fog passing in it's own settings. You use exactly the same approach for adding an extra global color.

As for documentation, it's hard to write, do support and write documentation for everybody at all times and give away all the code for free. I have to balance how much paid and unpaid work I do across these tasks. Over the years I average around 2/3rd's of my time dedicated to unpaid task so you might be frustrated by other folks not providing your even more free stuff, but spare a thought for those providing YOU free support and just getting push back that it's not enough.

[PowerOfNames]

Mhhh I see. The issue is that I dont need a global color but per model instead. Normally this would be done using a uniform buffer or storage buffer.

I've been looking through all relevant examples already, I wouldn't post here before I don't check all resources I can find within a reasonable amount of time.

This is also why I'm a bit frustated ':D Nothing personal or anything and oc I'm grateful for your efforts. It just feels odd to me to work on a free to use library that anyone COULD use, but because of its nature (due to the used patterns, the usage of Vulkan...) its far from trivial to learn. It might be different if one already is used to OSG, whcih I never worked with.
As for the support: Did you by any chance consider opening a discord channel for this? Its far more accessible and dynamic for support, and the community could help you out ALOT there.

PS: The start of the vsg.org tutorials is awesome! I chose vsg because of that, actually, because it seemed to fit my requirements and because the docu starts really good. I just didn't work it entirely through because I didn't had the time then and the basic examples looked enough for the tasks I had back then.
But for something (that is generally super trivial) like recoloring, it seems that you have to have A LOT of background knowledge over vsg, how the rendering loop works, which parts are compiled when and then need recompilation if changed. SharedObjects doesnt seem to be explained anywhere, but if enabled, which most of the exmaples do, it changes A LOT of how the vsg works and handles resources. Its juts not possible to know what happens, when you should enable it and when you should alter it.

Its just a couple of key points that really do lack the documentation -> with it, one could work a lot faster and also deduce some of the quirks of the vsg functionality without the need of posting here :)
I'm sure its a lot of work to do, but it would both enable more devs to find their ways into the library, and in theory also reduce the amount of support work you need to do.

I tried being as constructive as I can here. Im not a native english speaker and have problems with it, so please excuse if I'm being rude or frustrating to you in any way!

[robertosfield]

I have been doing open source support for a quarter century. Lots of folks like volunteering other folks to do more support on more different avenues. Reality is for those doing support keeping it all in one place is the only practical way to manage the volume of support required. This might make it easier for end users not getting their preferences catered to. With open source projects the precious resource isn't' users, it's core developers time.

As for documentation, if we couple clone myself and have those be housed and fed for free. And also have a full roadmap of how a scene graph on top of Vulkan should solve all the possible problems that all the possible users might have, then the software be developed and fully tested, and then documented the final result.

Reality is the software is constantly evolving because the needs of the user community is constantly evolving.

As for changing colours being trivial. In modern graphics colours can be done in hundreds of different ways, there is no "one" way. It's not a trivial problem, much as we'd like everything to be trivial, writing graphics software isn't. There is no one typical user with typical needs. Some users need performance, others need flexibility. Some users have static scenes, others highly dynamic.

What is clear is you have unrealistic expectations on what takes

FYI, The VSG tutorial was partially funded through a client training that alas wrapped up before I could finish it. I have since had so much unpaid and paid work to complete that I haven't been able to finish the VSG tutorial. It's many months of work to complete, it's really not just an easy thing to drop in and complete and do so for free.

Even I did put aside quarter of year and work for free writing the rest of the VSG tutorial it still couldn't cover a fraction of the different things real users want to do with the scene graph. Many users don't both reading documentation or examples, they just plow in and ignore the amassed resources. It's a fact of life, as is "users" thinking they are being helpful by suggesting even more drains on ones time that would be unpaid.

[AnyOldName3]

I'd like to note that Discord in particular is pretty bad for providing support for software libraries. Most of the time when developers hit a problem, it's something someone else has hit in the past, so having an archive of past questions that show up in search is vital to avoid having to reanswer the same queries over and over again. Discord's search is pretty bad, and it's explicitly against their terms of service to archive historical messages somewhere else, so we can't even put chat logs on the VSG website where search engines could index them.

If you've got a really big community, then often you'll end up with a few people that really enjoy helping others and have enough time to spend doing it as a hobby, but the VSG isn't nearly widely enough used for that.

[rolandhill]

One way to change the colour of STL files imported via Assimp is to run a visitor through the graph returned from the read to find the vsg::PbrMaterialValue nodes. You then set them to DYNAMIC_DATA. From there, you can update the diffuseFactor value and call dirty(). I also use this technique for DXF files and most other 3D imports. Roland Hill Director Four Winds Technology Pty Ltd Spatial Integration <https://www.spatialintegration.com/>

…

On Tue, 19 Aug 2025 at 16:45, Dov Grobgeld ***@***.***> wrote: You may want to examine how assimp and the assimp loader is treating color for a single-color resource like STL (though there are extensions to STL adding 16-bit RGB color to to each triangle). Your ChangeColorVisitor assumes that the color for the entire resource is stored in a single vec4. What you want to verify is that the VkVertexInputRate for your color is VK_VERTEX_INPUT_RATE_INSTANCE and not VK_VERTEX_INPUT_RATE_VERTEX. I have just looked at the vsgt file produced by vsgconv input.stl output.vsgt and you can see in the vsgt file that this is indeed the case! You can see this both from the fact that the VertexIndexDraw array of type vsg::vec4Array (why don't the arrays have names?) only has a single value, as well as by inspecting the inputRate for the vsgColor attribute (location=6, binding=3) and verifying that it is 1, i.e. VK_VERTEX_INPUT_RATE_INSTANCE . When I needed to load STL, I did not use vsgXchange, nor use any color attribute in the vertex shader. But instead passed the color of the object through a uniform. — Reply to this email directly, view it on GitHub <#1566 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPOEQZJ5Q7BBM7TMBSTKVT3OLBZJAVCNFSM6AAAAACD7DP35KVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMJUHE3DOMQ> . You are receiving this because you are subscribed to this thread.Message ID: <vsg-dev/VulkanSceneGraph/repo-discussions/1566/comments/14149672@ github.com>

[PowerOfNames]

mhh, I did that for the most part, but I set the baseColorFactor to the color I wanted, which did not work. I will try using the diffuseFactor and look what happens there. I suspect this will only work for the model though, which I need to reuse throughout the scene with different colors attached to them -> Do I need to add a StateGroup parent per "instance" of the model using the pbrPipeline, and attacheing a new material descriptor per Model then?

[dov]

Ok, looking at the standard_pbr.frag shader, that makes sense! You just have to set baseColorFactor=0 to ignore the vertex attribute colors.