Performance strategy for func_wall with +0/+A textures

[0x4E69676874466F78]

У нас существует проблема что все func_wall с +0/+A текстурами надо добавлять каждый кадр что даёт какие-то штрафы по производительности.
Мы могли бы проанализировать список энитити на наличие связи func_wall с любыми другими энтитями, для этого надо проверять что вот конкретная func_wall имеет ключ targetname и значение этого ключа (имя) используется какой-то другой энтитей, обычно целевое имя у ссылашющихся энтитей лежит в ключе target, но для страховки можно перебрать все ключи (хотя это может давать ложные срабатывания).

1. Если targetname нигде упомянут то эта статическая модель.
2. Если targetname у func_wall вообще не указан или пустой, то искать ничего не нужно и это статическая модель гарантировано (безопасно можем сразу добавить такое поведение).

Теоретически 1 вариант может сломать какие-то моды которые прямо из кода в обход энтитей перелючают func_wall, поэтому стоит оставить квар исключающий этот первый вариант. 2 вариант сломать ничего не должен (99,999%), но при желании тоже можно добавить квар (или сделать режим в рамках одного квара, типа значения 1, 2).

[w23]

For this to work a lot more is needed:

1. Distinguish between Animated|WithChangingEmissive and Switchable|WithChangingEmissive.
2. Detect whether func_wall can be switched (based on targetname logic above).
3. Only make the switchable static, not animated.

[0x4E69676874466F78]

Вроде бы что-то на эту тему уже было сделано базовое, но не помню что.

[w23]

Вроде бы что-то на эту тему уже было сделано базовое, но не помню что.

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