Лучшим способом было бы использовать (очень маленькую) текстурную карту для указания различных цветов лица.
Каждый материал glTF соответствует программе шейдера, стеку текстур и настройкам материала, используемым в одном вызове отрисовки. Если вы запрашиваете разные настройки, например, разные значения baseColorFactor для некоторых полигонов, тогда типичному механизму рендеринга потребуется выполнить более одного вызова отрисовки, чтобы получить весь рендеринг me sh.
В вашем примере с кубом это означает, что типичный механизм рендеринга, скорее всего, установит для некоторого значения uniform значение red, затем загрузит только вершины красных граней куба в графический конвейер, а затем запустит весь конвейер. Дождитесь, пока вершинный шейдер сделает свое дело, растеризатор разрезает треугольники на фрагменты, фрагментный шейдер закрасит все фрагменты красным, и пиксели выйдут с другой стороны. Затем, как только весь конвейер будет очищен от данных и сброшен, только тогда значение uniform будет изменено с красного на синий. Теперь загрузите вершины для синих граней и перезапустите весь конвейер с самого начала. Уч. Слишком медленно.
Вместо этого поместите небольшую карту текстуры с красной областью и синей областью. Грани куба не имеют общих нормалей, а некоторые не имеют УФ-лучей, поэтому на кубе будет 24 вершины. Механизм рендеринга загружает шейдерную программу, загружает карту текстур, а затем выгружает все 24 вершины в графический конвейер и позволяет ему копироваться. Таким образом, весь я sh может быть выполнен в одном материале, используя один glTF primitive, что приводит к одному вызову отрисовки.
Это большое усилие по оптимизации одного вызова отрисовки не Стоит это в вакууме, но если это указывает на паттерн, который часто повторяется в модели, или если me sh или модель многократно приводятся в действие, оптимизация становится стоящей. Если каждый кадр анимации поднимается на тысячи вызовов отрисовки, некоторые пользователи в некоторых системах могут начать замечать отставание.