Ага, поглядел через r_speeds 7, ни одного зеркала нету, надо понять почему оно невалидно сбросы считает иногда.
Добавлено 11-02-2021 в 23:09:
Разобрался почему невалидная инфа отображалась: у меня помимо R_DrawWorldList счетчики еще и инкрементировались в R_DrawBrushList (которая вызывается для каждой брашевой энтити). Теперь картина более ясная стала.
Короче разобрался почему столько переключений шейдеров было - снова не было проверки на fog там, где она по идее должна была быть. Теперь надо попытаться что-то с сортировкой сделать, чтобы переключения текстур были выше по приоритету чем переключения шейдеров.
Добавлено 21-02-2021 в 19:52:
Цитата:
Дядя Миша писал: Хы. Mod_ResortFaces должен вызываться каждый кадр. Там недоделато.
А можно про это подробнее? Как это в целом должно работать?
Добавлено 21-02-2021 в 19:59:
Цитата:
SNMetamorph писал: Теперь надо попытаться что-то с сортировкой сделать, чтобы переключения текстур были выше по приоритету чем переключения шейдеров.
Сейчас попробовал - переключений текстур убавилось буквально на 20-30, зато добавилось 50 переключений шейдеров. Вернул всё обратно.
В общем, по рендерингу мира картина уже более-менее ясна. В основном сброс буфера происходит из-за смены текстур, коих на более-менее крупных картах немало, и от этого никуда не деться. Они же в текущей ситуации и дают основную просадку FPS. В принципе, тут есть два решения:
1. Группировать все текстуры сурфейсов мира в атлас (придется много всего переделывать)
2. Использовать bindless textures (поддержка есть только в видеокартах >2013 года)
Добавлено 22-02-2021 в 00:19:
Теперь надо изучить рендеринг брашевых энтити, там вроде есть что-то довольно тормозючее.
Дядя Миша писал: Переключение текстур на фпс почти не влияет. Смена шейдера - самая дорогая операция.
Ну переключений шейдеров совсем немного, а текстуры по 200-300 раз за кадр на больших картах меняются, в итоге импакт по производительности очень большой.
Вообще, как я уже говорил - далеко не факт, что проблема именно в отрисовке. Ты для начала посмотри сколько нодов и лифов в дереве на этой карте. Отпрофилируй ENGINE_CHECK_VISIBILITY там могут быть совершенно сумашедшие значения.
Для быстрой прикидки можно выключить всю отрисовку энтить и сравнить фпс. Mod_HeadnodeVisible очень тормозной если дерево слишком большое.
Т.е. в первую очередь - исключи влияние механизмов проверки видимости, которые в какой-то момент начинают наоборот затормаживать всю работу.
Дядя Миша писал: Вообще, как я уже говорил - далеко не факт, что проблема именно в отрисовке. Ты для начала посмотри сколько нодов и лифов в дереве на этой карте. Отпрофилируй ENGINE_CHECK_VISIBILITY там могут быть совершенно сумашедшие значения.
Для быстрой прикидки можно выключить всю отрисовку энтить и сравнить фпс. Mod_HeadnodeVisible очень тормозной если дерево слишком большое.
А это все дело используется в отрисовке через отсортированный список сурфейсов который в Mod_ResortFaces собирается? Там же оно один раз генерится при загрузке уровня, а потом список никак не меняется. Я правда не пойму как потом некоторые сурфейсы куллятся в функции R_DrawWorldList
Список тут непричём. Это список отсортированных индексов. Из него видимые сурфейсы попадают в другой список, и вот он уже рисуется.
Проведи простой тест - r_norefresh 1
Если фпс не сильно подымется, дело вообще не в отрисовке.
Дядя Миша писал: Проведи простой тест - r_norefresh 1
Если фпс не сильно подымется, дело вообще не в отрисовке.
С 50 кадров поднялся до 170, немало.
Добавлено 22-02-2021 в 15:45:
Цитата:
Дядя Миша писал: Mod_HeadnodeVisible очень тормозной если дерево слишком большое.
Ну это же опять таки от процессора зависит?
Добавлено 22-02-2021 в 17:22:
Как
Цитата:
SNMetamorph писал: А это все дело используется в отрисовке через отсортированный список сурфейсов который в Mod_ResortFaces собирается? Там же оно один раз генерится при загрузке уровня, а потом список никак не меняется. Я правда не пойму как потом некоторые сурфейсы куллятся в функции R_DrawWorldList
Как щас выяснил, весь куллинг сурфейсов выполняется в двух строках в цикле:
C++ Source Code:
1
void R_DrawWorldList( void )
2
{
3
...
4
for( int i = 0; i < world->numsortedfaces; i++ )
5
{
6
int surf_index = world->sortedfaces[i];
7
if( !CHECKVISBIT( RI->visfaces, surf_index ))
8
continue;
9
}
10
...
11
}
12
Осталось разобраться как заполняется собственно сам RI->visfaces
Добавлено 22-02-2021 в 17:35:
Как я понимаю, R_RecursiveWorldNode пробегает по BSP-дереву, помечает видимые лифы и добавляет сурфейсы в некий список (который в R_DrawWorldList не используется) и как раз таки заполняет RI->visfaces
А в свою очередь R_WorldMarkVisibleFaces делает то же самое, только бегает не по дереву, а тупо последовательно по списку лифов на карте?
Добавлено 22-02-2021 в 17:58:
Сейчас потыкали всем народом квар gl_recursive_world_node, который как раз переключает функции R_RecursiveWorldNode и R_WorldMarkVisibleFaces, в итоге вообще ни у кого нет никакой разницы по производительности. Единственное что я заметил, у меня R_WorldMarkVisibleFaces выполняется малость быстрее.
SNMetamorph писал: Ну это же опять таки от процессора зависит?
Если рекурсия слишком глубокая, это на любом проце удар по производительности. Ну как цикл while( 1 ); загрузит проц на 100% независимо от его мощности.
Цитата:
SNMetamorph писал: Сейчас потыкали всем народом квар gl_recursive_world_node
вас там еще и много
Цитата:
SNMetamorph писал: в итоге вообще ни у кого нет никакой разницы по производительности
Дядя Миша писал: Если рекурсия слишком глубокая, это на любом проце удар по производительности. Ну как цикл while( 1 ); загрузит проц на 100% независимо от его мощности.
То есть предпочтительнее таки отказаться от R_RecursiveWorldNode в пользу R_WorldMarkVisibleFaces?
Цитата:
Дядя Миша писал: вас там еще и много
Из русских мб человек 10 наберется, из тех кого я знаю. А еще есть пару иностранцев.
SNMetamorph писал: То есть предпочтительнее таки отказаться от R_RecursiveWorldNode в пользу R_WorldMarkVisibleFaces?
сложный вопрос на самом деле. Лучше всего не допускать раздутого дерева, но на халфовском формате это нереально. Я писал симплификатор дерева для NT, он очень хорошо справлялся, но для меня это давно уже неактуально.
| IP: 
07-02-2021 21:08
