Вообще по сути с текущим пайплайном, как я его понял, проблема не только в текстурах, ведь одна текстура может шариться на несколько материалов, например, а значит конвейер будет тормозиться уже не на смене текстуры, а на переключении шейдера
ну текстура, материал, неважно. Понятно же что речь идёт об уникальном объекте. Пока не было шейдеров, в их роли выступали текстуры.
Список фейсов хитро отсортирован, чтобы минимизировать все переключения, так что этот фактор не влияет.
Вообщем я опробовал сравнительно свежий glMultiDrawElementsBaseVertex
и древний glMultiDrawArrays. И вот последний в моём случае дал наилучший результат. В принципе, когда у тебя вот такие вот три-фаны, их наверное и правда лучше рисовать совсем без индексов - быстрее будет.
Поскольку текстура потенциально может грузиться из разных мест, добавил в скрипт функцию addImageLocation. Конечно при нормальной разработке игры, это ненужно, но для моей отладки, когда у меня тут зоопарк из разных карт, в том числе и кутришных, это может оказаться полезным.
Через этот же механизм реализуется и дефолтная текстура, которую можно задать, если ничего не нашлось. Для бампа, например можно сделать чёб он поискал текстуры с разными суффиксами, ну там _gloss, _spec понятно.
Для диффузки - в ваде, в папке textures и так далее. Эти пути конечно тожы можно перегружать раздельно для шейдер объекта, для материала и для техники и заключать в условия.
Добавлено 31-10-2019 в 17:18:
Вчера ради интереса поглядел как это устроено в старом Unigine - там очень похожая схема, ну просто очень. Точнее не схема, а концепция, там тоже есть обозначенные типы проходов - амбиент, разные типы лайтов, отложка, постпроцесс. Но там довольно много встроенных параметров, у меня нет вообще. Полностью настраиваемый конвейер.
Для полного щастья осталось добавить команду cvar, которая будет регистрировать квары, например из game.rc и можно создавать различные рендереры, вообще не затрагивая код.
С китайскими детайлами одна беда - они сделаны для сохранения совместимости, поэтому кол-во производимых лифов просто зашкаливает.
Сами понимаете, проверять десятки тысяч лифов на каком-нибудь сепульчере дорогостоящее удовольствие. Можно конечно пойти простым путём как Ксерокс, прикрутить кутришные карты. Но так неинтересно.
Тут всё дело в том, что у нас есть необходимая информация, чтобы из общей кучи лифов и нодов восстановить дерево без детайлов. Ну точнее говоря, смержить все детайл-лифы обратно в один, и ноды подсократить. Насколько их меньше? ну скажем на Edge Of Forever 145 тысяч лифов, а реальных, которые отвечают за видимость около двух тысяч (кстати даже меньше чем в ку3). Лифы, первый в списке это основной, остальные с таким же оффсетом виздаты - детальные. Ну и руководствуясь этой информацией, как вы понимаете, идя, обратно по родителю лифа, можно найти детальные ноды и построить новое дерево. Правда оно не годится для трассировки например, только для видимости. так что старое тоже останется.
Мне это напоминает, как какой-то чувак увидел в хидерах vgui какой-то класс SurfaceGL и тут же решил что это мониторы из третьего дуума. Ну ему просто очень хотелось, чтобы они там оказались.
Дядя Миша писал: Ну што, работа идёт потихоньку. С новой скриптовой системой фичи добавлять одно удовольствие. Бамп подключил со спекуляром, за час.
Собсно, справился бы за пять минут, но ведь новые части системы написаны, а еще толком не отлажены. Плюс некоторые уточнения концепции.
Конечно нельзя сказать, что всё гладко. К примеру самая главная проблема отрисовки брашей - она никуда не делась. Надо придумать как оптимизировать это дело. А дело тут вот в чём:
Модель - понятно, загрузил меш, загрузил его индексы и рисуй себе.
С брашами не так. Там конечно можно весь мир засунуть в один вбо, но рисовать-то придётся по видимым фейсам, накапливая их в промежуточном буффере. Это первая проблема, то что нужен такой массив. Вторая проблема, что для того, чтобы сказать драйверу, какие именно сурфейсы рисовать, нам очевидно надо проталкивать индексы по шине каждый кадр.
Их не надо хранить, они всегда производное от surf->firstvertex (можете в ксаш-моде посмотреть), но положение это не спасает. Во первых их надо накопить в массиве. Во вторых их надо загрузить в видеопамять. Хреново вообщем. Пока карты стандартные халфовские это ни на что не влияет. Но взять ту же спонзу или карты рейда, и выходит что мы за кадр проталкиваем порядка 40 тысяч индексов. Конечно не вертексов, конечно это быстрее.
Но всё равно. Там где могло бы быть 2000 фпс, остаётся всего 300-400.
А с лайт-проходами и прочим, падение будет еще сильнее. Плюс это только рендерер. Вообщем имеет место быть мультипликационный эффект падения производительности. Надо придумать что с этим сделать.
Самое очевидное решение - вообще не использовать сложную брашевую архитектуру оставим на усмотрение дизайнерам. Если бы таких карт в природе не было, я бы может и не парился. Но они есть. И с этим надо что-то делать.
Добавлено 30-10-2019 в 18:51:
Из влобных решений - можно попробовать завести VBO для каждого фейса, но чёт мне кажется это плохая идея.
О, круто. Это решение потом можно будет и в ксашмод перетянуть.
З.Ы: Не эту идею с кучкой VBO, конечно же.
| IP: 
30-10-2019 20:54
