Дядя Миша писал: Да это для ботоф какая-то подсказка.
Не совсем. Это для навмеша. Там очень много арей создаётся, и граф доступности ареи из ареи разрастается сильно. Поэтому ареи собираются в кластеры, а кластер-порталы их делят (обычно в коридорах и прочих узких местах). Между кластерами свой отдельный граф досягаемости, который получается сильно меньше.
Может быть, я однажды допишу свой цикл статей по устройству AAS.
Похоже дуумтришные оптимизации треугольников придётся выбросить.
Ну или полностью переписать, они абсолютно не годятся для моих задач.
И вот почему - оптимизация происходит в 2д пространстве, т.е. на общей плоскости. Ну нетрудно догадаться, что такое справедливо только для брашей. А для вставленных моделей он просто формирует десятки тысяч цепочек с одним треугольником внутри. Причём уже просто на копирование этих цепочек уходит адски много времени без цели и смысла. В самом D3 это понимали, поэтому перестали включать статические модели в общую геометрию на этапе компиляции - их рендерер грузил, что тоже небыстро.
Но для параметрических поверхностей специализированная оптимизация справляется куда лучше общей. Для брашей это соответственно CSG, Merge и ClipSidesIntoTree. Для патчей RemoveLinearColumnsRows и StitchPatches.
Для моделей - простая индексация вертексов. Ну и собсно всё, переставлять эджы там нет никакого смысла, тем более я заметил, что после этой оптимизации FPS наоборот даже немного падает. Точно так же нет и смысла резать треугольники строго по дереву для full carve - это уже CSG делает. Так что от оптимизатора требуется единственная вещь - рассортировать треугольники по нужным ариям, разрезая его, когда он попадает точно на границу двух арий.
Вот так забавно получается, что код из D3 использоваться не будет - только некоторые идеи.
Концепция в том, чтобы рисовать сразу весь сектор целиком. В секторе мешы отсортированы по материалам. Сколько материалов - столько и мешей.
То есть получается любопытная ситуация в кадре треугольников в десятки раз больше, а фпс - выше. Но разбиение на сектора выполняет левел-дизайнер. Я в этом проблемы абсолютно не вижу - ареапортальный браш ставится один раз в дверном проёме и маппер точно знает, что в этом месте карта будет поделена на два сектора, в отличие от хинта, который может и не помочь. Причём он бы скорее всего и так бы туда этот хинт залепил, ну просто другой текстурой покрасит. Я вот вообще заметил, что народ очень любит оптимизировать вручную. Ну так надо дать им в этом больше возможности. Всего каких-то пять лет назад я считал совершенно иначе.
Ну вот вы видите Волатилу, построенную на этих принципах.
Я вот вообще заметил, что народ очень любит оптимизировать вручную.
Из-за предсказуемости. Кстати, подумалось тут, а для этих секторов какие-то предвычисления объёма/размеров/материалов на этапе коптиляции можно проводить, например, что бы автоматически привязать к ним roomtype?
Вот какую интересную фигню я заметил. Использование nvtristrip УМЕНЬШАЕТ фпс, вместо того, чтобы его увеличивать.
Пробовал менять размер кэша, играться с параметрами, итог всегда один. Простая индексация вертексов даёт лучший результат, нежели индексы, пропущенные через nvstristrip.
Вот примерчег:
Слева стриптнутая геометрия (рисуется через GL_TRIANGLE_STRIP), справа обычный лист, рисуется через GL_TRIANGLES. Если кто не понял, поясню, strip-режим позволяет экономить индексы, в отличие от листа. Правда это же осложняет и простейшие операции, поэтому на правой картинке поликаунт неверный, он совпадает с левой, но его нельзя посчитать, просто поделив индексы на 3. Поэтому он там неверный. То есть вот такая ситуация.
Может быть дело в том, что я использую glMultiDrawElementsBaseVertex, а для классических режимов будет прирост? Интересное кино.
Добавлено 24-05-2020 в 13:50:
Поигрался с SetCacheSize, наилучший результат получается при подстановке значения 1024 - фпс возрастает до 650. Но всё равно он меньше чем без использования NvTriStrip. И да, с таким размером кэша кратно увеличивается время работы. Без него карта собирается 9 секунд, а с ним - минуту.
| IP: 
22-05-2020 11:30
