MultiMesh 3D performance spike due to setting Visible Instance Count

meggeki

Hi, thanks for taking your time to read this post.

I have encountered a small performance issue in my game project related to the MultiMeshInstance node My project involves a Player scene that, whenever it jumps mid-air, creates a platform underneath the player.

The way it is done is: MMI(MultiMeshInstance) stores all the meshes the Player may use. Player sends signal to MMI -> MMI increases visible_instance_count -> MMI sets the transform of the last MeshInstance to Player's transform (creating the illusion that the Player creates the platform, while in fact MMI makes them visible and transforms them to the Player's location one by one)

My issue: When this code is ran the very first time, there is a performance spike that lasts a single frame (the performance is top notch other than that.) Upon inspecting the Profiler, I have found that when the code runs, the Idle Time is increased from 16~ ms to 96~ ms. Upon inspection of the code, I have found that is occurs when Visible Instance Count increases from 0 to 1.

What I have tried: I set Visible Instance Count to 1 instead, the Idle Time occurs when the scene loads instead of when the Player jumps for the first time, however this doesn't work for me since there will be a single platform in the middle of a scene where it shouldn't be, since all platforms are created on Player interaction.

Now, this is not an urgent issue by any means, however I'd still like any suggestions as to how I can remove this performance spike or mitigate it to the loading time of the scene.

In addition I would like to know why does this happen, even a generalized comment.

Here is the code:

extends MultiMeshInstance

onready var player = $'/root/World/Player/'
onready var block_spawn = $'/root/World/Player/BlockSpawn'

var spawn_position
var visible_count = 0

func _ready():
	player.connect('spawn_called', self, 'spawn_called')

func spawn_called():
	get_spawn_position()
	position_mesh()
	set_visible_instance_count()
	spawn_collision()

func get_spawn_position():
	spawn_position = block_spawn.global_transform

func position_mesh():
	multimesh.set_instance_transform(visible_count, spawn_position)

func set_visible_instance_count():
	visible_count += 1
	multimesh.visible_instance_count = visible_count # this guy adds a ton of idle time, causes stutter at first run

func spawn_collision():
	var collision_node = preload('res://BaseBlockCollision.tscn').instance()
	collision_node.transform = spawn_position
	add_child(collision_node)

GlyphTheWolf

Hi,

I am not 100% sure about that, but MultiMeshInstance on lower layer would use probably some method like OpenGL glDrawElementsInstanced or maybe glMultiDrawElementsIndirect.

That methods works the way you need to prepare some buffer with data that you want to draw, send prepared buffer to GPU and then you just call one method which draw all data from prepared array (that array may contain different data depending on needs, but probably it will consist at least of transforms).

There are 2 properities in multimesh. One is instance_count and second is visible_instance_count. According to documentation changing value of instance_count will always cause buffers to recreate, so it is costly to change instance_count often. Setting visible_instance_count shouldn't recreate buffers, I guess it only send updated data to already allocated buffer.

I assume you doesn't change instance_count every time you add new instance (that could probably cause performance issues not only when changing instances from 0 to 1, but also any time later).

So my guess is that when you change visible_instance_count from 0 to 1 Godot may do something like update some internal cache or allocate buffers it doesn't need if visible_instance_count is 0 (however as I understand it should do that when setting instance_count, not visible_instance_count, so that would be a bit strange).

Anyway according to your idea with setting visible_instance_count to 1 from the beginning I think that maybe simple solution would be to set visible_instance_count to 1 and just hide MultiMeshInstance. Then first time player jumps you need only show MultiMeshInstance itself and every next time use your current logic with showing more instances. You can check if that will help you somehow.

meggeki

Hey @GlyphTheWolf, thanks for clarifying as to what might be the case!

I attempted using the visible property of Spatial (at base of MultiMeshInstance), set it to false and then assigned a key that sets it to true (the reason I set a dedicated key is to test beyond the first jump, which brings identical results if I set the visible property through the spawning method)

Interestingly enough, the effect is the same even with visible_instance_count starting off at 1. So in this instance visible_instance_count starts at 1, MMI's visible property is false, Player jumps around and raises visible_instance_count even further, I press the key assigned to setting visible to true, every mesh is displayed as expected however at a cost of an identical stutter effect.

So it might be that when setting visible_instance_count from 0 to any positive number, Godot performs the same or similar action as when setting the visible parameter of Spatial.

But that did lead me to another solution, which is simply to run set_instance_transform on the first instance during the _ready method, and setting the transform so that the scale property will be at 0 (thus making it virtually invisible). It's a bit dirty, but for now it works.

Still curious about the phenomenon though, any additional info is welcome.

GlyphTheWolf

Yes, you are right. I also noticed similar issue that game stuck for a while when I make mesh visible for the first time (when I make it hidden and visible again later it works smooth, but first time when I call show it hangs for a while). I guess Godot have to perform some heavy operation then or maybe update cache or something?

Edit: To clarify in my case it is not even connected with MultiMeshInstance. I noticed similar issue with simple MeshInstance.

show() method itself seems to be pretty simple:

void Node3D::show() {
	if (data.visible) {
		return;
	}

	data.visible = true;

	if (!is_inside_tree()) {
		return;
	}

	_propagate_visibility_changed();
}

Well if anyone knows what may be reason of that I also would find it useful.

Calinou

Yes, you are right. I also noticed similar issue that game stuck for a while when I make mesh visible for the first time (when I make it hidden and visible again later it works smooth, but first time when I call show it hangs for a while). I guess Godot have to perform some heavy operation then or maybe update cache or something?

This is due to shader compilation. As a workaround, you can display the mesh during one frame in front of the camera when the game starts. It can be occluded by a solid surface, but it must be within the camera's far clip range and must be in front of it (not behind).

Shader caching is being worked on for a future Godot release.