Allow multiple individual sinks for GpuValue

[thefuselab]

Allow multiple individual sinks for GpuValue

[everyoneishappy]

Demo for this in VL.Fuse\R&D_Issues\GpuInTwiceBug.vl

[texone]

Double checked everything looks like at least the patch provided by kyle is working now although I have not specifically fixed anything might be a side effect of something else not sure, Do you have anything else to test this Kyle? Otherwise would close it.

[everyoneishappy]

For me the demo patch still shows the broken behavior. Are you sure don't have part of the graph cached or something?

[everyoneishappy]

@tebjan Are you able to give any feedback on the updated demo patch? \R&D_Issues\42#GpuInTwiceBug.vl
@texone mentioned he is stuck with this although had tried to copy your approach

It's quite a big limitation as it stands

[tebjan]

Late reply because the GitHub notifications didn't reach me in the past weeks.

This topic sounds like something that @azeno is comfortable with. I've lost track of the code a little bit after the mentioned pull request. It's quite complex at the moment and for me hard to decipher. I think in VL.Stride it needs a cleanup and good code documentation so that fuse can follow the guidelines.

The main idea however is, that the shader compilation context is the identifier for one particular shader that gets built. It can be used as key for IDs, input pins and other things that have to be unique per shader. It can also help with gathering information that has to be shared between different nodes that aren't aware of each other, such as multiple from/to ShaderFX nodes that have to cooperate when a shader gets built.

[texone]

Yes I was also rethinking this for materials as this seems to be the main usecase I would propse for materials we use semantics and materialextension and than override the shading stage to set the semantics currently every value would be recalculated even if it shares a lot of calculations with another node

Is it potentially possible to connect two material extensions? I would move the setup of the semantics into the fuse pbrmaterial so that the user does not need to take care of it

[azeno]

Hmm not sure we're on the same page here. I thought this is about the constant buffers getting generated per sink and each source needs to keep track of?