Современные технологии вроде Nanite (Wukong на UE5) , Mesh Shaders (Alan Wake 2 на Northlight) или Path Tracing (в комбинированном виде в Cyberpunk 2077 на REDengine) решают проблемы в той или иной степени о которых пойдет речь ниже, но это все еще что-то на богатом — эти технологии дорогие и кризис в микроэлектронике с подскочившими ценами подсказывают мне, что эра растеризации с его Quad Overshading (черт знает как на этот термин правильно говорить на русском, но к нему я еще вернусь) еще далека от завершения. Поэтому то, о чем пойдет речь, еще актуально, будет актуально и поэтому база. А базу знать надо. Тут сразу оговорюсь, что я не технический художник, а вообще гуманитарий, но в данном случае не обязательно знать формулу всемирного тяготения, чтобы понимать, что яблоко падает вниз.

Говоря об оптимизации сетки, начинающие часто думают, что если уложится в количество точек или треугольников в модели согласно ТЗ, больше можно ничего не учитывать — работа сделана и на этом их полномочия все. Однако есть еще один важный момент — равномерная и адекватная плотность сетки. Представьте что-то похожее на фрисби — выпуклый диск с подгибом вниз по краю. По наибольшему радиусу у него, допустим, петля из 24 ребер и по мере уменьшения радиуса количество ребер не меняется. Это будет означать, что с близкого расстояния по силуэту будет заметна небольшая угловатость, а ближе к центру размер треугольников может быть неоправданно маленьким. Это сигнал перераспределить сетку иначе: сократить на петлях меньшего радиуса, а на большом, напротив, увеличить или перенести оставшийся запас на другой элемент объекта, где не хватает плавности.

И вот тут мы подбираемся к самому главному: а чем еще плохи треугольники с маленькой площадью? Это тот самый момент, когда мы возвращаемся к Quad Overshading. При классической растеризации видеокарта обрабатывает не каждый пиксель отдельно, а целыми блоками 2х2 пикселя и когда треугольник настолько крошечный, что занимает из блока только 3 или вообще 1 пиксель, видеокарта все равно считает весь блок и 1 или 3 пикселя считаются зазря. Не страшно когда такие треугольники вылезают в паре мест, но если их много, на оптимизацию вычислений это влияет прилично.

Отдельно существуют и экстремально вытянутые треугольники, они не только тонкой иглой проходят через множество блоков, чем опять же забирают больше ресурсов чем могли бы, но эта не единственная их проблема: на них плохо ложится свет и могут вылезти артефакты как на вычислениях в пространстве экрана, так и при бейке, а еще если геометрия с ними нужна для расчета коллизий, то физический движок может повести себя некорректно и запустит игрока на орбиту или протолкнет под землю.

Так же вспомню про треугольники с нулевой площадью, когда три точки лежат на одной линии или хотя бы две точки в одной позиции — такие треугольники называют дегенеративными или вырожденными, они ломают расчеты нормалей и мусорят в памяти, ведь часть ресурсов уходит на их отсечение. С просто вытянутыми треугольниками без криминальных значений в площади, возникает другая проблема условно когда треугольник полностью находится за другим, то он отсекается и просчет идет один раз, но стоит хоть одному кусочку показаться, как просчет будет дважды.

На том же самом многие спотыкаются, когда есть задача сделать лоды, копии геометрии с итерируемым уменьшением детализации (Level of Detail или LoD). Тут так же многие спотыкаются, когда упрощают сетку ориентируясь исключительно на цифры — нужно не просто сокращать количество треугольников, но в первую очередь разряжать плотную сетку, т.к. лоды обрисовываются на расстоянии, когда объект всего из 20 всего плоскостей на 100 метрах от камеры игрока превратится в кашу из субпиксельных, их еще и так называют, треугольников.

Помимо уже упомянутого, есть и другие проблемы, но так глубоко в это я еще не залезал.

Вместо эпилога, хотел бы немного отрефлексировать, что очень грустно как технические художники «хранят свои секреты» и мало кто об этом пишет в документации под проекты или рассказывает на курсах чуть детальнее, чем «ну вот так вот заведено».