Sprite3Ds with fixed size, low pixel_size, large translation cause explosion in memory usage

[kb173]

Godot version:

3.1.1

OS/device including version:

Tested on different systems with Ubuntu 19 and Windows 10

Issue description:

When spawning many Sprite3Ds with a fixed size texture and a small pixel_size far away from the origin (large values in the translation), an explosion in memory usage happens, up until the whole RAM is filled and the OS either shuts the game down, or the whole PC freezes.

From playing with the parameters, it seems to me like this doesn't worsen gradually - there's a certain threshold where the explosion starts happening, before that all is good.

Whether the explosion happens is a result of a mixture of all three parameters (translation, amount, pixel_size). In fact, with a small enough pixel_size, spawning just one Sprite3D is enough to cause the explosion!

I realize that such large values in the translation don't make sense in a real situation. However, I think the fact that this is somehow related to the pixel_size and the huge memory explosion up to an OS freeze warrant looking into this. I would at least expect the application to fail gracefully, ideally with a hint to the cause. (Debugging this was not fun!)

Minimal reproduction project:

Warning: Running this may crash your PC due to the explosion in memory - terminate the game before the RAM usage gets too high!
TextureLeak.zip

Alternative parameters with just one Sprite3D causing the explosion:

var translation_mod = 100000000
var amount_spawned = 1
var icon_size = 0.0000001

[qarmin]

Seems like it's very deep recursion:

[Calinou]

Related to #20855. Sprite3D performs a lot of work every frame, which may explain this.

[Calinou]

If you can build Godot from source, please build the 3.2 branch and test this again now that #39867 has been merged. (That pull request also makes Sprite3D much faster to render.)

You can also use this Windows 64-bit editor binary for testing.

[FyiurAmron]

@Calinou I've tested it on 3.2.3 today, and it's still happening. Doesn't happen if the translation values stay in the <1E4, maybe <1E5 range (but with the value increasing, the speed visibly drops), but as soon as it hits ~1E6 range, it kills the memory completely.

[clayjohn]

@FyiurAmron it actually looks like this is more of an octree issue. In which case it may be fixed by #41123

Are you able to test on a custom build with #41123?

Cc @lawnjelly

[lawnjelly]

Yes I concur, sounds like octree. Try with my PR or naithar's (linked from mine).

[FyiurAmron]

@lawnjelly do you maybe have a Win binary you could share? I have problems with building from source on my box, for a multitude of reasons. :/

[lawnjelly]

Sorry I can't make one at the moment as I'm away from home this week. I would test it myself and confirm otherwise.

We should have a look at getting at least one of the octree PRs into the 3.2.4 betas soon as it is quite a nasty existing bug which needs fixing, perhaps in beta 2 (I think Akien is building the first soon).

[capnm]

t actually looks like this is more of an octree issue

I can confirm #41123 fixed the attached reproduction project for me.