Niko Marmeladkov
a1b0c03a62
Some checks are pending
CI / checks (push) Waiting to run
Ошибка была в моём же исправлении из E11. Экспоненту из четвёртого байта там отбросили, потому что у большинства люкселей байт равен 255, что как i8 даёт -1 и масштаб 0,5, и картинка выходила вдвое темнее. Взамен подобрали плоский коэффициент 3,0, и по освещённым поверхностям совпало. Но затенённые участки выходили втрое светлее эталона, и это было записано как «не найдено». Причина: VRAD нормализует мантиссу так, что её максимум лежит в верхней половине байта, а порядок яркости пишет в экспоненту. Отбросив её, мы сравняли тени с солнцем. Масштаб подобран так, чтобы освещённые участки остались: 2^(-1) * 4,47 = 2,24. Тень с экспонентой -3 получает 2^(-3) * 4,47 = 0,56, вчетверо темнее солнца. Та же камера, что в E11: бетон в солнце GMod 143,6 -> было 147,0, стало 143,7 тоннель GMod 92,9 -> было 165,8, стало 86,8 стена в тени GMod 36,6 -> было 124,6, стало 70,8 небо GMod 199,7 -> 196,9 без изменений Тоннель — то место, где затенение и должно быть сильным: 165,8 -> 86,8 при эталонных 92,9. Это и есть появившиеся тени. Проверено, что динамическое солнце эти участки не освещает: при SUN_BRIGHTNESS_SCALE 900 и 2500 значения совпали до десятых. Вода: ряд длин 46/23/11/5,5/2,7 был кратен ×0,5, из-за чего периоды фаз всех пяти волн синхронизировались и рябь выстраивалась в правильную решётку — на кадре это читалось как гофрированный металл. Заменено на шесть волн с несоизмеримыми длинами 340/210/125/73/41/19. Тест lightmap_ignores_exponent_byte переименован в lightmap_exponent_byte_makes_shadow_darker и проверяет, что разница экспонент на две ступени даёт вчетверо. |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||