Makes acid water surfaces emissive again.
However, they are not assinged proper emissive color values for direct
ray hits yet, so they do emit light, but look dar still.
Ref: #56
Only leave water surfaces directed towards "air".
This is consistent with:
- non-`kRenderNormal` surfaces, for which there's only one surface present
- opt2 for translucent surfaces, where we aim to detect medium boundary
direction based on normal-vs-ray-direction
Also add notes about translucent surfaces in general, more info about
water rendering under ref_gl, etc.
Fixes#264
Cull everything except:
- opaque geometry: to avoid shadow and reflection holes
- bleded geometry: particles and such should be visible from any angle
Alpha-tested geometries result in visual glitches when not culled
(double-sided ladders, double shadows, etc). These glitches are worse
than slightly misaligned shadows.
Translucent geometries are still matter of research.
Adds a few things:
- verbose logs about surface flags/type/orientation
- same about surface subdivided polys
- tries culling back water surfaces (doesn't work that well)
- tries culling in rt shaders
This still unfinished
Many static worldmodel surfaces still contain alternate texture chains.
That was making these surfaces dynamic, even though there's no way to
trigger these alternate anims.
Make worldmodel ignore alternate_anims when looking for animated
surfaces.
Fixes#644
Pass current entity to compute wave height. Still doesn't switch to
negative height when underwater for some reason.
And still displays water sides.
Add some notes regarding water geometry generation and drawing.
Adds `_xvk_tex_rotate` field for surface patches. Angle is specified in
degrees.
Note that it rotates the texture around origin, which might be very far
away. So offset patching might be needed to re-align.
This makes it easily switchable at any point in time.
Still not sure how to properly manage log verbosity cvars:
- cvars are loaded after initialization and map load, so we can't really
depend on saved cvar values.
- reloading cvars each frame cancels `-vkverboselogs` arg that is
supposed to work around the above limitation
Fixes a typo that rewrote roughness value with garbage.
Also adds a few more debug channel displays for lighting phases. And
prints out available debug displays.
Fixes#641
Now:
- Not necessarily vulkan-specific cvars are prefixed with `r_`
- Vulkan-specific but not RT-specific things are `vk_`
- RT-specific are `rt_`
Fixes#632
When texture coordinates are inverted, it makes tangent look into
oppsite direction, which inverts TBN and therefore normal map.
Make sure the tangent points to a consistent direction.
Fixes#627
It was using old pre-transform values for prev_verts, and that was
confusing temporal denoiser.
We should bone-transform vertices first, and only then store them as
prev_verts.
Fixes#585
Uses `_xvk_smoothing_excluded` field.
Surfaces can still be smoothed with a limited list of neightbours explicitly
by being included in a smoothing group.
Fixes#619
This is not a valid reason to assert/crash, even though it is clearly a programming mistake.
If the stack is corrupted, just print its contents as an S_ERROR and continue.
Also:
- Fix the ultimate reason for stack being unbalanced for #604
- Do not analyze scopes when not needed, i.e. when `r_speeds` is zero.
Fixes#604
Use dedicated hash table for new material names.
Updates a lot of dependent code:
- surface patches now target materials, not textures:
`s/_xvk_textures/_xvk_material`
- patching now affects only materials, not texture ids. All logic that
depends on texture ids now operate on original textures.
- brush normal smoothing now ignores patched surface materials when
deciding whether two surfaces can be smoothed.
The rationale is that patching should only affect newer PBR/RT code paths.
Legacy ref_interface_t texture access is not refcountable. It does
create/destroy texture in a single call regardless of other users.
Track it with a separate flag that affects refcount with a single +1/-1.
Too many places in the engine and the renderer expect texture names to
be insensitive: RAD files, material references, probably engine and game
calls too.
Make it universally case insensitive. Also, add rudimentary tests for
it.
Previous hash table was case insensitive, while the new one is
sensitive.
For now the workaround is to tolower texture names in rad files.
Proper way would be to address case-sensitivity globally. Currently it's
not very consistent.
Known issues:
- pbr materials are completely broken. They end up not being able to
find textures, seemingly due to memory corruption on materials side,
not textures.
- There are still places that try to get texture=1
Adds unordered_roadmap simple hash map:
- open addressing with linear probing
- size is fixed at init/compile time
- operates on an pre-allocated array of items with hashmap headers
Also adds basic tests for it.
And properly enables tests for ref_vk (i.e. alolcator)
THIS COMMIT IS BROKEN AND LEADS TO MISSING TEXTURES
There's a "race" between texture release/acquire on changelevel.
Textures end up being deleted when they shouldn't.
Addressing this is tedious, will be done in the following commits.
* engine: common: imagelib: add KTX2 support
Adds basic KTX2 support for a few compressed formats. KTX2 essentially
is a Vulkan-centric texture format that supports literally hundreds of
pixel formats.
For now only support for these is added:
- `VK_FORMAT_BC4_UNORM_BLOCK`
- `VK_FORMAT_BC4_SNORM_BLOCK`
- `VK_FORMAT_BC5_UNORM_BLOCK`
- `VK_FORMAT_BC5_SNORM_BLOCK`
- `VK_FORMAT_BC6H_UFLOAT_BLOCK`
- `VK_FORMAT_BC6H_SFLOAT_BLOCK`
- `VK_FORMAT_BC7_UNORM_BLOCK`
- `VK_FORMAT_BC7_SRGB_BLOCK`
Adding more formats is relatively straightforward:
- Copy format definition from `VkFormat` enum in `vulkan_core.h`
- Add a new definition into `pixformat_t` enum.
- Add format size calculation into `Image_ComputeSize()`
While we're at it, also adds a few new formats to DDS:
- BC4_UNORM -- PF_BC4_UNSIGNED
- BC4_SNORM -- PF_BC4_SIGNED
- BC5_UNORM -- PF_BC5_UNSIGNED
- BC5_SNORM -- PF_BC5_SIGNED
- BC7 is expanded into BC7_UNORM and BC7_SRGB
ref_gl and ref_soft code is updated where it made sense. But not tested
really. Support for these formats has been tested with ref_vk.
* address spaces-vs-parentheses formatting where noticed
* parenthesize sizeofs
* move ktx2.h to imagelib as img_ktx2.h; massage it a bit
* use SetBits() instead of |=
* remove stale TODO comments
We were running out of descriptor sets, as they weren't being freed at all.
Now there's a 1-1 table of texture-descset, and no way to run out of them.
Better solution would be to move this descset management to vk_render, and allocate them dynamically from a smaller pool.
Support DDS and KTX2
- [x] Pass KTX2 as raw data
- [x] Simplify image uploading (there are 2 copies of the same uploading code for regular textures and for KTX2)
- [x] Extract long format lists from `vk_image.c` to e.g. `vk_image_extra.h`
- [x] Support DDS formats
- [x] BC7
- [x] PoC works
- [x] read supplied mips
- [x] Pass most common KTX2 subformats as correct PF_ format
- [x] BC5
- [x] BC6H
- [x] BC7 -- need UNORM/SRGB expansion
- [x] BC4 -- need to add it
- [x] Alpha flag for KTX2 formats
- [x] swizzle r->rgba
- [x] check il_dds_hardware
- [x] add `IL_KTX2_RAW_SUPPORTED`
- [x] format imagelib things
- [x] extract image size function to img_utils
Fixes#154
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.
Ivan Avdeev
NightFox
Ivan Avdeev
Ivan Avdeev
Alibek Omarov
mittorn
mittorn
Valery Klachkov