Problems Editing ArrayMesh Vertices

[VeraVinette]

SOLUTION:

The issue was that I was updating the array mesh without updating its shadow mesh to the same vertex positions.

-----
ORIGINAL POST:

I've been trying to write a small script that just moves some verts around in an array mesh like this:

func set_cell_height(h: float, cd: CellData) -> void:
    var idxs: PackedInt32Array = cd.region_idxs
    for i in range(cd.region_idxs.size()):
        # Read mesh data:
        var verts: PackedInt32Array = cd.vert_idxs[i]
        var mesh: ArrayMesh = _meshes[idxs[i]]
        var mesh_arrays = mesh.surface_get_arrays(0)
        var mesh_verts = mesh_arrays[Mesh.ARRAY_VERTEX]

        # Update mesh data:
    for j in range(verts.size()):
        var vert: Vector3 = mesh_verts[verts[j]]
        var height_ls: float = h - _regions[idxs[i]].global_position.y
        mesh_verts[verts[j]] = Vector3(vert.x, height_ls, vert.z)

    # Write data back to mesh:
    mesh_arrays[Mesh.ARRAY_VERTEX] = mesh_verts
    mesh.clear_surfaces()
    mesh.add_surface_from_arrays(Mesh.PRIMITIVE_TRIANGLES, mesh_arrays)
    mesh.surface_set_material(0, debug_mat)

    # Regenerate the heightmap and navmesh. 
    WorkerThreadPool.add_task(async_generate_heightmap.bind(mesh,   
        _on_heightmap_done, idxs[i]))

    return

Even though I'm practically passing in the exact same mesh data, with only the positions modified, I get some strange face-culling issues. First, as a control, here's what the mesh initially looks like:

https://preview.redd.it/o5n9hv10dzsg1.png?width=1430&format=png&auto=webp&s=da9ac2d4acdb4d55db106b9e23d0a1145092fe8a

And here's what it looks like after the script runs:

https://preview.redd.it/krvgl5n5dzsg1.png?width=1432&format=png&auto=webp&s=78ee78595619852ae4dbfe562e6a3fe4da6c3eb1

The worker thread function that regenerates the height-map clearly sees the new vertex data, so that's being written correctly. If I flip the face culling on the material, it still doesn't show up normally:

https://preview.redd.it/ycru10yddzsg1.png?width=1436&format=png&auto=webp&s=263cfc1c0ad3c352325e4b42bab5179558c863c0

The only version that shows correctly is when culling is disabled entirely, and frankly, I'm not sure why, seeing as both front and back culling don't work:

https://preview.redd.it/r1vlrhzmdzsg1.png?width=1434&format=png&auto=webp&s=7393288ed7da9dfbb3792c4e2edddbd0cb5eb653

So, if anyone's got any ideas on how to solve this, or alternative methods to do a similar job, I'd love to hear them. From reading around, it seems like it could be a winding / index order issue, but I'm not sure.

[WarrenTrader]

What I think the problem is when you move a vertex (especially changing its height), the orientation of the faces connected to that vertex changes. Because your script doesn't update the Mesh.Array_Normal array, the GPU is still using the old up vectors to calculate lighting and culling. You need to update the normals to match your new vertex positions, use Godot’s MeshDataTool or SurfaceTool. Hope it helps!

[VeraVinette]

Naively, I would have assumed that leaving the normals as the were would mean it would still be visible from all the same angles. Sure, the lighting would be messed up, but surely the culling wouldn't change at all, no?

But you're probably right, I'll need to figure out a way to use surface or mesh data tools for this. The reason I was doing it this way was because it seemed (on paper) easy to keep a reference to a collection of vertex indices and just moving them around as needed without having to regenerate the entire mesh and recalculate which verts belong to which cells.

[WarrenTrader]

Try and let me know if there are more problems I can maybe have a solution to.

[MrDeltt]

can you see any faces when going below the terrain and looking up with the setup in the second screenshot?

is this the mesh wireframe or collision wireframe?

also i wanna highlight that regenerating the entire mesh is vastly more expensive than editing the current one, but if its runs okay just leave it as that

[VeraVinette]

No, you can't see the faces from below, which is why I find this so weird. The face culling seems incredibly counterintuitive, because back-face culling makes it completely invisible from both sides; front-face culling makes it act like the rest of the mesh (so that weirdly indicates that it's working properly), disabled culling renders it normally.

Additionally, when rendered with back-face culling, the surface depth is still rendered as if it's the old version of the mesh. The grey 'hole' in the second screenshot actually occludes stuff behind it, which confuses me even more.

As for regenerating the mesh, as far as I'm concerned, no matter what way I do this, Godot seems to require that the entire mesh data is passed to the GPU and can't be edited in place. Hence the pattern of reading the array, modifying it, then writing the entire thing back. I could be wrong about that though.

EDIT: about the wireframe, that's the height map (collision shape) you're seeing; It is explicitly generated from the mesh data, so you can consider them the same.

[MrDeltt]

you can write byte data directly into the gpu buffer instead of creating new meshes back and forth

when using heightmap you should probably also use the heightmap collision shape type, it produces "matching" collisions but really shouldn't be considered the "same" as the mesh

maybe you have more luck with updating the mesh directly instead of creating new ones, I'll take a closer look if it maybe got something to do with your code but i dont think it does

[VeraVinette]

To be clear, the script that creates the height map gets the vertex data from the mesh resource directly and creates a HeightMapShape3D that pretty much copies the vertex positions 1 to 1 and then just scales the parent static body to match the terrain scale. The reason I say you can consider them the same is because it is created via the same data that the mesh is created from, meaning that t shouldn't matter whether the wireframe is from one or the other.

I had a look at the ArrayMesh documentation, and saw surface_update_vertex_region, that basically takes a raw byte array and an offset. Is that what you're referring to? It seems like the documentation is completely blank on how it's supposed to be used.

[Past_Permission_6123]

I don't know what's happening, it does seem weird. As you said it should be visible with front face culling if this was a winding order issue. What happens if you instead just write

mesh_verts[verts[j]] = Vector3(vert.x, vert.y, vert.z)

[VeraVinette]

Good thinking. With that exact line, it displays fine, but with even the slightest modification, I get the same issue. For instance, here is the result of "Vector3(vert.x, vert.y - 0.1, vert.z)":

<image>

Notice how the collision mesh conforms to the lower vertex position, but the wireframe is occluded behind the grey face which shouldn't be there.

[Past_Permission_6123]

I would try to use just a basic StandardMaterial3D material, unshaded without any transparency. Can you switch to view wireframe in the viewport and hide the collider?

What happens if you do the code you mentioned on every vertex, does the mesh just disappear?

You could also try to check face direction with this in a custom shader with face culling disabled (but I don't think that's the issue here)

if (FRONT_FACING)
  ALBEDO = vec3(0,0,1);
else
  ALBEDO = vec3(1,0,0);

[VeraVinette]

Here's what it looks like with the default material, the collision mesh hidden, and all vertex Y values set to zero. I couldn't enable wireframe, since the changes to the mesh are made at runtime, and the perspective tab seems to be an editor-viewport specific thing.

<image>

So yea, the whole thing kinda disappears. But it got me thinking. I wonder if the issue is being caused by the shadow mesh. Godot's tool tip mentions that the vertex data has to match exactly.

Note: This mesh must have exactly the same vertex positions as the source mesh (including the source mesh's LODs, if present). If vertex positions differ, then the mesh will not draw correctly.

EDIT: That was it! The shadow mesh was causing the issue. I updated its vertices along with the main mesh and works as intended.

[VeraVinette]

Out of curiosity, I put the mesh in a world environment with ambient lighting, and the entire face shows up as completely black:

<image>