Соединяя точки

Эта маленькая глава посвящена тому, что не даёт вершинам рассыпаться – рёбрам. То, каким образом они формируют треугольники важно для художника, который стремится производить эффективный арт. И не только потому, что они определяют форму, а ещё и потому что они определяют скорость визуализации этих самых треугольников весьма нетривиальными способами. Как вы думаете, как отрендерить пиксель, который находится прямо посередине ребра, которое делят два треугольника? И опять решение самое простое. Вам придётся рендерить этот пиксель дважды, для каждого треугольника, а потом смешивать результаты. Что приводит нас к довольно интересной концепции – чем выше плотность сетки, тем больше перерендеренных пикселей мы получим, что значит большее время отрисовки. Если предположить что каждый треугольник объекта станет размером с пиксель, то общего количества пикселей затраченных на отрисовку одного этого объекта хватило бы ещё на полтора-два таких. Но для этого у нас к счастью есть LoDы.  В принципе эти знания не должны никак влиять на то, как вы моделите, однако есть специфические ситуации в которых они послужат вам добрую службу. Триангуляция – как раз один из таких случаев. То, что тонкие треугольники не совсем хороши для рендера факт довольно широко известный. И это вполне обосновано, когда мы говорим о моделинге в общем. Но, если, говоря о триангуляции, мы скажем, что сделали маленький тонкий треугольник, то это же будет означать, что, тем же самым действием, мы сделали другой треугольник больше. Представьте что будет, если мы будем удаляться от равномерно триангулированной модели: чем меньше становится объект, тем больше становится плотность сетки, а как следствие и шансы многократного рендера одних и тех же пикселей.

Однако если мы отбросим равномерную триангуляцию и позаботимся о том, чтобы каждый треугольник имел наибольшую возможную для себя площадь(и как следствие включал в себя как можно больше пикселей), тогда в итоге мы получим треугольники с последовательно уменьшающимися площадями. И теперь, когда вы вновь попробуете отдалиться от объекта, то увидите, что области с наибольшей плотностью ребёр будут ограничены намного меньшим количество экранных пикселей. Так что, чем меньше становится объект, тем меньше пикселей вам придётся перендеривать. Вы так же можете подойти с обратной стороны и пытаться сделать каждое ребро как можно короче. Это поможет сделать ваши объекты более эффективными и спасёт то время, которое могло быть потрачено на отрисовку одних и тех же пикселей.  Если вы столкнётесь с диллемой – добавить аккуртных скосов(chamfer) по краям объекта, сделать его более гладким, но в тоже время наплодить маленьких треугольников, что вроде как плохо, то я советую вам выбрать вариант, от которого ваша работа визуально выиграет. Это всегда самый важный ориентир. А сотпимизировать лишнего в крайнем случае – дело трёх минут.

Питаться маленькими порциями – сытнее

Точно так же как ваш движок отрисовывает объект треугольник за треугольником, он отрисовывает всю сцену объект за объектом. Чтобы визуализировать объект – нужно послать запрос на отрисовку(draw call). Поскольку компьютерное железо создано человеком - оно по природе своей бюрократично. ) Вы не можете просто скакать от объекта к объекту и рендерить, что заблагорассудится. Сначала необходимо провести некоторые приготовления. Центральный процессор и Графический процессор распределяют обязанности примерно следующим образом: В том время как ГП занимается непосредственной визуализацией, ЦП собирает информацию и готовит следующие порции к отправке ГП. Для нас с вами тут важно то, что, если ЦП не успеет собрать пакет для ГП к тому моменту, как он закончит с предыдущим, то ГП просто нечего делать. Исходя из этого, мы можем сделать вывод, что визуализация объектов с маленьким количество треугольников совсем не такое эффективное занятие, как кажется на первый взгляд. Вы потратите больше времени на подготовку к визуализации, нежели на саму визуализацию, а так же профукаете драгоценные миллисекунды, в которые ваш графический процессор мог обсчитывать что-нибудь впечатляющее.

A frame from NVidias 2005(?) GDC presentation

Количество треугольников которое ГП может обсчитать до того как ЦП подготовит следующий пакет значительно разнится, но я думаю я смогу привести несколько примеров. Где-то в UDN я видел, что для Unreal Engine 3 это цифра в пределах от 1000 до 2000 треугольников. Работая с движком Big World, мы установили планку на 800, хотя некоторые программисты поговаривали, что 1000 может оказаться ближе к реальности. Вы невероятно поможете своей арт команде если определите подобную цифру для своего проекта. Она сможет спасибо тонну, как рабочего, так и визуализационного времени. Плюс она служит прекрасным ориентиром, который поможет художникам разбираться со спорными ситуациями абсолютно самостоятельно. Вы захотите сделать менее детализированную модель, только если дальше добавлять деталей не имеет смысла и их всё равно никто не заметит. К счастью это работает и в обратную сторону – вы вряд ли захотите делать вашу модель более лоупольной чем это число, если у вас не будет на это каких-то особенных причин. Плюс ко всему треугольники, которые у вас останутся в резерве смело можно потратить на то чтобы срезать немного тех невидимых вершин о которых мы говорили ранее. Добавьте немного скосов по рёбрам и смело назначайте одну группу сглаживания. Это может звучать странно, но делая немного более высокополигональными ваши модели вы на самом деле можете помочь производительности. Если вы хотите, чтобы ваша игра более эффективна, то старайтесь не делать совсем низкополигональных моделей отдельными самостоятельными объектами. Если вы делаете, например, сцену в таверне, то вам не хотелось бы, чтобы каждая вилка, ложка, тарелка и нож на столе были разложены в ручную в редакторе игры. Скорее вы захотите соединить их в наборы или даже объединить их со столом. Да возможно разнообразия у вас будет меньше, но если вы сделаете всё как надо, то на это никто даже не обратит внимания. Но это ни в коем случае не означает, что вы должны сейчас кидаться и назначать на все ваши игровые объекты turbosmooth. Есть вещи, которых стоит остерегаться и которые требуют как можно меньшего количества вершин. Например стенсильные тени, инстансинг и даже вершинное освещение, к примеру. Плюс ко всему некоторые движки объединяют несколько объектов в один запрос на отрисовку, так что будьте бдительны. Я ещё буду говорить об этом в конце части о “Том, что вам надо знать”.