Patching shaders

Hi all

Recently I have begun using DX11 by default… waaaay too late to the game, I know. it is awesome in so many ways.

But one thing that become apparent as a die hard patcher and not coder is that the real power lies in the shaders and HLSL and what I can do there is very limited.

Simple things like here: are not so easy when your instinct is to not look into the shader code.

I remember at NODE13 when VL was introduced publicly for the first time a small demo, I think it was @Elias who demoed patching shaders.

How is it going with that?

Will I ever be able to patch shaders?

To me the power of vvvv is that I can patch super complex stuff without coding so it would be logical to think that patching shaders was something where you say “of course you can do that”

How do other non-coding patchers deal with when you would like to do fancy stuff in shaders, besides asking the extremely helpful people who are masters in shaders (noone mentioned, noone forgotten), after all they can’t be there always.

I look forward to the comments



of course you can do that :P

Seriously though, do have a look at instance-noodles
It’s pretty much intended for you and people like you (meant nicely- I prefer patching too, hence learning to write shaders so I can go back to patching).

In your case of wanting to play with vertex colors there are a few modules there.

  • ConstantBuffered(DX11.Layer) has vertex color option built in, as per instance, per face or per vertex
  • Vertex_Colors(DX11.GeomFX) will add vertex colors to a geometry
  • VertexColor (Dx11.Effect) will display vertex colors- assuming geometry has them already

That being said this pack is not really a solution for pixel shading, as it focuses on earlier stages of the pipeline. But still I think you can do quite a lot with it without touching any HLSL whatsoever.

Would really love to have something like that infamous NODE demo to play with.

the vvvv main problem that the patch interface is slow as hell, pipeline not optimized for graphics, since it gives u some freedom(or slavery) to create ur own rendering pipeline in cost of ur time and system resources. Modern concept of patching = less nodes are better… And in the end it’s all just code connected together.

this thread is a followup to

if there will be a node-parser for shader-code, it will make sense to implement it for dx12.
si ou non ?


Learn HLSL, it will benefit you in any case, since at least you will not be limited to a single paradigm and can choose for the best tool (code/patch) depending on what you need to achieve.


HLSL syntax is almost same in dx11/dx12 (only a few little optional differences to handle cbuffers). All new features available in dx12 hlsl are also usable in dx11.3, so not a big deal to support both.

Pipeline setup is the main difference between both APIs (dx11 favours late decision, whereas dx12 favours an up front model)

Also cost to go from shader code to something usable in pipeline is also higher in dx12 (as you have to build the whole state object again instead of just the shader unit, plus the fun of burning part/or all your heap descriptor/tables again)


There’s much more happening under the hood than “just” connecting code together…