When the instance count of MultiMesh is changed, strange data appears in the buffer.

[SneaK1ng]

Godot version

v4.1.dev.custom_build.c29866dbc

System information

Win10, AMD 2600, GeForce GTX 1060, Vulkan API 1.3.205

Issue description

I don’t know if it’s normal.

When I change the instance count of MultiMesh, sometimes strange data will appear in the buffer like below:

Steps to reproduce

Just change the number of instance_count several times.

Minimal reproduction project

nothing

[Calinou]

• Related to https://github.com/godotengine/godot/issues/56357.

[bitsawer]

I did some related digging during my MultiMesh bugfix and I can confirm this happening, it's pretty easy to repro. I suspect the reason might either be the semi-asynchronous nature of the buffer update or simply uninitialized data somewhere. Either way, the end result is that sometimes when resizing the buffer data in the editor, it gets filled with garbage data.

[Bimbam360]

I'm going to chime in on this rather than raise a new ticket as suspect it's the same bug still happening in v4.3.dev4.official [df78c0636]

Essentially I have a function that programmatically spawns new MultiMeshes, and am having to regenerate a new buffer manually to stop it generating junk:

func new_mm(basenode: Node, material: Material, mesh: Mesh, mm_instance_cap: int) -> void:
    var MMInst:MultiMeshInstance3D = MultiMeshInstance3D.new()
    var MM:MultiMesh = MultiMesh.new()
    var buffer = PackedFloat32Array() // Hacky workaround
    buffer.resize(mm_instance_cap*16) // Hacky workaround
    MM.transform_format = MultiMesh.TRANSFORM_3D
    MM.custom_aabb = AABB(Vector3(-1000, -1000, -1000), Vector3(2000, 2000, 2000))
    MM.use_colors = true
    MM.mesh = mesh.duplicate(true)
    MMInst.material_override = material
    MMInst.multimesh = MM
    MM.instance_count = mm_instance_cap
    MM.buffer = buffer // Hacky workaround
    basenode.add_child(MMInst)
    MMInst.owner = get_tree().edited_scene_root

Otherwise, it arbitrarily looks like:

[hackrmomo]

I believe this is also the case in v4.2.2 (release) by the way.

[jjoshpoland]

Confirming that it is happening in 4.2.2. I am generating MultiMeshes and MultiMeshInstance3Ds in code in a [Tool] C# script to make grass on a procedural mesh terrain and this started happening after a while. Only form of replicating the workaround posted above is by setting the buffer to null, which Godot complains about and then does render the MultiMeshInstance3Ds as expected.

It didn't happen for the first 1000 times I regenerated the map, but then it started happening every time until I found this thread. Rebuilding the scene, reloading the project, restarting the machine didn't work. I am not resizing the array, just running queue_free in the Tool script and then creating new MultiMeshes and MultiMeshInstance3Ds.

I have a Radeon 6650XT on Windows 11 and my grass runs great until this happens.

Before the workaround (commenting out the line MultiMesh.Buffer = null;)

After adding it back in:

Edit for clarity: these MultiMeshInstance3Ds are children of the root of the node tree and are visible in the scene hierarchy. They are updated over the course of multiple frames where additional instances are added to them, but this is present on the very first frame they are generated as well. They contain up to 16k grass mesh objects each and I've seen the buffer grow to around 200k in length. I didn't actually count if it happened after 1000 times, just that I had been using this logic for a week before I saw this occur. The error also occurs if I set the buffer to a new float[0].

[jjoshpoland]

Update: that workaround is not consistent. Even when the error is thrown, vertices will still show up screwed up. Currently having the buffer set to new float[0] and its running as expected for now.

[STehrani]

Godot version

v4.3.beta3.official

System information

MacBook with M1 Pro Chip

Issue description

I just tried out this project, which also uses MultiMeshInstance3D and the problem still exists:

https://github.com/Malidos/Grass-Shader-Example

[blam23]

Still an issue with v4.3.stable - note that it also affects MultiMeshInstance2D so this issue should probably be tagged with 2D topic too.