Allow importing textures as 16 bpc integer format

[William-Godwin]

Describe the project you are working on

I am working on implementation of a large terrain for my game.

Describe the problem or limitation you are having in your project

To reduce the amount of data and the number of sampler calls, I packed the heightmap into RGBA channels. Original format I'm using -- an uncompressed format in 16bit. Unfortunately, when I import the map into the engine, I get a 32bit image. This greatly increases the size of the map, which greatly affects performance. In addition, because the map is quite large, the file itself weighs 1024mb. If it will be in 16bit, it would take only 512 mb.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

If this is possible now, after freezing new features, I would like to be able to select bits when importing. In addition, I think that it would be very useful to add a choice of number of imported channels for the image. Sometimes It's useful for masks and some FX. It helped me a lot when I was working in Unreal Engine.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I'm not sure how best to implement this functionality. In the unreal engine, this was pretty easy.
https://docs.unrealengine.com/4.27/en-US/RenderingAndGraphics/Textures/TextureCompressionSettings

If this enhancement will not be used often, can it be worked around with a few lines of script?

I'm pretty sure it's not possible to implement in script.

Is there a reason why this should be core and not an add-on in the asset library?

I think this is a very important feature that is useful to most developers.

[Calinou]

Related to #5182 and #2107.

To reduce the amount of data and the number of sampler calls, I packed the heightmap into RGBA channels.

I remember being able to import 16-bit float data using an OpenEXR (.exr) or Radiance HDR (.hdr) image. However, since it's 16-bit float (and not integer), it doesn't have consistent precision throughout the range.

I wonder if you can use the LA8 format already (grayscale PNG with an alpha channel). However, you'll have to enable the Force PNG project setting for this to work: godotengine/godot#56523

[William-Godwin]

I remember being able to import 16-bit float data using an OpenEXR (.exr) or Radiance HDR (.hdr) image. However, since it's 16-bit float (and not integer), it doesn't have consistent precision throughout the range.

Thanks for the quick response! Yes, I use .exr, but it can't be compressed for this task.

I wonder if you can use the LA8 format already (grayscale PNG with an alpha channel). However, you'll have to enable the Force PNG project setting for this to work: godotengine/godot#56523

I tried the available import options again. If we talk about my main problem, then this can only be solved with VRAM uncompressed 16 bits. (Because it's a heightmap) It was a big surprise for me that my 16 bit .exr is converting to 32. Otherwise, .exr works fine. =)

If I use the same image in 8 bits it gives me 1.5-2 ms. Of course 16 bits will be worse, but it's still frustrating.
Actually there is a way which I saw here. Also, I was thinking about trying to pack 2 16bit heightmaps into one 32bit channel, but... I have no idea how exactly to do it. =)

[William-Godwin]

But this increases the number of texture samplings, most likely by 2 times.

I've been thinking about it for a bit now... Perhaps this problem can be solved with texture arrays. But it's still not that easy. Because it's necessary to divide maps into channels of 8 bits. Then create a texture array from those textures. However, I'm still not sure whether it's possible to pack textures in this way using, for example, a substance designer.

[Calinou]

Yes, I use .exr, but it can't be compressed for this task.

Compressed OpenEXR is supported in 4.0, but this wasn't backported to 3.x.

[William-Godwin]

Sorry, my English is't good enough. =) Perhaps I didn't explain the situation clearly. We can't use compression to import height maps, because the range of values mast de at least 65536.
In addition, as I understand it, there is a bug in 4.0-17alpha, when importing exr with any parameters of the import, we get RGBAfloat.

Even when importing an image with only one gray channel. That's why I also wrote about channels.

[William-Godwin]

@Calinou As I understand it, in 12 or 11 beta, texture import support half precision.
And this issue can be closed?

It is important to clarify that the EXR image with one channel is still imported as RGBA.

[Calinou]

As I understand it, in 12 or 11 beta, texture import support half precision.

Yes, when using OpenEXR or Radiance HDR images. This is also supported in 3.x. To clarify, "half precision" is half floating-point precision.

It is important to clarify that the EXR image with one channel is still imported as RGBA.

This is likely due to the same cause as godotengine/godot#56523.

[William-Godwin]

@Calinou
This issue has reappeared in recent versions. When importing open exr with any import parameters, we get RGBAfloat. =( Do I need to create an issue for this?

[Calinou]

@Calinou This issue has reappeared in recent versions. When importing open exr with any import parameters, we get RGBAfloat. =( Do I need to create an issue for this?

This is likely related to godotengine/godot#72031 and its subsequent regression godotengine/godot#72666. Double-check that VRAM compression is disabled in the Import dock (you want to use the Lossless compression mode instead).