Гипотеза Gemini (нормаль из dv.vec) не подтвердилась: сырые байты LUMP_DISP_VERTS
читаются как f32 с шагом 20 и дают осмысленные значения (vec=(0,0,1),
dist=18.145). Формат разобран верно.
Ориентация рельефа в порядке: 110 плоскостей вверх, 0 вниз, намотка не
перевёрнута (0 из 11776). У спавна рельеф плоский — z от -151.4 до -148.0,
поэтому «наклонены 104 вершины» это свойство карты, а не баг.
Найдена ошибка в моей же сверке: справочник лампов читался со stride 48 вместо
16. Из-за этого LUMP_NODES выглядел навмешем, а лампы 6 и 18 менялись местами.
Выводы части E14 про LUMP_NODES недействительны.
«Белые плиты» разобраны: у материала color/white всего 9 граней, и это не
ящик, а тонкие пластины 64x4 и 128x4 с нормалями ±X/±Y на четырёх высотах —
то, что на глаз читается как «оси координат 3д». Большая белая поверхность в
центре — другая: бетонная плита 2480x1936 над спавном, продублированная
(9379==9385, 9380==9386), дубль есть в самой карте.
Чёрные области проверены экспериментом: отключение тенев и отсечения задних
граней меняет картину, значит чёрное приходит из лайтмапы, а не из теней.
Подробности и следующие шаги в PARITY.md E15.
Жалоба: «в 0 0 видны белые плиты, которых нет в оригинале, причём у них
коллизия есть».
Измерено: материал GM_CONSTRUCT/COLOR_ROOM с текстурой color/white, ровно
9 граней, габарит (-1240,-968,-204)..(1240,968,204) — ящик 2480x1936x408 в
центре карты, точка спавна игрока внутри. surf flags 0x0, то есть SURF_NODRAW
не выставлен; стили [0,255,255,255] — свет не запечён.
Гипотеза «это сетка навигации» не подтвердилась: у info_node в лампе сущностей
нет ключей brushes и brushlist, и ни одна сущность на карте brushlist не имеет.
LUMP_NODES — это дерево BSP, не навмеш. Ни одна белая грань не привязалась к
кирпичу по planenum через LUMP_BRUSHSIDES.
Попутно выяснилось, что кирпичи и грани не параллельны: 2203 кирпича, 14946
сторон, 9460 граней. Отсев «границы сущности -> номера граней» не тривиален.
Добавлена заготовка NavHulls с честной пометкой, что отбор пуст и ничего не
отсекает. Подробности и следующие шаги в PARITY.md E14.
Ошибка была в моём же исправлении из 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 и проверяет, что разница экспонент
на две ступени даёт вчетверо.
Теней в движке не было вообще — это и было причиной того, что плоская трава
читалась как «вывернутая», хотя намотка рельефа верна: плоскости 110 граней
смотрят вверх, развёрнуто 0 из 11 776 треугольников. Проверка переворотом
подтвердила: при инверсии становится вверх 8 008 / вниз 10 353 и разворачиваются
все треугольники, то есть явно хуже.
Добавлена карта теней 2048x2048 (Depth32Float), ортографическая проекция на
область радиусом 2 600 юнитов вокруг камеры по направлению на солнце. Отдельный
пасс глубины со стороны источника; вода в него не идёт — она полупрозрачна.
В шейдере луч сравнивается с картой четырьмя сравнениями по соседним текселям
и сглаживается smoothstep, иначе край тени идёт лестницей. Смещение по
нормали на 3 юнита убирает полосу самозатенения.
Солнце в небе: направление пишется в uniform камеры шестым vec4, небо рисует
ядро 2,5 градуса и ореол до 12.
Сверка с GMod на той же камере, что в E11:
бетон 143,6 -> 147,0 (было 87,8)
трава 127,1 -> 129,0 (было 77,3)
небо 199,7 -> 196,9
Расходится стена в тени: GMod 36,4, у нас 124,6. Основной свет даёт запечённая
лайтмапа, а динамическое солнце при SUN_BRIGHTNESS_SCALE = 900 вносит малую
долю, поэтому затенение этой стены у нас не гаснет. Причина не найдена,
записана в PARITY.md E12.5.
Заодно добавлен Mat4::ortho в math.
Затухание было 1/(1 + d²·0.00012) — на 900 юнитах это 0,01, и озеро с высоты
читалось зеркальной плитой. Алиасинг бьёт только по мелким волнам: дальше
пикселя. Заменено на затухание по волновому числу каждой волны отдельно,
local = 1/(1 + (k·d·0.01)²). Волна длиной 46 юнитов на 900 юнитах ещё видна
(0,4), длиной 2,7 — уже нет (0,002).
discard считался по волновой нормали: на скользящих углах dot(n, view)
проваливался в ноль и поверхность выбивалась дырками, край озера рвался
зубцом. Теперь facing берётся по плоской поверхности — это вопрос геометрии,
а волновая нормаль идёт только в френель и блик.
Сверено с настоящим GMod на одной камере: точка (-399.5, -1604.5, 67.9),
yaw 146.33, pitch 3.48, fov 100. Наш кадр снят в той же точке, ракурс совпал.
Первое сравнение: небо сошлось (0,97-1,00), а поверхности были темнее вдвое.
Причина — четвёртый байт люкселя читался как i8 и давал масштаб 2^exp; у
большинства люкселей он равен 255, то есть как i8 это -1 и масштаб 0,5.
Масштаб подобран по эталону на двух разных материалах:
0,5 -> бетон 70,5 / трава 52,8
1,0 -> 87,8 / 77,3
2,0 -> 122,0 / 107,8
3,0 -> 147,0 / 130,3
GMod -> 143,6 / 127,1
Один коэффициент попал в эталон на двух материалах, значит это найденная
величина, а не подгонка.
Заодно:
- водa: сумма герстнеровских волн вместо ровной синусоиды — острые гребни и
широкие ложбины; референсы дают прямое указание «Gerstner, not sine»;
- плавание: вход подавался как направление (-1..1), а не скорость, поэтому
горизонтальная скорость была 0,8 юнита в секунду вместо 200;
- ноклип: скорость при отпускании клавиш не обнулялась — это инерция; теперь
обнуляется, а пробел такой же ввод, как «вперёд»;
- добавлен --fov, по умолчанию 100 как в GMod.
Тесты на плавание и на инерцию в ноклипе добавлены.
Нашли сравнением с настоящим GMod — запустили клиент через Steam и сняли ту
же точку карты. Сравнение по зонам: небо совпадает (178,7 против 175,5), а
земля расходится (60,3 против 167,5). Канал вывода и гамма верны, расходится
геометрия.
Расходился не только уровень, но и тон: GMod (1.000, 0.973, 0.866) — тёплый
солнечный, наш (0.756, 0.960, 1.000) — холодный синий.
Люксель лайтмапы лежит в блоке как B, G, R, экспонента, а читался как R, G, B.
Сырые байты на gm_construct — [141, 208, 251, 255]: как RGB — холодный синий,
как BGR — тёплый солнечный.
Подтверждение независимое: цвет солнца из light_environment на этой же карте
тёплый, [1.046, 1.011, 0.942]. Запечённая лайтмапа обязана быть того же тона.
_ambient при этом 114 136 148 (B > G > R) — синева, и это верно: небесная
добавка холодная.
После обмена R и B тон стал (1.000, 0.960, 0.756) — совпал с GMod.
Яркость после обмена не изменилась: разрыв в 7,8 раза по линейному
пространству остаётся. Причина, судя по коду, в том, что солнце прибавляется к
лайтмапе, уже содержащей запечённое солнце, плюс домножается ambient, плюс
SUN_BRIGHTNESS_SCALE = 900. Не починено и записано в PARITY.md E10.3.
Тест light_sample_missing_is_white поправлен под новый порядок каналов.
Симптом: «на видео нету освещения вообще». Предыдущий замер показывал
среднюю лайтмапу 0,22 и делал вывод, что темно «от данных карты». Вывод был
неверен.
Замер ориентаций вершин gm_construct вскрыл причину: строго вверх — 17
вершин, строго вниз — 18 096. У настоящей карты пола смотрят вверх.
Причина: face_normal брала нормаль плоскости с обратным знаком
(`if side == 0 { -normal }`). В VBSP нормаль плоскости грани уже смотрит
наружу от твёрдого тела. Инверсия попала в код при попытке починить
намотку, но намотку чинит отдельная face_winding — она сравнивает
геометрическую нормаль треугольника с нормалью грани и переворачивает обход
сама.
Следствие: солнце и запечённая лайтмапа попадали на изнанку всех
поверхностей. Пол не получал ни того, ни другого.
Стало: вверх 15 195, вниз 2 918. Тест real_map_normals_are_not_inverted
не даёт дефекту вернуться.
Заодно второй настоящий баг в том же месте: в sample_light_luxel ширина
строки блока лайтмапы считалась как extent[0], а блок — это
(extent[0]+1) × (extent[1]+1) люкселей. Каждая строка читалась на люксель
раньше, и к низу блока чтение уезжало на десятки люкселей в сторону.
Долго висевшее «белое пятно» оказалось не дефектом: это комната Construct,
материал GM_CONSTRUCT/COLOR_ROOM с VMT UnlitGeneric и базовой текстурой
color/white — белая по замыслу и неосвещаемая. Спавн игрока внутри неё.
Рябь на воде подобрана замером: частота 0.035 давала плиту, 0.35 —
aliasing на горизонте, остановились на 0.12 и 0.19; третью полосу убрали —
её наклон давал клинья поперёк озера.
Зафиксировано то, что измерено, и то, что осталось неопознанным — включая
белую площадку в кадрах: пустых текстур нет, SURF_NOLIGHT рядом только у
skybox (и они не рисуются), белый материал один и с этого ракурса не виден,
формат захвата тот же sRGB, что у экрана.
Воды в физике не было вовсе: она только рисовалась (SURF_WARP → шейдер воды).
Жидкости даже не хранились — Collision::from_bsp отбрасывал всё, что не
CONTENTS_SOLID, а вода как раз не SOLID. Итог: игрок входил в озеро и шёл по
нему как по пустоте.
- Liquid — объём жидкости (полупространства + CONTENTS_*), хранится отдельно.
Отбор по содержимому перенесён ДО отсева по SOLID: на gm_construct такой
кирпич ровно один (0x10000020 = CONTENTS_WATER | CONTENTS_ORIGIN), и из-за
отсева вода не находилась вообще.
- Collision::point_contents — аналог GetPointContents.
- Player::check_water — CheckWater: три пробы, уровень WL_NotInWater…WL_Eyes.
- Player::water_move — WaterMove: гравитации нет, пробел даёт полную скорость
вверх, без ввода игрок тонет (wishvel[2] -= 60), желаемая скорость режется
до 80 %, трение по всей скорости, разгон той же квото-формулой.
- Player::water_jump — CheckWaterJump: преграда по поясом, место над головой,
опора под ногами не круче sv_walkable_normal; скорость 256, WaterJumpTime 2 с.
- drowning_time и breath(): под водой воздух кончается, в воздухе
восстанавливается, полное время 15 с.
- Вода по колено: гравитация действует, вертикальная скорость гасится в 0,9.
FullWalkMove собран как в оригинале: StartGravity только если CheckWater вернула
ложь, при WL_Waist вместо WalkMove идёт WaterMove.
Замер на gm_construct: озеро (-3072, 1985, -960)..(1856, 6464, -160); без ввода
игрок через 10 с на дне z = -960, с пробелом всплывает до -194,8. Остановка
всплытия ровно по пояс — верное поведение Source, выпрыгнуть из бесконечного
бассейна нельзя, только на борт через water_jump.
Трение и ускорение в воде взяты из WaterMove SDK 2013 (sv_friction, sv_accelerate).
У GMod есть sv_waterfriction и sv_wateraccelerate, но где они применяются,
проверить не удалось: в публичных исходниках их нет.
«Дырки в крыше, сквозь которые нельзя упасть»: граней в картинке было меньше,
чем в коллизии. Причина — константы SURF_* в world.rs были перепутаны. По
public/bspflags.h Source настоящие значения:
SURF_SKY2D 0x0002 SURF_NOPORTAL 0x0020
SURF_SKY 0x0004 SURF_TRIGGER 0x0040
SURF_WARP 0x0008 SURF_NODRAW 0x0080
SURF_HINT 0x0100 SURF_SKIP 0x0200
SURF_NOPORTAL означает «нельзя поставить портал», SURF_TRIGGER — служебный
флаг; ни то, ни другое не про рисование, а мы их пропускали. Замер на
gm_construct: старая маска скрывала 2511 граней, новая 2411 — в картинке
появилось 100 граней, не пропало ни одной.
Тесты surface_flags_match_source_bspflags и
skip_mask_covers_only_faces_that_are_not_drawn не дадут значениям снова разойтись.
«Прыжки марсианские»: скорость прыжка бралась как 270 из Source SDK, а у GMod
она своя — вики GMod в примере Player:GetJumpPower() печатает 200. Прыжок был
выше в 1,8 раза.
высота 60,8 -> 33,3 юнита
до вершины 0,45 -> 0,33 с
полёт 0,90 -> 0,67 с
sv_gravity = 600 подтверждён вики отдельно и остаётся.
Попутно исправлены две ошибки в самих измерениях: брался максимальный z над
точкой вместо высоты поверхности на месте (крыша на z=1296 заслоняла крышу на
z=240), и зазор между габаритами считался без клампа по нулю. На этих
артефактах диагностика рапортовала чужие дефекты.
Ноклип — по наблюдению в игре: инерции в полёте нет, скорость пишется прямо
по вводу и отпускание клавиш останавливает сразу. Разгон выглядел «лунной
гравитацией». Импульс при этом переживает отпускание: пока ввода нет, скорость
не трогается — раньше `velocity = wish * speed` писался каждый кадр и затирал
собственную скорость, поэтому прыжок по Z не мог сохраниться в принципе.
Пробел даёт порцию импульса по фронту нажатия, порции складываются: одно
нажатие поднимает на 279 юнитов, два — на 567. Выход из ноклипа переносит
импульс по всем осям в обе стороны.
«Марсианские прыжки»: дуга снята целиком и совпадает с расчётом для GMod —
0,45 с до вершины, 0,90 с полёта, 60,8 юнита высоты. Значит ощущение рождается
обрывом прыжка о невидимые стены.
Проверка касания переписана: грань должна доставать до кирпича, и проверяется
весь габарит тела в момент касания, а не одна точка. С проверкой точки игрок
переставал перебирать уступы уже высотой 4 юнита (замерено); с габаритом
подшаг работает — 18 перебирается, 19 нет.
Новый тест обходит gm_construct сеткой из 49 точек восемью направлениями:
117 600 кадров, невидимых стен 0 (было 2 на прямом ходе).
Заодно исправлена ошибка в самой диагностике: зазор между габаритами считался
без клампа по нулю, и на пересекающейся оси выходило отрицательное число,
из-за чего длина вектора давала «912 юнитов зазора» там, где габариты
соприкасаются. На этом артефакте рапортовалось 35 невидимых стен — все были
выдумкой измерения.
«Дырки в крыше, сквозь которые нельзя упасть» НЕ воспроизведены и не
«исправлены»: твёрдость кирпичей, покрытие displacement, отбор по содержимому
и обход карчи — всё чисто. Нужны координаты конкретной дырки; без них остаётся
только гадать.
Четыре жалобы из игры, все закрыты измерением.
Константы движения (gmodwiki.com/ConVars_In_Garrysmod, не source-sdk-2013):
sv_friction 4 -> 8 торможение 250 -> 10 за 0,40 с, путь 26 юнитов
sv_stopspeed 100 -> 10
sv_gravity 800 -> 600 прыжок 45,6 -> 60,8 юнита, как в GMod
sv_airaccelerate 12 -> 10
sv_maxvelocity 350 -> 3500 падение 585/589/590 -> 600/1200/1800/2400/3000
«В воздухе управление слабее»: в AirAccelerate кап sv_air_max_wishspeed
ограничивает ЦЕЛЬ, а прибавка считается по некапленной wishspeed. Мы
ограничивали и то и другое — прибавка была в 8,3 раза слабее. Замер после
правки: рывок вбок даёт ровно 30,0 юнитов/с, как в Source. Поворот при
полёте вперёд по-прежнему заблокирован (проекция 177 >> капа 30) — это
верное поведение оригинала.
«Высота шага терялась единица»: подъём ровно на sv_stepsime ставит низ
габарита точно на грань ступени, грань считается касанием, и подшаг
блокирует сам себя. Замерено: брались уступы до 17 и застревали на 18.
В оригинале подъём на flStepSize + DIST_EPSILON. После правки — все до 18
включительно, 19 нет.
«Невидимые стены, рампа как параллелипипед»: грань кирпича ограничивает
плоскость, а не кирпич, и останавливает шаг где угодно на её уровне.
Замерено: игрок останавливался за 3,4 юнита до настоящей преграды, блокировала
верхняя грань соседнего кирпича. Правка: при t около нуля проверяется, что
точка касания лежит на самом кирпиче. Замер после правки: преград «из
воздуха» 0 (было 2), упоров за 30 с ходьбы 0.
Проверено и отброшено измерением: кисти не работают как ящик (аудит 2126
кирпичей, 0 расхождений из 129684 точек); displacement не выпадает из сетки
(11776 треугольников, выпало 0); скорость вдоль склона 239-263 против 250.
Пара sv_falldistance/fall_speed НЕ введена осознанно: в таблице cvar'ов GMod
её нет, а формула HL2 при отрицательной velocity[2] даёт замедление падения,
а не разгон. Ставить непроверенные константы значило бы гадать.
228 тестов зелёные, clippy -D warnings чист.
Два оставшихся пункта из B6.7, сверенные с оригиналом SDK 2013
(src/game/shared/gamemovement.cpp).
- StartGravity / FinishGravity берут по половине гравитации до и после
движения: «yes, this 0.5 looks wrong, but it's not» — комментарий Valve.
Замер высоты прыжка на gm_construct: 42,7 -> 44,9 юнита при ~45 в Source.
Заодно проверено, что TryPlayerMove гравитацию не применяет вовсе.
- CheckVelocity: sv_maxvelocity = 350 попоосно. Без него шаг за кадр на
большой скорости становится длиннее стены, и отсечение её не видит.
- Место вызова важнее самого ограничения: в оригинале CheckVelocity стоит
прямо перед TryPlayerMove (внутри Friction). Вызов только в конце кадра
позволял одной нечислице уйти в смещение и сделать позицию нечислицей
навсегда — прогон тестов занимал 42 с вместо 0,01. Теперь вызов есть
и перед движением, и в конце.
- Позиция проверяется на нечислицу так же, как скорость.
Тесты: speed_is_capped_at_max_velocity, non_finite_velocity_is_zeroed.
Жалоба: «если игрок выходит за карту, то скайбокс и 3D-скайбокс не должны
рендериться (иначе не понятны границы карты)».
Причина видна в шейдере 3D-скайбокса:
world = camera.pos.xyz + (in.pos - sky_camera) * scale
Геометрия неба размещается относительно камеры, поэтому небо всегда заливает
весь фон — пределы карты на нём не видно.
Замер на gm_construct:
габариты геометрии (-5640, -4576, -960) .. (2168, 6464, 2976)
габариты коллизии (-15360, -15360, -1024) .. (15872, 15360, 15359)
sky_camera (-1428, 1645, 10991), масштаб 1/16
2D-скайбокса нет, только 3D
Габариты коллизии не годятся — включают и 3D-небо, и далёкие террасы,
поэтому основание — габариты геометрии карты.
- world::inside_bounds — одна реализация предиката, её используют и движок,
и рендерер (рендерер копирует габариты при загрузке).
- WorldRenderer::update_sky_visibility пересчитывает видимость каждый кадр:
игрок уходит за край во время игры. Проверка по всем трём осям сразу,
под картой небо тоже исчезает.
- SKY_BOUNDS_MARGIN = 128: габариты считаются по вершинам, а камера стоит
на высоте глаз над опорой, так что стоящий на краю игрок формально за ними.
- Гасятся оба прохода неба: иначе за краем остался бы виден 3D-неб, а это
ровно то, что мешало увидеть границу.
Тесты: sky_is_visible_only_inside_the_map (юнит) и real_map_sky_bounds
(замер на настоящей карте).
Замеры на gm_construct до и после — шесть жалоб из игры закрыты.
Исправлено по измерениям, а не по догадкам:
- vertices_of брал пересечение двух граней (прямую) и выбирал точку вне
кирпича: 1846 кирпичей из 2126 (87%) считались «без объёма», то есть
не твёрдыми. Это корень «сквозь рампу прошёл» и «падаю сквозь карту».
- clip_fraction отбрасывал грань при касании (guard `start <= limit`):
шаг 8 юнитов — стоп у стены, шаг 16 — на 8 внутрь. Guard убран,
условие `!(0.0..1.0).contains(&t)` — верно и для -0.0, и для NaN.
- Полуплоскость кирпича действовала на всю плоскость: игрок зависал
над краем площадки. Добавлен swept-bounds early-out.
- Движение шло одним общим процентом шага, из-за чего игрок «запинкой»
полз по полу. Заменено на цикл касаний TryPlayerMove (numbumps = 4).
- step_move всегда выбирал путь «вверх», а он уводил назад по склону:
игрок сползал с x = -256 до x = -1066 за 5 с. Переписано по оригиналу —
побеждает путь, ушедший дальше по горизонтали, z из движения вниз.
- stay_on_ground падал всем шагом, вминался в кирпич и выталкивался вдоль
нормали, то есть вбок по склону. Теперь зондирует вниз по 1 юниту.
- Трение было только без ввода. FullWalkMove зовёт Friction() безусловно —
именно оно удерживает игрока на рампе.
- Линейная интерполяция ускорения замедляет не хуже, чем ускоряет:
равновесие на 179 юнитах/с. Заменена квото-формула Accelerate;
sv_air_max_wishspeed = 30 действует только в воздухе.
Замер на настоящей карте (real_map_movement, --ignored):
скорость 165 -> 224,9 (среднее с разгона; Source 250)
дёрганье назад 0,00 юнита за 3 с
прыжок 42,7 юнита (Source ~45)
падение сквозь мир и проход сквозь рампу устранены
Старый real_map_player_rests_walks_and_does_not_sink требовал пройти
2000 юнитов вслепую вдоль +x, где на карте стена на x = 992 — ожидание
теста было неверно, а не игрок. Тест удалён, его корректная часть
покрыта real_map_movement.
222 теста зелёные, clippy -D warnings чист.
Главный дефект батча 2 был не в кинематике, а в проверке пересечения AABB с
кирпичом. Симптомы были «поверхность превратилась в лёд» и «выталкивает сквозь
пол и стены».
Глубина проникновения считалась как `dist - project_min(aabb, n)` — насколько
тело зашло за грань с внутренней стороны. Для игрока, стоящего на полу (низ на
1 юнит ниже верха кирпича высотой 100), это даёт 172 юнита проникновения в
нижнюю грань — на 172 юнита выше неё. Тело выталкивало вниз сквозь пол.
Отсюда сразу все жалобы: улетев вниз, игрок терял `on_ground`, трение не
применялось — это и был «лёд».
Заменено на SAT по разделяющим осям: длина перекрытия интервалов проекций.
Для того же игрока — 1 юнит, выход вверх. Чтобы у кирпича был второй конец
интервала, находятся его вершины и хранится проекция противоположного края.
Отдельно: минимальный вектор выхода не годится для тонкой стены — у стены
шириной 16 при теле шириной 32 выход вперёд всегда короче, и тело, дошедшее до
её середины, выталкивалось сквозь (замерено ровно до x = 132.1 при стене на
x = 100). Добавлена swept-трассировка: тело останавливается у грани и никогда
не оказывается по другую сторону.
По `CGameMovement` из Source SDK 2013:
- `StayOnGround()` — функции не было вообще. После ходьбы игрок
притягивается к поверхности; без этого он висит над землёй на спуске.
- порог опоры `sv_walkable_normal` = 0.7, а не 0.6;
- `StepMove` работает только когда игрок был на земле, в прыжке на ступеньку
не взбираются;
- в пути отсечения выставляется опора — без этого игрок замирал намертво на
45° рампе: гашение скорости контактом уравновешивало гравитацию.
Замер на gm_construct (30 секунд ходьбы): пройдено 6372 юнита вместо 1072,
проваливания и замирания нет. 81 тест зелёный, clippy чистый.
Доки Valve закрыты Anubis, читал первоисточник
ValveSoftware/source-sdk-2013, src/game/shared/gamemovement.cpp.
Записаны точные причины двух симптомов пользователя и ещё трёх расхождений:
1. StepMove у оригинала пробует оба варианта (вниз и вверх на flStepSize) и
берёт тот, что ушёл дальше по горизонтали; вертикальную скорость берёт из
движения ВНИЗ (m_vecVelocity.z = vecDownVel.z). У нас подшаг всегда идёт
путём «поднять 18 и уронить», режет путь на рампе и добавляет паразитную
вертикаль — отсюда и потеря скорости вверх, и «прыжки с рампы» вниз.
2. Friction() вызывается каждый кадр на земле безусловно, формула
control = max(speed, sv_stopspeed), drop = control*friction*frametime.
У нас трение только при отсутствии ввода — по рампе на бегу его нет.
3. Гравитация делится 0.5 до и 0.5 после движения (StartGravity/FinishGravity).
4. Ускорение — Quake-формула accelspeed = accel*frametime*wishspeed, а в
воздухе ещё и ограничение sv_air_max_wishspeed = 30. Отсюда «вязкое»
управление в воздухе, которого у нас нет.
5. Прыжок по фронту: в оригинале при выходе из воды ставится
m_nOldButtons |= IN_JUMP с комментарием «don't jump again until released» —
наша защёлка воспроизводит штатный приём движка.
Код не менял: сначала фиксирую расхождения, чтобы не подгонять тесты.
Четыре жалобы (проталкивает на расстояние, метания вдоль стены, сползание по
рампам, bhop) оказались одной ошибкой: гравитация применялась КАЖДЫЙ кадр,
в том числе стоя на земле. Игрок вдавливался в геометрию, разрешение
столкновений выталкивало обратно.
Source делает наоборот: при FL_ONGROUND вертикальная скорость
обнуляется, а ApplyGravity в земле не вызывается вовсе.
Что изменено:
- гравитация только в воздухе;
- трение всегда на земле (Source зовёт Friction() каждый кадр) — именно
оно держит игрока на рампе; sv_friction = 4, sv_stopspeed = 100;
- прыжок по фронту нажатия, защёлка держится пока пробел зажат;
- подшаг PM_StepSlideMove: полное движение, при блокировке повтор с
подъёмом на 18 юнитов и спуском; при падении отключён, иначе игрёт в
потолок;
- MoveResult::blocked — признак блокировки для подшага.
Три мои ошибки пойманы тестами:
1. jump_latched = jump — защёлка вставала ДО первого прыжка, прыгать было
нельзя вообще;
2. jump_latched = jump && on_ground — флаг сбрасывался тем же кадром, когда
прыжок уже отработал, bhop возвращался;
3. тест на рамку мерил первоначальное падение (40 -> 6), а не сползание, и
падал с «сносом 34»; после отделения приземления снос ноль.
Также: пропы добавлены в коллизию игрока (Collision::boxes) и в is_on_ground
- иначе игрок стоял на ящике и считал себя в воздухе.
Тестов 73 в engine (было 70), 23 набора по воркспейсу, clippy чист.
Две версии про проваливание проверены тестами и обе оказались неверными.
1. «Пропов нет в коллизии игрока» — пробел реальный и устранён, но игрок
ходил по брашам, это его не объясняло.
2. «На низком FPS шаг подшага прошивает пол» — опровергнуто: при
terminal-скорости 2000 юнитов/с и dt = 1/60 игрок садится на площадку
толщиной 4 юнита, on_ground = true.
Тест оставлен как регрессионный сторож: если подшаги когда-нибудь
ослабнут, он сразу это покажет.
Замер: стояние на спавне gm_construct стабильно 180 кадров (z = -143.9,
on_ground = true). Дефект локальный и требует указания места.
Причина не найдена — фиксирую это в docs/PARITY.md B3, а не подгоняю
тест под желаемый результат.
Батч 3, шаг 4. Соединения между телами по классам GMod: phys_ballsocket,
phys_hinge, phys_slider, phys_weld, rope. Плюс add_force (база для
thruster/hover) и set_angular_velocity_target (мотор шарнира).
Главная тонкость переноса: скрипт задаёт якорь в мировых координатах, а
Rapier ждёт локальные в каждом теле. Пересчёт через обратное вращение.
Ошибка не бросает исключение — соединение просто «приклеивается» к другой
точке и уезжает при первом движении.
Четыре вывода из измерений, а не из рассуждений:
1. Констрейн не «стягивает» тела, и это правильно: якорь в мировой точке
совпадает у обоих тел в момент создания, ограничение выполнено сразу и
включается, только когда тела расходятся. Пять первых тестов проверяли
расстояние между телами и падали именно поэтому. Правильный инвариант —
совпадение ТОЧЕК КРЕПЛЕНИЯ под действием силы.
2. Сила в Rapier действует один шаг и сбрасывается: add_force надо вызывать
каждый кадр. Тест с однократной силой измерял не силу, а её отсутствие,
и падал одинаково при 8000 и при 40000.
3. Спящее тело честно сообщает нулевую скорость, поэтому эффект силы
проверяется сравнением с контрольным прогоном, а не по скорости.
4. ПОЛЗУН НЕ УДЕРЖИВАЕТ. Сустав сообщает enabled = true и 5 заблокированных
осей из 6, шар/шарнир/сварка в том же прогоне держат, но ползун пропускает
расхождение по высоте. Тест помечен #[ignore] с причиной: зелёная галочка
на неработающем коде хуже явного отказа. Гипотеза к проверке записана в
docs/PARITY.md B2.6.
Тестов 67 в engine (было 56), 23 набора по воркспейсу, clippy чист.
Батч 3, шаг 3. Сначала измерено, а не придумано: прогнаны 130 файлов
gamemodes/sandbox, извлечены 182 различных вызова API с частотами.
Топ по частоте: hook.Run (63), math.Clamp (61), game.SinglePlayer (36),
math.Rand (27), render.AddBeam (21). Первые четыре — чисто Lua-слой,
сделаны здесь; render.* — отдельная большая работа.
hook.Run не синоним hook.Call: он останавливается на первом не-nil. На этом
построены все проверки Sandbox, подмена Run на Call ломала бы их молча.
Найдено три дефекта, все — измерением:
1. Ключи хуков — строки (идентификаторы скриптов), а не числа. Отбор только
целочисленных ключей давал пустой список: хуки не выполнялись вообще,
hook.Run возвращал nil.
2. Vec<Value> реализует IntoLua как таблицу, поэтому Function::call передавал
хуку ОДИН аргумент вместо трёх — молча, без ошибки. Проверено:
select('#', ...) внутри хука давал 1 при трёх переданных. То же с одиночным
числом. Лечится Variadic; отдельный тест фиксирует именно эту ошибку.
3. math.Rand определён на Lua, а не на Rust: он зовёт math.random того же
состояния и передаёт аргументы нативно.
file.* — с песочницей на garrysmod/: выход за корень это отказ, а не
предупреждение, абсолютные пути не даны, чтение ограничено 8 МБ. На живом
клиенте file.Read('../../../../etc/passwd') вернул nil.
Совпадения с GMod зафиксированы тестами: math.Round(-2.5) = -3,
math.Rand(x) даёт целое в [1, x], AngleDifference(10, 370) = 0,
Remap на вырожденном диапазоне даёт out_min, а не NaN.
Тестов 38 в glua (было 24), 23 набора по воркспейсу, clippy чист.
Батч 3, шаг 2. Крейт glua не зависит от engine: поведение отдаётся через
трейт Host, реализация которого живёт в клиенте. Иначе был бы цикл
зависимостей и Lua-слой нельзя было бы тестировать в одиночку.
Мир переведён в Rc<RefCell<World>> — скрипт обращается к нему из хуков в
любой момент. Все обращения через try_borrow: пересечение заимствований
даёт panic, а падать из-за скрипта клиент не должен.
Проверено измерением на gm_construct: ents.GetAll() возвращает 1227
сущностей, ents.GetByClass('prop_physics') читает позицию.
Найден и исправлен рассинхрон: move_prop обновлял позу экземпляра пропа,
но не запись в пуле сущностей. Lua читал z = -64, пока физика уже опустила
проп на z = -84 — «данные» и «картинка» разошлись, и заметить это можно
было только глазами. Теперь поза пишется в оба места всегда, даже без
модели: проп без модели всё равно стоит правильно, он просто не рисуется.
Возвращаемое значение move_prop теперь означает именно «геометрия
пересчитана».
После правки Lua читает z = -84.15848, физика даёт -84.15847778320313 —
совпадение до последнего бита.
Тест на паникующий хост: скрипт получает «невалидно» вместо падения.
Тестов 24 в glua, 56 в engine, 23 набора по воркспейсу, clippy чист.
Батч 3, шаг 1. Фундамент Lua-API: без этих типов Entity:GetPos() не
возвращает ничего, с чем можно считать.
Проверено тестами через настоящий LuaRuntime, а не голый интерпретатор:
скрипт считает теми же глобалами, что и обычный автор в Sandbox.
Решения по совместимости:
- пропущенные аргументы не бывают ошибкой: Vector() и Vector(1, 2) должны
работать, иначе ломается бытовой код Sandbox;
- деление на ноль даёт 1, а не inf — inf в позиции пропа отравляет всю
геометрию объекта;
- NaN из скрипта не доезжает до физики;
- компоненты цвета обрезаются в 0..255, а не отвергаются;
- Source — левая система координат: нулевые углы смотрят вдоль +X,
yaw=90 — вдоль +Y.
Найден дефект чтения чисел в mlua 0.11: Value::as_number() различает только
Number и молча возвращает None на Integer, а LuaJIT отдаёт целые как
Integer. Vector(1, 2, 3) давал Vector(0, 0, 0) — и это выглядело как
«арифметика не работает». Собственный value_number() принимает Number,
Integer и строку-число.
Ещё убрат шум тригонометрии: cos(90°) в f32 равен 6.1e-17, и
Angle(0,90,0):Forward() печатал -0.00000004371139 вместо 0.
Тестов 17 в glua (было 1), 23 набора по воркспейсу, clippy чист.
Батч 2. Мир не переезжает в Rapier целиком: геометрия карты остаётся
брашевой, Rapier обслуживает только динамические тела.
Четыре дефекта найдены измерением на gm_construct, а не догадкой — каждый
следующий был невидим, пока не закрыт предыдущий:
1. Рельеф раздувался в 15 277 коллайдеров (сетка LAND_CELL дублировала
каждый треугольник в каждую ячейку). Заменено одним объединённым
trimesh с дедупликацией вершин: 11 776 треугольников -> 6 148 вершин,
1 коллайдер. Точнее и на порядки дешевле.
2. Уровень gm_construct построен брашами, а не displacement'ами: без них
все пропы падали насквозь. add_brushes восстанавливает вершины
перебором троек плоскостей (Крамер). Замер: 2121 построен, 5 пропущено.
3. Broad-phase Rapier наполняется только на step(): после вставки статики
луч её не видел. Лечится явным broad_phase.set_aabb().
4. setup_physics начинался с PhysicsWorld::new() и стирал построенные браши.
Тест поймал баг, который замер бы не увидел: add_brushes создавал
коллайдеры, но не увеличивал счётчик, и лог врал (static = 1 при 2121 браше).
Проверка двумя независимыми системами коллизий: и Rapier, и брашевая
Collision находят пол под пропами на z = -96. После 400 кадров все 4
prop_physics осели: speed = 0.0, sleeping = true.
Ограничения зафиксированы в docs/PARITY.md: коллайдер пропа — AABB модели,
а не vcollide; физика только у prop_physics*; FPS просел до 10-21 и требует
отдельного замера.
Тестов 55 в engine (было 42), 23 набора по воркспейсу, clippy чист.
collect_lights() разбирает light_environment (солнце), light, light_spot.
На gm_construct: 65 источников, 1 солнце, 22 прожектора. Шейдер получил
uniform-блок с солнцем, точечными источниками и конусами прожекторов.
Ключевые находки при подборе нормировки (проверено рендерами):
- четвертая компонента _light — это РАДИУС у ламп и ЯРКОСТЬ у солнца;
- яркость нельзя домножать в цвет, иначе возводится в квадрат;
- лайтмапа уже содержит запеченное солнце, динамическое добавляется слабо.
Также добавлен разбор GAME_LUMP в formats (нужен для деталь-текстур) и
заодно выяснено: в gm_construct деталь-текстур нет, под-лумпы prps/prpd —
это геометрия пропов. Текстура GRASS-SAND_13 есть, но не используется ни
одним texinfo — вопрос песка остается открытым (docs/PARITY.md A5).
Зафиксирован план достижения одиночной игры, совместимой с GMod.
Главный принцип — совместимость, а не тождество внутренностей: контент
карт и аддонов, Lua-API, поведение игрока, формат сущностей.
Часть A — семь найденных дефектов, в том числе подтверждённых замером
по реальному gm_construct.bsp: 77 из 2203 брашей ошибочно считаются
твёрдыми, скорость не гасится о контакт, нет отсечения граней,
нет деталь-текстур.
Наш первый netchan-пакет был на 22 байта короче эталонного — ровно на
cl_playermodel\0male07\0. Без него сервер не знает, какую модель ставить
нашему энтити-игроку.
Набор конваров вынесен в client::userinfo_pairs() и теперь сверяется с
эталоном настоящего GMod (новая фикстура fixtures/classicbox_client_hello.bin,
511 байт из пакета #24) попарно, включая порядок. При том же имени наш пакет
теперь совпадает с эталонным побайтово: тело идентично в 513 из 514 байт,
различаются только checksum/challenge из-за другой сессии и один остаточный
бит добивки.
Раскладка взята из Source.NET (NetMessages.cs), т.к. эталонного pcap с этими
сообщениями нет — в захвате потеряно 2576 серверных пакетов именно на участке,
где сервер шлет таблицы (docs/RECON.md 13.13).
Важно: у SVC_SendTable нет имени таблицы, в отличие от раскладки Source 2013
SDK, на которую я ориентировался раньше.
Попутно найден баг через круговые тесты: префикс ':' у строковой таблицы
нужно смотреть (PeekUBitLong), а не читать — иначе теряется первый символ
имени ('userinfo' читался как 'serinfo') и дальше по потоку едет смещение.
Число классов ограничено MAX_SERVER_CLASSES=4096: значение приходит из сети.
Source.NET в ReadSubChannelData при фрагменте вне диапазона или нулевой
длине делает data.Return() и выходит — это штатная ситуация для
опоздавшего/дублирующего фрагмента. Наш код возвращал NetError, из-за чего
терялись все остальные сообщения пакета, а с ними и signon-блок.
Взят прямо из Source.NET (IConnectionlessPacketHandler.cs, enum PacketFlag):
Reliable=1, Compressed=2, Encrypted=4, Split=8, Choked=16, Challenge=32.
Из-за неверного бита в пакетах сервера с выставленным битом 3 читался
лишний байт, reliable_state и challenge уезжали на 8 бит.
Добавлены тесты на константы флагов и на заголовок с Choked.
Раскладка ServerInfo была неверной (max_classes как long вместо 16 бит,
4 байта вместо MD5 карты, ServerOS как строка, нет loading_url/gamemode).
Исправлено по спецификации Source.NET и подтверждено тестами на реальном
блоке ClassicBox: map=gm_bigcity_improved_rp, host=ClassicBox,
gamemode=sandbox, maxcl=48, tick=0.030303, proto=24.
Layout одиночного блока, подтверждённый перебором по pcap настоящего GMod:
4 (подканал) + 2 (потоки) + 1 (single-block) + VarInt32 = 23 бита.
Мы писали 24 бита (лишний бит «сжатие»), из-за чего сервер читал длину
с неверного смещения и отбраковывал фрагмент — reliable-поток не читался,
m_bSendServerInfo не выставлялся.
Также набор USERINFO-конваров приведён к реальному (28 шт. с net_maxroutable).
Захват настоящего GMod (ClassicBox, 8091 пакетов) показал: реальный клиент
шлёт в первом netchan-пакете rel=0x0000, а мы ставили 1. Это поле означает
«какие подканалы мы хотим получить», в начале оно нулевое.
Проверка по InReliableState показала: исходные 4 бита и LSB-first верны
(and $0xF / позиция +4 в ProcessPacket; rol в bf_write::WriteByte).
Правки 12f94ae и 50bb363 были регрессией и откачены.
Настоящая причина отсутствия server info: bf_write писал биты LSB-первым,
а Source читает/пишет MSB-первым (подтверждено дизассемблированием
bf_read::ReadUBitLongNoInline в engine_srv.so).
Из-за этого WriteOneBit(true) попадал в поле соседнего потока фрагментов,
а ID сообщений записывались перевёрнутыми — сервер не распознавал
net_SignonState и не выставлял m_bSendServerInfo.
- write_one_bit/write_ubit_long/read_one_bit/read_ubit_long: MSB-first;
- write_u32/write_short/read_long/read_short: побайтово little-endian
(как ReadLong в движке);
- reliable_state кодируется через WriteUBitLong(16);
- тесты bit_order_matches_source и reliable_block_layout_is_canonical.
Главная причина отсутствия server info: SUBCHANNEL_BITS был 4, из-за чего
сервер читал subchannel=1 и 0 фрагментов, молча отбрасывая reliable-поток
(net_SignonState не обрабатывался → m_bSendServerInfo не выставлялся).
Подтверждено pcap-разбором и дизасмом engine_srv.so (CNetChan::ProcessPacket:
lea 0x3(%esi) — ровно 3 бита; and $0x1 — reliable-флаг 0x01).
Проверка поля клиента (0x5af) в GMod-сервере: для удалённого клиента
сигнон-блок не отправляется, пока флаг (вероятно m_bFullyAuthenticated,
ставится при успешной асинхронной валидации тикета) не выставлен.
Симптомы совпадают: connect принимается, netchan работает, сообщения
доходят, но ServerInfo не приходит. Дальнейшие шаги — в docs/RECON.md §13.2.
- Регулируемые экспериментальные ручки: SOURCE_RS_SUBCHANNEL_BITS,
SOURCE_RS_REL_STATE, SOURCE_RS_HELLO_EVERY_MS, SOURCE_RS_PROBE_SIGNON,
SOURCE_RS_RETRY_DELAY_MS, SOURCE_RS_NO_TICKET_REFRESH.
- docs/RECON.md §13.1: разбор логики сигнона по утёкшему исходнику
(SendPendingServerInfo/SetSignOnState/ConnectClient), формат challenge-ответа,
наблюдения по лимитам Steam (DuplicateRequest ~2-3 мин), что уже проверено.
- Сигнон-блок от сервера пока не приходит (наши пакеты доходят, connect
принимается) — следующая задача; все зацепки в доке.
- Современный Steamworks требует GetAuthSessionTicket с
SteamNetworkingIdentity = SteamID игрового сервера; generic-тикет сервер
отвергает синхронно (#GameUI_ServerRejectSteam). Тикет привязывается к
серверу из ответа challenge ('A': keysize u16, GSID u64, secure u8).
- Кэш тикета по SteamID сервера (как CSteam3Client::GetAuthSessionTicket),
ретраи connect с задержкой (10 с): повторный BeginAuthSession для того же
SteamID сервер считает дубликатом и отклоняет.
- Тикет запрашивается в момент connect (GSID уже известен), стартовый тикет
больше не нужен.
- docs/RECON.md §13: полный формат challenge/connect/reject, порядок состояний
сигнона, наблюдения по лимитам Steam.
- Вода: детект Water-шейдера (/), отдельный полупрозрачный
проход с френелем; поверхность/изнанка по нормали. Белая дыра на месте воды
(2D-скайбокс «вниз») устранена.
- 3D-скайбокс: выбор граней по area листа sky_camera (движок: area bits), а не по
AABB. Disp-грани не попадают в leaf_faces — выбор по листу центра грани; теперь
в скайбоксе есть большая плоскость flatgrass_2 (пропадала — торчала «стена»
бетонного пола). Защита >30% граней = скайбокс не выделяем (gm_flatgrass).
- Порядок: 2D-скайбокс фоном -> 3D-меш (depth Always, без записи) -> мир ->
вода. Скайбокс больше не проступает сквозь дальние стены карты.
- Лайтмапы: блок грани (size+1)^2 с индексом v*width+u; для displacement'ов —
плотная сетка по UV поверхности (CalcDispSurfCoords), а не проекция мира:
убрана «шахматка» теней на рельефе. Скайбокс-меш тоже сэмплит лайтмапы.
- Тесты: gm_flatgrass-диспы живут в скайбоксе (z≈-16000), пороги обновлены.
- docs/RECON.md §12: форматы листьев/граней, лайтмапы, скайбокс, вода.
