Mesh::create_trimesh_shape() causing a frame duration spike when called from a thread

[nenad-jalsovec]

Not sure what to make of it. I expected I can create a bunch of concave colliders in a thread using Mesh::create_trimesh_shape(), but this call appears to be blocking the main thread. It causes a single frame spike visible in the profiler. The profiler attributes it to Physics Time. The more data there is in the mesh, the larger the spike. Couldn't find anything about it in the docs. Is this by design? Can it be improved or worked around?

[nenad-jalsovec]

I'm providing a minimal example (tested in 4.3):

extends Node

func thread():
	var mesh = SphereMesh.new()
	mesh.rings = 50000
	CollisionShape3D.new().shape = mesh.create_trimesh_shape()
	
func _process(delta):
	if Input.is_action_just_pressed("ui_accept"):
		Thread.new().start(thread)

Attach the script to a node, run the scene, start the profiler, press enter and observe the spike in the profiler.

Can you guys verify this is indeed happening? If so, should it be reported as an issue?

[smix8]

Mesh data is stored on the GPU. Calling anything that needs to read mesh data needs to copy that data from the GPU back to the CPU stalling the entire rendering in the process.

[nenad-jalsovec]

Hm, in the actual project I plan to generate the mesh procedurally using SurfaceTool. Then I guess a workaround would be to pass the generated mesh data directly to ConcavePolygonShape3D::set_faces(). This should completely circumvent the gpu.

So just to clarify, mesh resources cannot be instructed to cache any data on the cpu side? If I for example create a primitive mesh and then immediately call PrimitiveMesh::get_mesh_arrays(), the data already went to gpu at this point and it will be retrieved from there?

[smix8]

Rendering mesh data never exists inside a Mesh resource at runtime. It is either loaded from disk or created procedural but in any way the data is always immediately send to RenderingServer and GPU when the mesh is created/commited and never stored on the CPU. There is no CPU copy and no way to cache it other than trying to work with the raw mesh data arrays stored in some variables.

You can not really use any rendering meshes at runtime to read data, at least not without creating those heavy performance problems. This includes all functions that touch them like SurfaceTool. Same for functions that try to create other geometry from rendering mesh data, e.g. creating collision shapes with the mentioned functions or e.g. baking navigation meshes from them. As far as performance is concerned those are all editor-only functions if you can not hide them behind a loading screen.

[nenad-jalsovec]

From my understanding, SurfaceTool maintains the data on the cpu side until commit() is called.

Is it possible to retrieve this data and pass it to ConcavePolygonShape3D::set_faces() without gpu involvement? SurfaceTool::commit_to_arrays() looks like it does precisely that.

Btw I plan to hide this behind a loading screen but I want it to be animated, and the spikes are breaking the animation smoothness.

[smix8]

SurfaceTool appends to its internal LocalVector arrays until a commit function is called. Those internal arrays can't be access.

The SurfaceTool::commit_to_arrays() creates a new mesh Array with a copy of this internal data. This is just a normal Array sized to MESH::ARRAY_MAX with PackedXYZVectors for whatever was added to the SurfaceTool.

While this Array can be used to construct a new ArrayMesh it is just that, a normal Array of data on the CPU, so works fine with threading and is not affected by the rendering stalling. The unindexed vertex array should be fine for faces of a ConcavePolygonShape3D.

[nenad-jalsovec]

Thanks for clarifications. Much appreciated. I think I'll manage from here.