Лучшим способом было бы использовать (очень маленькую) карту текстур для обозначения разных цветов лица.
Каждый материал glTF соответствует программе шейдера, стеку текстур и настройкам материала, используемым в одном вызове отрисовки. Если вы запрашиваете разные настройки, например разные значения baseColorFactor для некоторых полигонов, то типичному механизму рендеринга потребуется сделать более одного вызова отрисовки, чтобы визуализировать всю сетку.
В вашем примере с кубом это означает, что типичный механизм рендеринга, скорее всего, установит какое-то значение uniform на красный, затем загрузит только вершины красных граней куба в графический конвейер, а затем запустит весь конвейер. Подождите, пока вершинный шейдер сделает свое дело, растеризатор разрезает треугольники на фрагменты, фрагментный шейдер окрашивает все фрагменты в красный цвет, а пиксели выходят с другой стороны. Затем, как только весь этот конвейер очищается от данных и сбрасывается, только тогда значение uniform будет изменено с красного на синий. Теперь загрузите вершины для синих граней и перезапустите весь конвейер с самого начала. Ой. Слишком медленно.
Вместо этого поместите небольшую текстурную карту с красной и синей областями. Грани куба не имеют общих нормалей, а некоторые не имеют общих UV-разверток, поэтому на кубе будет 24 вершины. Механизм рендеринга загружает программу шейдера, загружает карту текстур, а затем выгружает все 24 вершины в графический конвейер и позволяет копировать. Таким образом, вся сетка может быть сделана из одного материала, используя один glTF primitive, что приведет к одному вызову отрисовки.
Эти большие усилия по оптимизации одного вызова отрисовки не стоят того в вакууме, но если это свидетельствует о шаблоне, который часто повторяется в модели, или сетка или модель создаются много раз, оптимизация становится стоит. Если на каждый кадр анимации приходится тысячи вызовов отрисовки, некоторые пользователи некоторых систем могут начать замечать задержку.
person
emackey
schedule
30.04.2020
