Culling problem on c1a1a, c1a2b, etc

[0x4E69676874466F78]

The brightness of red light drops dramatically when moving from turn.

[w23]

Kek. This is due to that решёточка disappearing. Why does it disappear? Because it is transparent and thus is a separate entity. So the moment the player is about to go around the corner, visibility of that leaf changes and entity stops being added to rendering.

So the fix is likely beyond ref_vk. I'm not sure if we even can have access to the entities that are technically considered invisible by the engine.

We also probably need to start adding more of such cases here to understand the scale of this issue.

[0x4E69676874466F78]

@w23 ага, точно, так и есть, как до меня только не дошло 😞 А мы можем пометить в конфиге определённые браши чтобы они подгружались и не выбрасывались если мы находимся в определённом радиусе от них?

[w23]

Их вообще не надо выбрасывать. Другое дело, что нужно о них знать, знать их позиции, и пр.

[0x4E69676874466F78]

@w23 а доступ к геометрии вообще есть или можно получить? Допустим я нахожу model id через bspguy вот пример: Правда этот браш ещё можно по entity id получить так как это func_wall.

[0x4E69676874466F78]

Сам уровень оказывается имеет model id 0, так что в случае с обычными брашами только по plane id/face id:

[w23]

Повторюсь. Этот кусок стены это отдельная энтити, которую движок даёт или не даёт мне в рендер в зависимости от того, считает он что она видима, или нет. Это абсолютно внешний по отношению к рендеру код. Мне дали отрисовать -- я отрисовал. Не дали -- не отрисовал.

Что можно попробовать сделать:

1. Поперебирать энтити через gEngine апи. Может, они там есть, но не все прилетают на отрисовку, и я бы мог их выгребать сам? Но могу ли я узнать, как бы они отрисовывались, если бы отрисовывались (рендермод, цвета, матрицы, етц)?
2. Научить движок спец режиму с другим отсечением. Не отсекать вообще ничего, наверное, может оказаться дорого. Однако режим "дай мне всё, что видно из листов, видимых мне" должен быть уже значительно лучше, и вроде как не фундаментально сложнее для движка.

[0x4E69676874466F78]

@w23 надо у разрабов спросить. Как лучше завести мне задачку в FWGS/xash3d-fwgs или сам? или на стриме отлавливать их? В целом я думаю это не сильно приоритетная задача, есть сейчас поважнее.

[w23]

Можно тегнуть их в дискорде для начала

[0x4E69676874466F78]

Можно попробовать покрутить engine\common\mod_local.h:

#define REFPVS_RADIUS        2.0f    // radius for rendering
#define FATPVS_RADIUS        8.0f    // FatPVS use radius smaller than the FatPHS
#define FATPHS_RADIUS        16.0f

Замечено использование REFPVS_RADIUS в ref_gl\gl_rsurf.c и ref_soft\r_main.c <- у нас REFPVS_RADIUS нет. FATPVS_RADIUS и FATPHS_RADIUS в engine\server\sv_game.c

[0x4E69676874466F78]

Заметно на c1a2b.

https://user-images.githubusercontent.com/4449851/148854232-b4fb5f92-1273-407b-9047-bd85e8037b73.mp4

Решил покрутить выше константы, внезапно на этой карте помогло! На c1a1a не настолько но тоже при сильном увеличении значений можно получить неплохой результат, как и на test_brush2 (комната со сферой).

#define REFPVS_RADIUS       32.0f   // radius for rendering
#define FATPVS_RADIUS       128.0f  // FatPVS use radius smaller than the FatPHS
#define FATPHS_RADIUS       256.0f

Пока мне лень выяснять что на что влияет но последние два параметра в нашем случае решают.

[0x4E69676874466F78]

@a1batross, какое тут будет правильное решение? Мы можем как-то для лучевого рендера переопределять эти определения?

[a1batross]

Для начала, разберитесь что эти константы означают.

[0x4E69676874466F78]

@a1batross Ну они определённо влияют на результат, понятно что это связано с тем как работает PVS FATPHS_RADIUS (например в pfnSetFatPAS) и FATPVS_RADIUS (например в pfnSetFatPVS) улетают как радиус в Mod_FatPVS и Mod_FatPVS_RecursiveBSPNode где:

Calculates a PVS that is the inclusive or of all leafs within radius pixels of the given point.

Короче это всё довольно legacy-специфично и прокатывает на legacy GL. В нашем случае надо сказать движку поменьше отрезать геометрию.

[a1batross]

Не совсем.

REFPVS в вашем случае нужно игнорировать.

FATPVS/FATPHS нельзя трогать. Все же это меняет серверную логику. Мы не ломаем серверный код ради мода на одну игру.

Тем не менее движок поддерживает увеличение видимости для зеркал, этот механизм и надо задействовать.

[a1batross]

Как костыльное решение предлагаю пока выставлять sv_nopvs в 1.

Это включает полную видимость. Как уместитесь в пакет на более тяжелых сценах я не знаю.

[0x4E69676874466F78]

@a1batross

REFPVS в вашем случае нужно игнорировать.

Да я понял, поэтому написал что последние два решают.

FATPVS/FATPHS нельзя трогать. Все же это меняет серверную логику. Мы не ломаем серверный код ради мода на одну игру.

Никак выделить это для клиента и сервера по отдельности? Нам же видеть только геометрию, а не игроков.

Как костыльное решение предлагаю пока выставлять sv_nopvs в 1.

Такой команды нет. Зато нашёл sv_novis которая при 1 включает полную видимость. Но тогда мы получаем просадку производительности :(

[a1batross]

Да, sv_novis.

Но тогда мы получаем просадку производительности :(

А вы думали. Для лучей это единственное полноценное решение. "legacy GL" говорили они. :)

[0x4E69676874466F78]

Если новые кластеры будут хороши возможно мы сможем просто включить sv_novis 1?