Investigate possibility of returning Godot Image instead of saving

[kb173]

Currently we take a detour over the disk since we save images, and then load them again in Godot. If possible, it would be great if we could directly return the image from GDAL to Godot in RAM.

[kb173]

This was implemented in c39d8b7. It's a bit hacked together at the moment, but the whole pipeline works as intended.

I suggest doing some performance testing with both the new commit and the previous one. If saving the image to disk and loading it in Godot (previous commit) is comparably performant as the new solution, I suggest we go with that since it's a bit more flexible and there are less opportunities for memory leaks. If the new method is significantly faster (which I think it should be, since it doesn't save to disk, but it does require reformatting the raw array into a PoolByteArray), it will be cleaned up and kept.

[chrisgraf]

sounds reasonable. i saw in your TODOs that there is already a memory leak somewhere?

[kb173]

Yes, but nothing mysterious, just missing cleanup code. I wanted to make something functional as quickly as possible so we can do performance testing. The version we stick with will be cleaned up.

[kb173]

The original method of saving the file to disk and loading it in Godot can load around 7 images per second from the heightmap to Godot on my test setup. The newer method loads around 20 images per second. In addition, we would have to create a PNG instead of a GTiff in order to be able to use the image as an ImageTexture with the saving method. This step is not required when using the image in RAM, since it doesn't have a specific format, it's just an array.

I'd say the RAM method is more promising.

Note that both methods are (equally) unoptimized, so final results should be even better.

[kb173]

The RAM method was refactored and cleaned up now. The whole pipeline works in the Godot demo project; the clipped heightmap is displayed on a mesh.

When creating 5x5km images at 256x256 pixels, about 26 images can be created per second. The performance mostly depends on the scale (in km); the transfer of the image itself seems to be negligible, so this issue is done.