Cannot use EXR as internal heightmap format

[Zylann]

Currenlty, the heightmap is saved internally as a binary blob, because Godot doesn't support saving an Image using a 16-bit color depth format. The downside is, it occupies more memory and cannot be inspected with an image editor. Ideally, I would need a 16-bit UNORM format. PNG and EXR would be good candidates.

Depends on https://github.com/godotengine/godot/issues/17450

Godot 4 update: https://github.com/Zylann/godot_heightmap_plugin/issues/34#issuecomment-1490677299

[SIsilicon]

Hey I have an idea. What if instead of putting the height in one 16-bit component of an image, why not encode it in two 8-bit components. Then when you read it, you can decode it back into 16-bits of glorious precision.

[Zylann]

I thought of that already, but that would not solve all problems. It would reduce disk memory usage a bit, but it would slow down loading because I have to convert the image pixel per pixel, which actually consumes more RAM because both images need to exist during conversion. I would rather prefer an actual image format because a "packed" 8-bit format isn't usable externally either.

[SIsilicon]

W-wait.

both images need to exist during conversion.

Both images?

What's the second one?

[Zylann]

First image is the one I load from disk. Second image is a converted copy. They have to both exist in RAM during the conversion process from 8-bit to 16-bit (using GDScript). Thing is, I'd want to avoid that, because terrain data is big.

[Zylann]

Due to low-level byte layout it could be possible to not copy it, but I don't know if that's doable with the GDScript API.

[SIsilicon]

I'll try it out myself. See what happens, and how fast it would be.

[Zylann]

I think it should work tbh, but I'm not sure if it's worth it. I'd rather have 16-bit PNG support straight-away :)

[SIsilicon]

Yeah me too. I was just thinking of alternatives if there aren't any other options that Godot 3.0.2 has.

[Zylann]

Just a quick update on that: due to https://github.com/Zylann/godot_heightmap_native_plugin/issues/50, I will change the way heightmaps are saved by simply using the .res format. It's still the same uncompressed data, but at least it will be easier to load and will be exported by default.

[Zylann]

In Godot 3.2, saving as a single-channel greyscale EXR image works, with https://github.com/godotengine/godot/pull/31047 However, loading an EXR still doesn't work as expected, because it produces 3-channel float images instead of a single-channel one (which wastes x3 memory at runtime). The plugin may have to keep using a .res until single-channel EXR can be loaded as-is.

[Redwarx008]

In my program, I also have this problem, godot loads the exr file and it automatically expands to three channels. Another thing I couldn't stand is that the same image exr file reads about 1/30 of the png value and is weird when multiplied by the height, which eventually made me give up on exr. Now I use a third party library in C# to handle 16bit png files, just a little slow when loading.

[MJacred]

With https://github.com/godotengine/godot/pull/41925, single-channel and dual-channel are now possible. But it would be a Godot 4 only feature

[Zylann]

In Godot 4 I started using RGB8, so now the heightmap is saved as a regular PNG. EXR would be used if supporting float32 was viable, unfortunately it isn't because GPU editing of such textures isn't possible without using Vulkan compute shaders, while RGB8 can be edited using viewports and works both in Vulkan and OpenGL renderers.

So I guess the problem now has shifted down to Godot no longer supporting 2D HDR viewports (or a similar API to support the use case).

[MJacred]

Then I reckon this issue can be closed (as there's no cherry-pick for Godot 3 of the mentioned PR)?

[Zylann]

Can't be closed, as it turns out RF might be usable in the end, but that means we would get the problem again if we want to use EXR.