I have seen this happening to quite a lot of custom shaders I made as well as in some VL.Addons shaders where GPU inputs (most of the time) are involved (in my case I found this happening just with a SamplerState), where opening a patch pins do not pass the values directly but most of the times I have either to update the values manually or to delete and re-introduce the connected node. I am still using stable 7.0 for my current work, is this just me, is it about the version is it the way I am declaring my variables in the shader (not using stage casually)? Thanks in advance.
This needs a test case, but basic “what’s wrong” is that different way of how stuff is resolved. The thing is vvvv is not magic, and way it resolves stuff is actually a process you can observe in here for instance VL.Stride.Voxels/VL.Stride.Voxels/src/ProcessNodeBase.cs at develop · antokhio/VL.Stride.Voxels · GitHub
Basically you have an object, like shader factory, the shader factory creates shader based on some sdsl code, to make shader compiled it has to be provided with address of gpu (gpu.resource) the it needs to be bound some uniforms (input pins), each pin maybe a gpu resource like GPU. The core of this process is likely some orchestration. The orchestration should recompile shader or shader resource and it should decide: like I should update shader if code changed, or I should update resource if float changed… The problem here, is that it’s not obvious what created first a shader or resource, is resource changed after you create shader, and so on…
Likely you hit some bug in orchestration, the way to sort it, is likely Do region or Manage Process, since orchestration (shader) may depend on resources that are not actually created during shader creation…
Long story short, there is Cache that avoids expensive calls, likely most setters incorporate cache like if new value != old value Set, there are also a cached getters witch are even more complicated, since they should resolve much more, like are you in update, or it’s a get call even before update, or maybe resource wasn’t created at time of call…
All we can is track some test cases. Hope the orchestration can be fixed…
2 Likes
@nissidis yes please provide a case for us to reproduce.