Configurable glow map intensity per lighting profile and per texture

[dustinspace217]

What?

Glow maps get two settings instead of the fixed values in the model shader (intensity 1.5, HDR multiplier 3.0):

• A lighting profile can set $Glow Map Intensity: (default 1.5) and $Glow Map HDR Multiplier: (default twice the intensity, so 3.0).
• A texture can override both in a plain-text file named after it and placed next to it, such as shockwave3d.mat beside MediaVPs' shockwave3d texture for the 3D shockwave.
• Decals use their diffuse texture's .mat, or their glow texture's if they have no diffuse, and otherwise the profile's values.

With none of these set, rendering is unchanged.

Why?

Goober asked for this for the Scroll of Atankharzim. Some glow maps, like a shockwave's, need to be brighter or dimmer than everything else, and right now the only way to change glow strength is to edit the shaders.

How?

• The two constants become per-draw shader values (glowIntensity and glowHdrMultiplier in the model block, and two fields that were padding in the decal block). static_asserts pin the C++ layouts.
• A .mat is read once, when its texture loads, and kept with the bitmap. So it follows texture replacement, covers every frame of an EFF, ANI or APNG, and applies wherever the texture is drawn. Edits need a restart.
• .mat files are UTF-8 (a byte order mark is fine); ; starts a comment. Unknown entries, bad numbers and files in other encodings get a warning and are ignored. A Latin-1 .mat is ignored rather than converted as Unicode-mode tables are. Values are capped at 100 so glow stays within the 16-bit emissive buffer, and lighting profiles get the same checks.
• .mat joins the file types indexed in data/maps and data/effects, so older builds never see the files. A .mat follows the usual mod priority: a mod can add one for a MediaVPs texture, and a mod that replaces a texture but wants the default glow can ship an empty .mat.
• A .mat belongs to the base texture: replacing only a glow map keeps the base texture's .mat.
• For the HDR multiplier, the texture's own value wins. Next comes a value the profile sets explicitly. Otherwise it's twice the intensity in use, so under HDR the glow grows with the square of the intensity; setting the HDR multiplier keeps it linear.
• The old constants stay in lighting.sdr for mods that ship their own copies of the model shaders. A mod that overrides main-v/g/f.sdr has to update all three, as with any change to that block.
• In modular tables, set intensity and HDR multiplier together: once a table sets the multiplier, a later table can't send it back to "twice the intensity".

Testing?

• Unit tests for the profile defaults, precedence and value checks, and for .mat files: both keys, comments, UTF-8 comments, tabs, CRLF, a UTF-8 BOM, case and extension in the name, data/maps and data/effects, missing files, other encodings, control bytes and truncated UTF-8, bad, negative, nan and too-large values, unknown entries, and that a texture, an EFF and an APNG all carry their .mat. All pass in Release and Debug, shuffled and repeated. I also broke each rule on purpose and checked that a test failed.
• In game on nightly 26.1.0-20261013 with MediaVPs 5.0.2, OpenGL and Vulkan: with no .mat, screenshots match the nightly apart from 5 pixels on one hull that come from the build settings, not this change. A .mat with intensity 0 on the Hatshepsut's textures removes only that ship's glow, and the nightly ignores the files. A replacement texture uses its own .mat. The lab's hidden-diffuse view still applies the .mat, and one texture's .mat doesn't change the next texture drawn.
• Decals on OpenGL: unchanged at defaults, and a .mat on a decal's texture brightens only that decal.

Anything Else?

Following the discussion on Discord, the per-texture values now live in a .mat file next to the texture instead of in the POF, so this no longer depends on #7864. The branch still carries #7863's commit until that merges; nothing here depends on it now.

While testing I found that decals don't draw at all under Vulkan, including on current master (#7866). The review also turned up two existing overflows in the engine's text readers, filed as #7869 and #7870. Both are separate from this PR.

I used Claude Code to write the change and tests and to run the checks; I reviewed the code and this text.

[The-E]

This is fundamentally wrong and mixes concerns in a bad manner.

Lighting profiles are supposed to hold global settings that apply to an entire mission. They should not hold data that, as per the intent expressed in this and the other PRs linked to this, is set on a per-model basis. The proper way to communicate this data is through the material system, not lighting profiles.

[BMagnu]

The ltp should hold a global default that is then overridden by the per-model/-texture set data

[dustinspace217]

To clarify the flow: the per-texture values do go through the material system. model_render_buffers sets them on the model_material for each texture slot, and convert_model_material copies them into the uniforms. The lighting profile only holds the global default, calibrated next to the tonemapper and exposure, which applies when a texture doesn't override it. If the concern is that model_material reads the profile for that fallback, I can resolve the default before it reaches the material instead. (The diff also includes #7863 and #7864's commits until those merge, which makes it look bigger than it is.)

[The-E]

My apologies, I did not read the flow correctly. I retract my objection.

[dustinspace217]

The revision is done. Per-texture values now come from a .mat file next to the texture instead of the POF, following the Discord discussion, so this no longer depends on #7864. The description is updated, and the PR is ready for review.

[dustinspace217]

Small follow-up: .mat files are now read as UTF-8 rather than plain ASCII. FSO expects UTF-8 text in Unicode mode, and a single non-ASCII character in a comment was making the whole file get ignored. Other encodings still get a warning and are ignored. The description is updated to match.

The second commit marks the two deliberately non-UTF-8 test files as binary in .gitattributes. The Mac clang-tidy step reads the PR diff as UTF-8 and was failing on their bytes.