Add support for the GL_RED format, use it, also rework format detection

[illwieckz]

• tr_image: rework the alpha detection
• renderer: implement and detect RED and RG images
• renderer: introduce and use IF_NOALPHA
• tr_backend: fix a comment
• tr_image: flag glyph image with IF_ALPHA
• sdl_glimp: fix the EXT/ARB texture_rg confusion
• tr_image: document the GL_RGB format
• tr_image: add some GL format checks and asserts
• tr_image: reshape the cinematic image generation a bit
• tr_image: reshape the default image painting a bit
• tr_image: make some iterators more local

---

Previous message:

• tr_image: reword the fog generation code
  That's just beautifying, following patches are written above this
• tr_image: store the fog alpha channel in red one
  Imported from WIP: tr_shader: linearize fog colors and fog image #1730
  but without the colorspace-related HACKs
• renderer: add support for the GL_RED image format
  Imported from WIP: tr_shader: linearize fog colors and fog image #1730
• tr_image: upload _fog image as GL_RED
  Imported from WIP: tr_shader: linearize fog colors and fog image #1730
• tr_image: upload _black, _red and _blackCube images as GL_RED
• tr_image: rework the alpha detection
• tr_image: detect RED images
• renderer: introduce and use IF_NOALPHA
  Useful for when we know in advance an image has no alpha channel
• tr_image: do not rely on previously set data for _cinematic, make sure it cannot be detected as RED
• tr_backend: fix a comment
  Actually GL_COMPRESSED_* formats can be used (they let the driver decide), but we don't use them.

[illwieckz]

We may also upload standalone height maps as GL_RED too, unfortunately doing that will loose precision since as far as I know the DXT storage is 5:6:5 and then the red component features less bits than the green one.

[illwieckz]

We may also upload standalone height maps as GL_RED too, unfortunately doing that will loose precision since as far as I know the DXT storage is 5:6:5 and then the red component features less bits than the green one.

I'm doing the same mistake again… DXT images can't be uploaded as GL_RED. 🤣

[VReaperV]

This doesn't seem to do what the commit message says?

[illwieckz]

That removes the IF_RED flag for the next textures that cannot be uploaded as GL_RED.

[VReaperV]

Does this actually work? I assume the check for IF_LIGHTMAP could've been there because lightmaps might contain some garbage in the alpha channel.

[illwieckz]

Long time ago the code was doing:

		if ( image->bits & IF_NORMALMAP )
		{
			if ( image->bits & ( IF_DISPLACEMAP | IF_ALPHATEST ) )
			{
				samples = 4;
			}
			else
			{
				samples = 3;
			}
		}
		else if ( image->bits & IF_LIGHTMAP )
		{
			samples = 3;
		}

It was just a code setting known formats for known input.

The current code in master (that is modified by this PR) was a modification I made: 071c789

The IF_LIGHTMAP test was just there because we already knew there is no alpha channel in a lightmap. Q3map2 doesn't produce alpha channel (and should not).

I added a more generic IF_NOALPHA flag that can be used for other things than lightmaps, like the deluxemaps, and other things, instead of only checking for lightmaps as a known input with known format.

[illwieckz]

This alpha channel detection code is never expected to be run on lightmaps to begin with, and now also not on other images I flagged with IF_NOALPHA.

[slipher]

The fog image is pretty pointless, all it really does it calculate sqrt(x). We should just do that in GLSL. I think it only exists because someone ported the code from GL1 in an overly mechanical way.

[illwieckz]

The fog image is pretty pointless, all it really does it calculate sqrt(x).

Oh, that's interesting! Would you also know what computation to expect when blending the linear way? Or maybe it should have been sqrt() in linear space but the naive blending did garbage and we're accustomed to it?

We should just do that in GLSL. I think it only exists because someone ported the code from GL1 in an overly mechanical way.

If we can that would be nice.

[slipher]

Oh, that's interesting! Would you also know what computation to expect when blending the linear way? Or maybe it should have been sqrt() in linear space but the naive blending did garbage and we're accustomed to it?

Square root doesn't make much sense as a model for the fog; probably they just tried random functions and picked something that looked OK. Instead of sqrt(a*x), 1 - exp(b*x) would be an obvious model to use (as if the fog is formed from layered alpha blending). a/b is a constant based on the fog density. You can make these functions match up somewhat using appropriate constants: https://www.desmos.com/calculator/abvkogdqzy

[illwieckz]

That looks ready to me.

[illwieckz]

I fixed an non-optimal code path, it was testing for RED before testing for ALPHA, meaning a red texture with an opaque alpha channel was only detected as RGB, not as RED. Now fixed:

]/listImages *red*
------------------------------------------------------------------------- 
num   width height layers mm  type format   space  wrap.t   wrap.s   name 
------------------------------------------------------------------------- 
3         8      8      1 no  2D   R8       linear t.rept   s.rept   _red 
99       64     64      1 no  2D   DXT5     linear t.clmp   s.clmp   emoticons/featured 
119     256    256      1 yes 2D   RGB8     linear t.rept   s.rept   textures/pulse/metal-red.tga 
120     256    256      1 yes 2D   RGB8     linear t.rept   s.rept   textures/pulse/metal-red 
158     256    256      1 yes 2D   RGB8     linear t.rept   s.rept   textures/pulse/e8base_red 
159     256    256      1 yes 2D   RGB8     linear t.rept   s.rept   textures/pulse/e8base_red.tga 
233      16     16      1 no  2D   R8       linear t.rept   s.rept   textures/pulse/red16x16.tga 
262      16     16      1 yes 2D   DXT1     linear t.rept   s.rept   gfx/buildables/common/redbuild 
281      16    256      1 yes 2D   RGB8     linear t.rept   s.rept   gfx/cgrading/red-only 
------------------------------------------------------------------------- 
0 total texels (not including mipmaps) 
1.01 MB total image memory (estimated) 
689 total images 
------------------------------------------------------------------------- 

Unrelated to that branch, but I notice we have both textures/pulse/metal-red.tga and textures/pulse/metal-red loaded… that doesn't look right. That should be investigated separately.

[illwieckz]

Very good:

2         8      8      1 no  2D   R8       linear t.rept   s.rept   _black
3         8      8      1 no  2D   R8       linear t.rept   s.rept   _red
39      256     32      1 yes 2D   R8       linear t.clmp   s.clmp   _fog
47       32     32      6 no  CUBE R8       linear t.eclmp  s.eclmp  _blackCube
519      32     32      1 yes 2D   R8       linear t.rept   s.rept   textures/atcshd/bulb_red.tga
522      64     64      1 yes 2D   R8       linear t.rept   s.rept   textures/atcshd/black

[illwieckz]

This now also support and detect RG textures, and use explicit GL_R8 instead of GL_RED when supported.

]/listImages *16x16*
-------------------------------------------------------------------------
num   width height layers mm  type format   space  wrap.t   wrap.s   name
-------------------------------------------------------------------------
205      16     16      1 no  2D   R8       linear t.rept   s.rept   textures/pulse/black16x16.tga
280      16     16      1 yes 2D   RGB8     linear t.rept   s.rept   textures/pulse/white16x16.tga
283      16     16      1 no  2D   RGB8     linear t.rept   s.rept   textures/pulse/white16x16.tga
291      16     16      1 yes 2D   R8       linear t.rept   s.rept   textures/pulse/black16x16.tga
296      16     16      1 no  2D   R8       linear t.rept   s.rept   textures/pulse/red16x16.tga
302      16     16      1 no  2D   RG8      linear t.rept   s.rept   textures/pulse/green16x16.tga
-------------------------------------------------------------------------
0 total texels (not including mipmaps)
0.00 MB total image memory (estimated)
752 total images
-------------------------------------------------------------------------

[illwieckz]

So yes there was a pre-existing confusion on master related to some RG extension but it was less problematic than what I thought at first, it was just a naming mess.

[illwieckz]

Detection works well:

]/listImages *shared_colors*
-------------------------------------------------------------------------
num   width height layers mm  type format   space  wrap.t   wrap.s   name
-------------------------------------------------------------------------
614       1      1      1 yes 2D   R8       sRGB   t.rept   s.rept   textures/shared_colors_src/black_d
615       1      1      1 yes 2D   RGB8     sRGB   t.rept   s.rept   textures/shared_colors_src/gray_d
616       1      1      1 yes 2D   RGB8     sRGB   t.rept   s.rept   textures/shared_colors_src/white_d
617       1      1      1 yes 2D   R8       sRGB   t.rept   s.rept   textures/shared_colors_src/red_d
618       1      1      1 yes 2D   RG8      sRGB   t.rept   s.rept   textures/shared_colors_src/orange_d
619       1      1      1 yes 2D   RG8      sRGB   t.rept   s.rept   textures/shared_colors_src/yellow_d
620       1      1      1 yes 2D   RG8      sRGB   t.rept   s.rept   textures/shared_colors_src/chartreuse_d
621       1      1      1 yes 2D   RG8      sRGB   t.rept   s.rept   textures/shared_colors_src/green_d
622       1      1      1 yes 2D   RGB8     sRGB   t.rept   s.rept   textures/shared_colors_src/spring_d
623       1      1      1 yes 2D   RGB8     sRGB   t.rept   s.rept   textures/shared_colors_src/cyan_d
624       1      1      1 yes 2D   RGB8     sRGB   t.rept   s.rept   textures/shared_colors_src/azure_d
625       1      1      1 yes 2D   RGB8     sRGB   t.rept   s.rept   textures/shared_colors_src/blue_d
626       1      1      1 yes 2D   RGB8     sRGB   t.rept   s.rept   textures/shared_colors_src/violet_d
627       1      1      1 yes 2D   RGB8     sRGB   t.rept   s.rept   textures/shared_colors_src/magenta_d
628       1      1      1 yes 2D   RGB8     sRGB   t.rept   s.rept   textures/shared_colors_src/rose_d
629       1      1      1 yes 2D   RGBA8    sRGB   t.rept   s.rept   textures/shared_colors_src/transparent_d
-------------------------------------------------------------------------
0 total texels (not including mipmaps)
0.00 MB total image memory (estimated)
630 total images
-------------------------------------------------------------------------

[illwieckz]

I found a bug in the code in master where we only iterate the first layer of an image for detecting the format. Now fixed.

[illwieckz]

I noticed that would modify an undocumented feature of _black, previously it was usable to make a transparent texture:

transparent
{
	map _black
	blend blend
}

Because all its channels were set to 0, including the alpha one.

But when stored as RED the alpha channel is opaque (so, 1).

But I have seen no map in the whole betaserv corpus that used any _black, *black, $black, $blackimage keywords at all, so even not used as trick with blend to get a fully transparent texture.

Actually it bugged me that the black image was not opaque black.

[slipher]

Fog image stuff can be dropped.

Do we really need to have the _red image at all?

[illwieckz]

Yes we may purge those color variants.

[illwieckz]

This PR is expected to be rebased after #1804 is merged:

• tr_image: rework some builtin images #1804

So this PR is currently not in mergeable state.

[illwieckz]

Detecting the RG images is less needed after we drop all the color image variants that are not white and black, as seen in:

• tr_image: rework some builtin images #1804
• rewrite the common and colors shaders in a better way UnvanquishedAssets/tex-common_src.dpkdir#9

Though, this can still be useful for optimizing the upload of legacy images from legacy paks, that are not DXT-compressed, and then for which we can detect if they use their blue channel or not.

This PR actually fixes a bug in detecting the alpha channel presence (it only looked for the first layer of an image).

This also adds IF_NOALPHA to skip the detection of the alpha channel when it is known the image is fully opaque, it already uses it for a bunch of builtin images.

Something not implemented in that PR is to flag images with IF_NOALPHA when they are part of a shader without blend functions, something we can do, but I'm postponing this. Especially, we may need some revamp to be done first, as some images are loaded before the stage is entirely parsed (and then the blending is unknown). But that's likely something I want to do later.

Also something I want to do later is to reimplement the GL compression of non-DXT-compressed images, for use with the legacy assets full of non-crunched JPG or TGA files. I actually have a working branch for that, based on an older version of this branch, but then again that's for later.

Some commits do some beautifying or improve consistency with other parts of the code around to ease the reading.

[slipher]

How much memory do we expect to save from this red image detection?

[slipher]

Why are we even passing in data there? Can't we put in nullptr for the data like when making an FBO?

[illwieckz]

I have no idea, but that would have to be investigated for another PR, not this one.

[illwieckz]

How much memory do we expect to save from this red image detection?

That's one of my concern. Now that we ditched the color images, and after we will use q3shader code for common colors instead of pixmaps, not only RG detection but also RED detection becomes less useful.

This can still benefit some legacy maps, for example the pulse maps has some plain red and green images for displaying the door closed/open status in the control room, legacy maps may have things like that, pure black, red or green images, the win isn't very big.

[slipher]

Yeah I don't think the complexity is worth it if we are going to only save like 10 KB or something. The color detection code is rather convoluted.