NodeMaterial with a customblock causes UV issue, as well prevents it from reloading

When using a custom block which outputs a value to both the fragment and vertex outputs, any UV node connected to the flow returns the Mesh’s UV, instead of the fragment UV. This results in any textures getting sampled at a lower resolution (depending on the mesh density).

Also, when a node material includes a custom block and you do any change, you need to toggle Force alpha blending, to force update the material. Otherwise, it’s stuck showing the material as if nothing changed.

Here’s a link to the NodeMaterial:
Babylon.js Node Material Editor (babylonjs.com)

What it is supposed to look like:

What it looks like (lower resolution):

Here’s the code for the DebugCustomNode:

{
    "name": "DebugCustomBlock",
    "comments": "DebugCustomBlock.",
    "target": "Neutral",
    "inParameters": [
        {
            "name": "value",
            "type": "Vector3"
        }
    ],
    "outParameters": [
        {
            "name": "sameValue",
            "type": "Vector3"
        }
    ],
    "functionName": "debugCustomBlock",
    "code": [
        "void debugCustomBlock(vec3 value, out vec3 sameValue) {",
        "    sameValue = value;",
        "}"
    ]
}

The custom node simply returns the same value as its input. I also have this issue with a more complex custom block. This indicates that it doesn’t matter what the custom node does, the UV gets altered regardless.

To me, UV look the same but texture resolution does not.
Any idea @PatrickRyan ?

My bad, I should have used a better mesh to display the issue. I used the default plane, which if I had to guess, is 100x100 quads. So, it made it look like the image was 100x100 pixels.

If you switch to a different mesh, you can see how the pixels get smeared across the triangles:
image

Ho! Something related to block vertex/fragment @Deltakosh

On it!

1 Like

Ok not a bug :slight_smile:

Here is the explanation:

  • Your DebugCustomCode is emitted in the vertexShader as its output is then used to get the vertex data.
  • By doing so, NME has to export a varying of its value and send it to the fragment shader but in this case it is a pure linear interpolation of its value.
  • So the texture color is read only per vertex and then interpolated instead of being read per pixel

One solution:

This way the texture is read in both vertex and fragment and not interpolated

2 Likes

Thank you @Deltakosh for the explanation!

If it is possible, and I have no idea how difficult this would be, but I think it would be fantastic if there was some sort of indicator, such as an icon on the block, showing that the block is processed by the vertex shader.

The example that I used was of course very simple, for the purpose of reproducing this behavior with a minimal example. However, I have encountered this behavior a handful of times with quite complex graphs.

In this example, I had to duplicate the same nodes, to be able to use the effect for both the fragment and vertex shader.

You are right I need to also flag the custom block (you can see other where there is a triangle showing it is ran on a vertex shader)

1 Like

Oh, I didn’t know that the triangle and square icons was used to indicate this. I thought it just meant that it was an input, but I can see it now on a few other blocks.

Though I’m still a bit confused due to this:
image

How come the color block has a triangle, and the fragment output has a square?

This is exactly what was happening to you. The triangle comes from the vertex shader to a rectangle (fragment) so it will get interpolated