Open SirYodaJedi opened 1 year ago
This is an example of how an implementation might look, from a mapper's perspective:
Only _ewt_embedlightmap
, _ewt_embedlightmap_resolution
, and _ewt_embedlightmap_writeext
are probably integral, but I figured I'd list some other KVs that have features which could be useful.
KV | Type | Explanation |
---|---|---|
_ewt_embedlightmap |
bool | Enable "embedded" lightmaps (equivalent to zhlt_embedlightmap ) |
_ewt_embedlightmap_resolution |
uint | Luxel density; defaults to same density as regular lightmaps (ex: 16:1 texels to luxels) |
_ewt_embedlightmap_subdivsize |
uint | Max texture resolution to use before subdividing. 256 should be a safe default (being the max res supported by GoldSrc's software renderer, as well as the Voodoo 1). |
_ewt_embedlightmap_intensity |
float | Scale the obviousness of the lightmap; default 1.0. Useful for creating stuff that will be turned into static prop models, which will be vertex-lit by the engine. |
_ewt_embedlightmap_writeext |
bool | Write external textures; always enabled for Q2BSP |
_ewt_embedlightmap_extformats |
csv | List of formats to write external textures as; default is TGA (formats: BMP, PCX, PNG, TGA, WAL). |
_ewt_embedlightmap_compressext |
bool | Enable (additional) compression for supported formats (formats: 24-bit PNG - 256-color paletted, 24-bit TGA - RLE compression, 32-but PNG - 255-color paletted with 1-bit alpha if extbinaryalpha is enabled). |
_ewt_embedlightmap_extbinaryalpha |
bool | Allow binary alpha for supported formats (just PNG atm, being the 255-color paletted with 1-bit alpha, if compressext if enabled), as not all engines support such |
External textures are written to the following folders, depending upon output BSP format:
Q1BSP: <moddir>\textures\
Q2BSP: <moddir>\textures\<mapname>
HLBSP: <moddir>\materials\<mapname>
Textures are automatically named to avoid conflicts, and to avoid breaking functionality. A 10-character hash is generated for the name; if two generated textures are identical, then both faces will use the same texture. The first three characters of the original texture name are retained, which ensures that most special prefixes still work ({
, !
, #
, *
, +x
, -x
, ~
, @
, etc.), with the exception of HLBSP scrolling textures (as those wouldn't look nice with embedded lightmaps anyway). To keep the embedded lightmaps from intermingling with regular textures when using Q1BSP external textures in the mapper's filesystem, the string l_
is be placed between the three prefix characters and the hash.
So a texture name might look like this: +0~l_e2cfc89fae
When embedded lightmaps are used with an animated, toggled, or randomly tiled texture set, baked versions of all possible textures are created. Naturally, that will exponentially increase file size, but such a use-case is unlikely to be common.
_ewt_embedlightmap_compressext
, because the vanilla engines and many derivatives don't read RLE-compressed 32-bit TGAs correctly. 24-bit TGAs can be RLE-compressed with no issues._ewt_embedlightmap_extbinaryalpha
would cause generated DDS textures with transparency to use DXT1 instead of DXT5 or BC7_ewt_embedlightmap_compressext
would result in a compression level of 90 instead of 98, or maybe it would enable chroma subsampling (which I usually disable for JPEGs myself)zhlt_embedlightmapresolution
apparently results in downscaling the texture (to save file size, allegedly). I don't think it makes sense to implement an equivalent; users can downscale the texture beforehand.
A feature in VHLT and forks, "embedded" lightmaps are lightmaps that are baked into the diffuse texture, for textures that cannot be lightmapped on certain engines.
These have a few use cases: