SdfPlane graph node writing to weight channel through OutputSDF

[AntoineRR]

First of all thank you for this amazing plugin, it does work very well and help me a lot!

Describe the bug
While playing with the VoxelGraphGenerator, I noticed some weights were being added by the SdfPlane node even though I didn't want it. This is very visible when using a shader that displays weight values on the sides of a bound VoxelTerrain (see screenshot).
My guess is that the SdfPlane node just writes the y value to channel sdf and at some point it overflows onto the weight channel. I get the same issue when I plug InputY directly to OutputSdf.

To Reproduce

• Create a new VoxelTerrain
• Set its bounds to (-32, -32, -32) and (32, 32, 32)
• Assign it a new ShaderMaterial with the following shader :

shader_type spatial;

#include "res://addons/zylann.voxel/shaders/transvoxel.gdshaderinc"
#include "res://addons/zylann.voxel/shaders/voxel_texturing.gdshaderinc"

varying vec4 v_material_weights;


void vertex() {
	VERTEX = get_transvoxel_position(VERTEX, CUSTOM0);

    v_material_weights = decode_8bit_vec4(CUSTOM1.y) / 255.0;
}

void fragment() {
	ALBEDO = vec3(v_material_weights.rgb);
}

• Assign a VoxelMesherTransvoxel with the "Mixel4" texturing mode
• Assign a VoxelGraphGenerator
• Add an OutputWeight node (should set the first weight to 0)
• Regenerate Terrain

Expected behavior
I would expect the weights to be set to 0 accross all the voxels

Screenshots

Workaround
For my use case, the simplest workaround is to use the following graph. The sdf is probably less precise but it's ok for me.

Environment

• OS: Fedora 42
• Graphics card: NVIDIA GeForce GTX 1070
• Godot version: 4.5.1
• Module version: Voxel Tools GDExtension 1.5 for Godot 4.5+
• Renderer used: Forward +

[Zylann]

TLDR: not really a bug, works as designed. Can be worked around. Could be improved somehow but no motivation to do so.

---

I'm quite confused about what you're actually amining to do here, but there are several things to note here:

• Currently I'm kinda deprecating the use of OutputWeight nodes. They are currently available as of legacy, but they are actually quite difficult to use correctly when there are more than a few weights, so I'm unsure about developping them any further.
• Weights are not just any values that gets attached to vertices somehow. They are related to texture splatting and are supposed to sum to 1, at least roughly. By adding a weight output which always outputs 0, you're doing something unsupported by the mesher. I'm not quite sure what will happen in that case. It shouldn't go as far as crashing, but whatever it is, that's not an expected case.
• Weights are supposed to be used with indices in the shader. Each component of the vector may not always refer to the same weight, depending on the indices. But you're using weights without the indices. I don't know if that's because it's an example or because you're really trying to use them this way.

Apart from all this, it is indeed quite strange to see anything > 0 pop up, but I wanted to highlight the other issues here because it might just be an unfortunate consequence.

Upon investigation, the red you are seeing doesn't directly come from the generator. It's an interaction between the mesher's interpolation and default voxel values outside terrain boundary.

The default value of weights in general is actually (1, 0, 0, 0). When meshing near boundaries, neighbor voxels fallback to default values, they don't query the generator because it's outside of the terrain. SDF also defaults to a big positive value, so a vertical surface shows up. But because the isosurface is located just between voxels you generated and those default ones, you get an interpolated result that looks non-zero.
So... it's working as designed.

As to why it is more pronounced a few meters down, this is because of an optimization the graph does when far enough from the "usual" isosurface: instead of continuing to calculate the distance field, it skips to a constant value. This is usually not noticeable but boundaries aren't considered in that optimization so they show up more here. This makes the isosurface interpolate closer to the boundary, so it becomes more "default" (more "red").
You can turn off this optimization by setting sdf_clip_threshold to a high number in your generator, and you'll see the cut will disappear.
However, just like in your second screenshot, you still won't get full black, for reasons stated above. So turning this off might not be the right thing.

You can get better fix by subtracting the outside of an SdfBox from the terrain's SDF, which explicitely defines your boundaries within the graph (this is done with a Min operation). This makes the boundary known by the optimizer, and that makes the cut go away as well. But still slightly tinted red, for the same reasons.
Shrinking that SdfBox by 2 voxels (1 for each side) will truly make the tint go away, as the isosurface will no longer be close to default voxels beyond the boundary.

If you're going to have a fixed-size terrain, better have some margin away from the true boundary anyways, because of litteral edge cases that occur there. There used to be no default voxels at all there, and instead terrain just stopped with an edge, without forming cliffs, since it kept using the generator for voxels out of bounds. But then this was reported so now it behaves the way it is. Which is not extraordinary but adding special cases everywhere for that boundary isn't really something I'm fond of (considering I made this either for "infinite" terrain or large fixed terrain with many kilometers of margin; where basically, boundary stuff practically never happens).

Note about your Select workaround: it gets rid of all gradients beyond 1 unit of the surface: everything is 1 above 0 and -1 below. This can cause problems when you operate with other SDF on top because of the lack of gradient, i.e values are "blocky". It also gets rid of the color change a few meters down since it makes SDF below zero constant anyways, making it look like it fixes the issue, but as shown earlier the tint remains anyways.

[AntoineRR]

Thank you for your detailed answer! It is much clearer why this appears now.

Indeed this was just a simplified example, in which I forgot the weights should add up to 1. I tested while adding a weight of 1 to layer 1 and the red tint still shows up. Also I didn't specify the indices because to my understanding they default to (0, 1, 2, 3) which was fine for the test.

Anyway, I understand this is expected behaviour. I was concerned the weights would be non zero across the whole volume below a certain depth, which I found weird. As it is only an edge case this is perfectly fine and I'll probably add a safety margin as you suggested.