I tried this (with the ScreenSize block which is also fragment only) but it did not work because the system still tried to put the stuff in the vertex shader and ScreenSize is not allowed in the vertex shader… So adding it did not force to move the other nodes in the fragment shader, it was ScreenSize that was moved to the vertex instead. The problem in the node material above is that “position” should be made available in the fragment shader, but “position” is an attribute so must exist in the vertex shader. We would need to pass this data to the fragment through a varying, but then InputBlock would need to be aware of that and generate the right code.
rats…and what about manually flagging the node to target fragment?
Inputs are converted to varyings when used from the fragment
Calling:
super(name, NodeMaterialBlockTargets.Fragment/*Neutral*/);
in the TrigonometryBlock constructor does not make Fract being generated in the fragment shader…
That should be the case 
(as long as it is not connected to vertex node on the output side)
Hey, good discussion happening here! I tried out a few of your mentioned options. But surprisingly the ScreenSize workaround worked! It is a bit hacky and am not sure if it will work in bigger node materials. But I guess I will try to work with it for now I think it would be still nice to have a clean solution for this case. But already big thanks to you two!
If you don’t mind I would be interested to see your solution with ScreenSize as I could not make it work myself!
Sorry forgot the link: https://playground.babylonjs.com/#2SN0M8#2
worked for mod, too
Thanks, I now know what makes that my test did not work but I don’t understand why…
If you invert the input connections of the Add block it won’t work, error is “ScreenSizeBlock must only be used in a fragment shader” (the error I got when I tried it).
It’s a bit surprising as an addition is commutative, so changing the order should not change the behaviour. Granted, the result of the addition itself does not change but the node material does compile or not depending on how you input the connections.
@Deltakosh is this expected?
I had a similar message once in a while, but then I just inserted an unconnected Add block and that one would work. So it seem the block knows which shader it belongs to, once it is connected. Similarly to the trigonometric blocks that know if a float, vec2 or else is connected.
Not really 
Can you create an issue for you or me with the details so we can check?
No wait! this is expected!! To evaluate where to drop the code, the system is browsing up the graph. And when there is a node with several inputs, it start with the first one and go to the next one only if there is only neutral nodes in the first one
it happens here:
Babylon.js/nodeMaterialBlockConnectionPoint.ts at master · BabylonJS/Babylon.js (github.com)
and there
Babylon.js/nodeMaterialBlockConnectionPoint.ts at master · BabylonJS/Babylon.js (github.com)
I honestly think it should work by flagging the node as Fragment instead of Neutral and maybe we could expose the property in NME
Ok! I did 2 changes.
First we can now see the block target:
And for neutral blocks, you can set the target:
PR is progress
2 Likes
Thanks so much for this PR! Am looking forward to try it! 
It seems that it is not as easy as expected. https://playground.babylonjs.com/#2SN0M8#4
This time I have two textures, as soon as they are somehow combined, the fragment shader throws errors:
Shader compilation error: FRAGMENT SHADER ERROR: 0:126: 'undefined' : redefinition
It seems they share the same variable:
//Texture2
vec4 undefined = texture2D(TextureSampler, xy);
vec3 rgb = undefined.rgb;
//Texture
vec4 undefined = texture2D(TextureSampler1, xy);
vec3 rgb1 = undefined.rgb;
This PR will fix the problem:
1 Like
Wow speedmode! Thanks
Hi!
I had time to test the PRs now. It seems working on the vertex/fragment shader assignment is really opening some new issues. Fixing one error leads to the next.
Now I added a third texture, which could be used for uv2 to define a color for multiplication.
I could get around it with my current approach by not using a texture to define color. But it would still be nice, to find a solution for this issue. It seems to be a similar issue as the last one.
Furthermore I have assigned “Fragment” to Fract, Divide and Vector Merger in the following playground, but it switches back to Neutral, once it is reloaded. It would also complain trying to connect a fragment to a vertex shader node. So it seems allowing the assignment of the Shader did not work as expected. I myself can work with the screen space workaround though.
@Evgeni_Popov will definitely be the right person for it
yes I forgot to serialize that state change. We need to serialize it
1 Like