It only does a very basic header validation, and passes the entire file
as PF_KTX2_RAW format. This is to simplify KTX2 reading in ref_vk and
trying out different formats. KTX2 has support for >200 format, and
passing all of them through PF_ types is a non-starter.
The plan is to figure out which formats we want to support, and add
their support to imagelib/ktx2 incrementally, leaving the rest as
PF_KTX2_RAW, so ref_vk still can use them.
`"inherit" "debug_test"` will replace all fields for the current
material with ones from material named "debug_test".
`"inherit"` should be specified before any material fields, except for
selectors like "new", "for" and "for_rendermode".
Storing it linearly was a mistake: it is 8-bit only, and lacks enough
precision for dark values. It also doesn't really need any more
precision, and should be limited to 0..1 range.
Therefore, it makes sense to treat it as sRGB explicitly.
Traditional renderer operates in sRGB-γ space (as everyone was in 199x).
Making vulkan textures explicitly SRGB for RT renderer breaks color for
trad rendere. Make sure trad renderer still has raw SRGB-unaware texture
sampling.
Adds an UNORM image view for all relevant SRGB textures, and uses them
exclusively for trad renderer. RT still gets proper SRGB views.
Also rename XVK_ to R_Vk for images
Make sure that all SRGB-gamma textures are marked with SRGB format (this
includes all the original textues, 8bit PNG textues). All other
textures (roughness, metallic, normal maps) are linear (UNORM).
Trust KTX2 texture that they store in the correct colorspace.
Then we can just sample textures w/o SRGBtoLINEAR'izing them. Supposedly
this is better because of hw interpolation in the correct colorspace.
This is a bit experimental because Compressonator can't really into
BC7_SRGB, which is sad. And also we need to re-gamma all the textures
for the gamma/srgb-unaware traditional renderer.
They have slightly different incompatible encodings. Switch between them
using #define at build time.
Old png code can be removed when we fully switch to KTX2.
Loads something. Not everything. Not everything correctly.
Doesn't do validity checks.
Makes colorspace (srgb gamma vs linear) inconsistent between textures
(ktx has correct srgb-vs-unorm, all is unorm (but srgb gamma
semantically) in png)
Makes normals inconsistent too (.xy in ktx, .xyz in png)
related #154
Was triggered by renormalizing normal z when applying normal scale.
Not sure why exactly, though, the math checks out.
Doing it a bit differently solves the issue.
Fixes#595
kRenderTransColor mode strips geometry of its texture and makes it solid
color. Previously we were noticing this rendermode late, and failed to
update the textures.
Now we depend on reading this rendermode from map entities, and
pre-assigning correct (white) textures on load.
Assumes that rendermode doesn't change at runtime for brush models.
Fixes#528
- [x] Pass material reference via geom/render API
- [x] Show original textures for traditional renderer, #571
- [x] Remove old material type flags
- [x] ~~Move sky surfaces to a separate BLAS~~ Remove `SURF_DRAWSKY` from geometries completely #474
- [x] **REVERT** `SURF_DRAWSKY` changes. Such surfaces still need to be "drawn" to hide geometry behind it (see comments).
- [x] Chrome material: have an explicit material for it
- [x] This needs vk_texture vs vk_material index decoupling
- [x] Assess #577
- [x] Improve paths #578
- [x] `pbr/maps/c0a0a.bsp/c0a0a.bsp.mat` -> `pbr/maps/c0a0a.bsp/c0a0a.mat`
- [x] `pbr/halflife.wad/halflife.wad.mat` -> `pbr/halflife.wad/halflife.mat`
- [x] Rename files in PBR repo for the above
- [x] `luchiki/maps/c0a0.bsp.patch` -> `luchiki/maps/c0a0.patch`
- [x] Rename patch files too
- [x] Same for spr,mdl
- [x] Rename
- [x] Pass material mode directly, instead of render type
- [x] Advanced material patching/selection
- [x] Need a few advanced selection examples
- [x] #317
- [x] стёкла у костюма (??)
- [x] #526
- [x] #577
- [x] #213
Different render sources (model types, render types, etc) might require
different material modes. E.g. brush should be translucent (refractive+mirror)
for blend mix modes. However, smoke particles should not be
mirror/refractive for the same blend mix render type.