Для оптимизации 3D-моделей недостаточно считать полигоны / Хабр

Разобравшись с основами процесса рендеринга мешей, вы сможете применять различные техники для оптимизации скорости рендеринга.

Введение

Сколько полигонов мне можно использовать? Это очень частый вопрос, который задают художники при создании моделей для рендеринга в реальном времени. На этот вопрос сложно ответить, потому что дело не только в цифрах.

Я начинал карьеру как 3D-художник ещё в эпоху первой PlayStation, а позже стал программистом графики. Хотел бы я прочитать эту статью перед тем, как впервые начал создавать 3D-модели для игр. Рассмотренные в ней фундаментальные основы пригодятся многим художникам. Хотя бОльшая часть информации из этой статьи не повлияет значительно на продуктивность вашей ежедневной работы, она даст вам базовое понимание того, как графическая карта (graphics processing unit, GPU) отрисовывает создаваемые вами меши.

От количества полигонов в меше обычно зависит скорость его рендеринга. Однако несмотря на то, что количество полигонов часто коррелирует с частотой кадров в секунду (FPS), вы можете обнаружить, что даже после снижения количества полигонов меш по-прежнему рендерится медленно. Но поняв, как рендерятся меши в целом, вы сможете применить набор техник для повышения скорости рендеринга.

Как представлены данные полигонов

Чтобы понять, как GPU рисует полигоны, нужно сначала рассмотреть структуру данных, используемую для описания полигонов. Полигон состоит из набора точек, называемых вершинами, и ссылок. Вершины часто хранятся как массивы значений, например подобно рисунку 1.

Рисунок 1. Массив значений простого полигона.

В данном случае четыре вершины в трёх измерениях (x, y и z) дают нам 12 значений. Для создания полигонов второй массив значений описывает сами вершины, как показано на рисунке 2.

Рисунок 2. Массив ссылок на вершины.

Эти вершины, соединённые вместе, образуют два полигона. Заметьте, что два треугольника, в каждом из которых по три угла, можно описать четырьмя вершинами, потому что вершины 1 и 2 используются в обоих треугольниках. Чтобы эти данные мог обработать GPU, предполагается, что каждый полигон является треугольным. GPU ожидают, что вы работаете с треугольниками, потому что они предназначены именно для их отрисовки. Если вам нужно отрисовать полигоны с другим количеством вершин, то необходимо приложение, разделяющее их на треугольники перед отрисовкой в GPU. Например, если вы создаёте куб из шести полигонов, каждый из которых имеет по четыре стороны, то это не более эффективно, чем создание куба из 12 полигонов, состоящих из трёх сторон; именно эти треугольники будет отрисовывать GPU. Запомните правило: считать нужно не полигоны, а треугольники.

Использованные в предыдущем примере данные вершин являются трёхмерными, но это необязательно. Вам может быть достаточно и двух измерений, но часто необходимо хранить и другие данные, например, UV-координаты для текстур и нормали для освещения.

Отрисовка полигона

При отрисовке полигона GPU первым делом определяет, где нужно рисовать полигон. Для этого он вычисляет позицию на экране, где должны находиться три вершины. Эта операция называется преобразованием (transform). Эти вычисления в GPU выполняет небольшая программа под названием «вершинный шейдер».

Вершинный шейдер часто выполняет и другие типы операций, например, обработку анимаций. После вычисления позиций всех трёх вершин полигона GPU вычисляет, какие пиксели находятся в этом треугольнике, а затем начинает заполнять эти пиксели с помощью ещё одной маленькой программы под названием «фрагментный шейдер» (fragment shader). Фрагментный шейдер обычно выполняется один раз на пиксель. Однако в некоторых редких случаях он может выполняться несколько раз на пиксель, например, для улучшения сглаживания (антиалиасинга). Фрагментные шейдеры часто называются пиксельными шейдерами, потому что в большинстве случаев фрагменты соответствуют пикселям (см. рисунок 3).

Рисунок 3. Один полигон, отрисованный на экране.

На рисунке 4 показан порядок действий, выполняемый GPU при отрисовке полигона.

Рисунок 4. Порядок действий GPU, отрисовывающего полигон.

Если разделить треугольник на два и отрисовать оба треугольника (см. рисунок 5), то порядок действий будет соответствовать рисунку 6.

Рисунок 5. Разделение полигона на два.

Рисунок 6. Порядок действий GPU, рисующего два полигона.

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

Использование кэша вершин

Если посмотреть на два полигона из предыдущего примера, то можно увидеть, что у них есть две общие вершины. Можно предположить, что эти вершины придётся вычислять дважды, но механизм под названием «кэш вершин» (vertex cache) позволяет использовать результаты вычислений повторно. Результаты вычислений вершинного шейдера для повторного применения сохраняются в кэш — небольшую область памяти, содержащую несколько последних вершин. Порядок действий при отрисовке двух полигонов с использованием кэша вершин показан на рисунке 7.

Рисунок 7. Отрисовка двух полигонов с использованием кэша вершин.

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

Разбираемся с параметрами вершин

Чтобы вершину можно было использовать повторно, при каждом использовании она должна быть неизменной. Разумеется, той же должна оставаться позиция, но и другие параметры тоже не должны меняться. Передаваемые вершине параметры зависят от используемого движка. Вот два широко распространённых параметра:

• Текстурные координаты
• Нормали

При UV-наложении на 3D-объект любой создаваемый шов будет означать, что вершины вдоль шва не могут быть общими. Поэтому в общем случае стоит избегать швов (см. рисунок 8).

Рисунок 8. UV-наложение швов текстуры.

Для правильного освещения поверхности каждая вершина обычно хранит нормаль — вектор, направленный от поверхности. Благодаря тому, что все полигоны с общей вершиной задаются одной нормалью, их форма кажется плавной. Это называется плавным затенением (smooth shading). Если каждый треугольник имеет собственные нормали, то рёбра между полигонами становятся выраженными, а поверхность кажется плоской. Поэтому это и называется плоским затенением (flat shaded). На рисунке 9 показаны два одинаковых меша, один со сглаженным затенением, а второй — с плоским.

Рисунок 9. Сравнение сглаженного с плоским затенением.

Эта геометрия со сглаженным затенением состоит из 18 треугольников и имеет 16 общих вершин. Для плоского затенения 18 треугольников нужно 54 (18 x 3) вершины, потому что ни одна из вершин не является общей. Даже если два меша имеют одинаковое количество полигонов, скорость их отрисовки всё равно будет разной.

Важность формы

GPU быстро работают в основном потому, что они могут выполнять множество операций параллельно. В маркетинговых материалах GPU часто делается упор на количество их конвейеров (pipeline), определяющих количество операций, которые может выполнять GPU одновременно. Когда GPU отрисовывает полигон, он отдаёт множеству конвейеров задание заполнять квадраты пикселей. Обычно это квадрат размером восемь на восемь пикселей. GPU продолжает это делать, пока не будут заполнены все пиксели. Очевидно, что треугольники не являются квадратами, поэтому некоторые пиксели квадрата окажутся внутри треугольника, а другие снаружи. Оборудование работает со всеми пикселями квадрата, даже с теми, которые находятся за пределами треугольника. После вычисления всех вершин в квадрате оборудование отбрасывает пиксели за пределами треугольника.

На рисунке 10 показан треугольник, для отрисовки которого требуется три квадрата (тайла). Большинство вычисленных пикселей (голубые) используется, а показанные красным выходят за границы треугольника и будут отброшены.

Рисунок 10. Три тайла для отрисовки треугольника.

Полигон на рисунке 11 с точно таким же количеством пикселей, но растянутый, требует для заполнения большего количества тайлов; бОльшая часть результатов работы в каждом тайле (красная область) будет отброшена.

Рисунок 11. Заполнение тайлов в растянутом изображении.

Количество отрисовываемых пикселей — это только один из факторов. Так же важна форма полигона. Для повышения эффективности старайтесь избегать длинных, узких полигонов и отдавайте предпочтение треугольникам с примерно равной длиной сторон, углы которого близки к 60 градусам. Две плоские поверхности на рисунке 12 триангулированы двумя разными способами, но при рендеринге выглядят одинаково.

Рисунок 12. Поверхности, триангулированные двумя разными способами.

Они имеют абсолютно одинаковое количество полигонов и пикселей, но так как поверхность левого имеет более длинные, узкие полигоны, чем у правого, его рендеринг будет более медленным.

Перерисовка

Для отрисовки шестилучевой звезды можно создать меш из 10 полигонов или нарисовать ту же фигуру всего из двух полигонов, как показано на рисунке 13.

Рисунок 13. Два разных способа отрисовки шестилучевой звезды.

Можно решить, что быстрее отрисовать два полигона, чем 10. Однако в данном случае это скорее всего неверно, потому что пиксели в центре звезды будут отрисовываться дважды. Это явление называется перерисовкой (overdraw). По сути оно означает, что пиксели перерисовываются больше одного раза. Перерисовка естественным образом возникает во всём процессе рендеринга. Например, если персонаж частично скрыт колонной, то он будет отрисован целиком, несмотря на то, что колонна перекрывает часть персонажа. Некоторые движки используют сложные алгоритмы, позволяющие избегать отрисовку объектов, невидимых на конечном изображении, но это трудная задача. Центральному процессору часто труднее выяснить, что не нужно отрисовывать, чем GPU отрисовать это.

Работая художником, вы должны смириться с тем, что от перерисовки не избавиться, но хорошей практикой является удаление поверхностей, которые нельзя увидеть. Если вы сотрудничаете с командой разработчиков, то попросите добавить в игровой движок режим отладки, в котором всё становится прозрачным. Это упростит поиск спрятанных полигонов, которые можно удалить.

Реализация ящика на полу

На рисунке 14 показана простая сцена: стоящий на полу ящик. Пол состоит всего из двух треугольников, а ящик состоит из 10 треугольников. Перерисовка в этой сцене показана красным цветом.

Рисунок 14. Стоящий на полу ящик.

В этом случае GPU отрисует часть пола пол ящиком, несмотря на то, что его не будет видно. Если бы вместо это мы создали под ящиком дыру в полу, то получили бы большее количество полигонов, но намного меньше перерисовки, как видно из рисунка 15.

Рисунок 15. Дыра под ящиком, позволяющая избежать перерисовки.

В подобных случаях всё зависит от вашего выбора. Иногда стоит уменьшить количество полигонов, получив взамен перерисовку. В других ситуациях стоит добавить полигонов, чтобы избежать перерисовки. Ещё один пример: две показанные ниже фигуры являются одинаково выглядящими мешами поверхности с торчащими из неё остриями. В первом меше (рисунок 16) острия расположены на поверхности.

Рисунок 16. Острия расположены на поверхности.

Во втором меше на рисунке 17 в поверхностью под остриями прорезаны отверстия, чтобы уменьшить объём перерисовки.

Рисунок 17. Под остриями вырезаны отверстия.

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

Представьте, что вы моделируете дом, стоящий на земле. Чтобы создать его, вы можете или оставить землю без изменений, или вырезать под дом отверстие в земле. Перерисовки больше в случае, когда под домом не вырезана дыра. Однако выбор зависит от геометрии и точки обзора, с которой дом будет видеть игрок. Если нарисовать под основанием дома землю, то это создаст большой объём перерисовки, если войти внутрь дома и взглянуть вниз. Однако разница не будет особо большой, если вы будете смотреть на дом с самолёта. Лучше всего в таком случае иметь в игровом движке режим отладки, делающий поверхности прозрачными, чтобы вы могли видеть то, что отрисовывается под видимыми игроку поверхностями.

Когда у Z-буферов возникает Z-конфликт

Когда GPU отрисовывает два накладывающихся друг на друга полигона, то как он определяет, какой из них находится поверх другого? Первые исследователи компьютерной графики потратили много времени на исследование этой проблемы. Эд Кэтмэлл (который позже стал президентом Pixar и Walt Disney Animation Studios) написал статью, в которой изложил десять различных подходов к решению этой задачи. В одной части статьи он замечает, что решение этой задачи будет тривиальным, если у компьютеров будет достаточно памяти для хранения одного значения глубины на пиксель. В 1970-х и 1980-х это был очень большой объём памяти. Однако сегодня так работает большинство GPU: такая система называется Z-буфером.

Z-буфер (также известный как буфер глубин) работает следующим образом: с каждым пикселем связывается значение его глубины. Когда оборудование отрисовывает объект, оно вычисляет, как далеко от камеры отрисовывается пиксель. Затем оно проверяет значение глубины уже существующего пикселя. Если он дальше от камеры, чем новый пиксель, то новый пиксель отрисовывается. Если уже имеющийся пиксель ближе к камере, чем новый, то новый пиксель не отрисовывается. Такой подход решает множество проблем и работает, даже если полигоны пересекаются.

Рисунок 18. Пересекающиеся полигоны, обработанные буфером глубин.

Однако Z-буфер не обладает бесконечной точностью. Если две поверхности находятся почти на одном расстоянии от камеры, то это сбивает GPU с толку и он может случайным образом выбрать одну из поверхностей, как это показано на рисунке 19.

Рисунок 19. У поверхностей на одинаковой глубине появляются проблемы с отображением.

Это называется Z-конфликтом (Z-fighting) и выглядит очень забагованно. Часто Z-конфликты становятся тем хуже, чем дальше поверхность от камеры. Разработчики движков могут встраивать в них исправления, позволяющие сгладить эту проблему, но если художник создаёт достаточно близкие и накладывающиеся друг на друга полигоны, то проблема всё равно может возникать. Ещё одним примером может служить стена с висящим на ней постером. Постер находится почти на той же глубине от камеры, что и стена за ним, поэтому очень высок риск Z-конфликтов. Решение заключается в том, чтобы вырезать в стене отверстие под постером. При этом также снизится объём перерисовки.

Рисунок 20. Пример Z-конфликта накладывающихся друг на друга полигонов.

В крайних случаях Z-конфликт может возникнуть, даже когда объекты касаются друг друга. На рисунке 20 показан ящик на полу, и поскольку мы не вырезали в полу под ящиком отверстие, z-буфер может быть сбит с толку рядом с ребром, где пол встречается с ящиком.

Использование вызовов отрисовки

GPU стали чрезвычайно быстрыми — настолько быстрыми, что ЦП могут за ними и не успевать. Так как GPU по сути предназначены для выполнения одной задачи, их гораздо проще заставить работать быстро. Графика по своей природе связана с вычислением множества пикселей, поэтому можно создать оборудование, вычисляющих множество пикселей параллельно. Однако GPU отрисовывает только то, что ему приказывает отрисовывать ЦП. Если ЦП не может достаточно быстро «кормить» GPU данными, то видеокарта будет простаивать. Каждый раз, когда ЦП приказывает GPU что-то отрисовать, называется вызовом отрисовки. Простейший вызов отрисовки состоит из отрисовки одного меша, в том числе одного шейдера и одного набора текстур.

Представьте медленный процессор, способный передавать 100 вызовов отрисовки за кадр, и быстрый GPU, который может отрисовывать по миллиону полигонов за кадр. В таком случае идеальный вызов отрисовки (draw call) может отрисовывать 10 000 полигонов. Если ваши меши состоят всего из 100 полигонов, то GPU сможет отрисовывать только 10 000 полигонов за кадр. То есть 99% времени GPU будет простаивать. В таком случае мы можем запросто увеличить количество полигонов в мешах, ничего при этом не потеряв.

То, из чего состоит вызов отрисовки, и затраты на него сильно зависят от конкретных движков и архитектур. Некоторые движки могут объединить в один вызов отрисовки множество мешей (выполнить их батчинг, batch), но все меши при этом обязаны будут иметь одинаковый шейдер, или могут иметь другие ограничения. Новые API наподобие Vulkan и DirectX 12 разработаны специально для решения этой проблемы при помощи оптимизации того, как программа общается с графическим драйвером, увеличивая таким образом количество вызовов отрисовки, которые можно передать за один кадр.

Если ваша команда пишет собственный движок, то спросите у разработчиков движка, какими ограничениями обладают вызовы отрисовки. Если вы используете готовый движок наподобие Unreal или Unity, то выполните бенчмарки производительности, чтобы определить пределы возможностей движка. Вы можете обнаружить, что можно увеличить количество полигонов, не вызывая при этом снижения скорости.

Заключение

Надеюсь, эта статья послужит вам хорошим введением, способным помочь в понимании различных аспектов производительности рендеринга. В GPU разных производителей всё реализовано немного по-своему. Существует множество оговорок и особых условий, связанных с конкретными движками и аппаратными платформами. Всегда поддерживайте открытый диалог с программистами рендеринга, чтобы использовать их рекомендации в своём проекте.

Об авторе

Эскил Стеенберг (Eskil Steenberg) — независимый разработчик игр и инструментов, он работает и консультантом, и над независимыми проектами. Все скриншоты сделаны в активных проектах с помощью инструментов, разработанных Эскилом. Подробнее о его работе можно узнать на сайте Quel Solaar и в аккаунте @quelsolaar в Twitter.

3D в играх: Полигоны | StopGame

3D в играх. Часть 2

Полигоны
Как мы выяснили в прошлой части, современные трехмерные компьютерные игры строятся на основе полигонов. Но, что же это за зверь такой?

Полигон (Polygon) – это плоскость в евклидовом пространстве. Пространство имеет размерность три, соответственно, имеются три координаты: X, Y, Z. Условно их можно обозвать как длина, высота и глубина. В программном обеспечении для 3D нет единого стандарта относительно, так сказать, ориентации данных координат, хотя, как правило, координата X параллельна условном горизонту, т.е. это длина, а вот условной высотой может быть как Y так и Z. Соответственно, условной глубиной может быть как Z, так и Y. Но нам это не столь суть важно, примем для последующего материала представление, показанное ниже.

У полигона есть вершины, минимум три, максимум, теоретически, бесконечность. Практически максимум – много. Но в играх используются треугольные полигоны, т.е. полигон имеет три вершины. Почему именно три? Через три точки в пространстве можно провести только одну плоскость, что упрощает расчеты и позволяет избежать искажений (артефактов) на итоговой картинке связанных с тем, что вершины полигона могут лежать не в одной плоскости.

Однако в программах трехмерного моделирования принято пользоваться 4-х угольными полигонами, а вот 5-ти и больше, как правило, под запретом. Поэтому при моделировании приходится следить за тем, чтобы все 4 вершины полигона были в одной или почти одной плоскости. А как же игры? спросите вы. Полигон с 4-мя вершинами математически очень просто превратить в два треугольных с двумя общими вершинами, что и делается автоматически при экспорте в игровой движок.

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

Почему сетка? Из полигонов создаются трехмерные объекты для игр (и не только), и если рассматривать все эти полигоны издалека включив отображение сторон полигона, они же ребра, то все это похоже на сетку.

Вообще, полигон – это то, чего на самом деле не существует, это всего лишь математика. У него нулевая толщина. Это координаты трех (для игр, далее будем говорить только о треугольных полигонах, если не будет указано иное) точек в трехмерном пространстве. И то, как отображать эти несуществующие полигоны, — зависит исключительно от той или иной компьютерной программы. Как правило, существуют три основных вида отображения: каркасная сетка, полигональная сетка, «чисто» полигональное представление. На рисунке ниже даны все три вида.

При моделировании, тестировании и т.п. для закрашивания плоскости между вершинами полигона используется произвольный цвет, но зачастую это так называемый сермат, RGB 128,128,128. На нем удобно тестировать, в частности, освещение. Да и однородная заливка, в отличии от полновесных текстур, использует не так много ресурсов компьютера.

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

Кроме координат вершин есть у полигона такое свойство как нормаль. Это вектор, перпендикулярный одной из сторон плоскости полигона. Так как это вектор, то у него есть направление. Это направление указывает лицевую сторону полигона, вернее его начало находится у лицевой стороны полигона. Нужна нормаль для наложения текстур и расчета освещенности. Так же хочу заметить, что математически полигон не имеет никакого отношения к тому, как он выглядит, т. е. к текстурам. Полигон отдельно, текстуры – отдельно.

Так вот, та сторона, из которой «выходит» вектор нормали — и определяет лицевую сторону полигона, поэтому с противоположной стороны полигон прозрачен при визуализации, вернее обратной стороны просто не существует. Именно поэтому когда игровой персонаж из-за некорректных коллизий проваливается сквозь текстуры, то почти все сверху кажется полупрозрачным – текстур, вернее обратной стороны у полигона не существует.
Ниже скриншот из игры Batman Arkham Knight.

То же можно наблюдать, если попасть туда, куда игровой персонаж попадать не должен по задумке разработчиков: за уступы скал, в закрытые помещения и т.п. И это не баг игрового движка, это его особенность, ну, и недосмотр при тестировании (или разработчики не отреагировали должным образом на отчет тестировщиков). Необходима такая особенность для оптимизации расчетов итоговой картинки, или, по-другому, рендеринга. Ведь совсем незачем тратить вычислительные ресурсы на то, что никто никогда увидеть не должен.

Внимательный читатель может спросить: а как же быть в том случае, если игровой персонаж должен зайти в помещение? Тогда необходимо, как и в реальном здании, придавать стенам (потолку, крыше, дверям и т.д.) толщину с помощью двух полигонов у которых нормали смотрят в противоположные стороны.

Ниже показан фрагмент модели здания со стеной, имеющей реальную толщину. Синим показано направление нормали у полигонов.

Для совсем тонких предметов, таких как лист бумаги, применяется другой подход и зависит он от конкретного игрового движка. Например, может применяться специальный двухсторонний материал или отключаться параметр Backface culling, и в этом случае объект будет выглядеть одинаково с обеих сторон. (Подробнее про Backface culling можно почитать тут: Полигоны, свободная камера и MGS 5)

Теперь поговорим о том, какие бывают трехмерные полигональные модели.

3D модели принято делить на низкополигональные (low poly) и высокополигональные (high poly). Как несложно догадаться – разница в количестве полигонов, причем разница не абсолютная, а, как и все в нашем мире, относительная.

Высокополигональной можно назвать модель с самодостаточной геометрией, т.е. когда даже мелкие детали (в разумных, конечно, пределах) смоделированы с помощью полигонов и при этом модель выглядит достаточно правдоподобно даже без текстур. Непосредственно в играх high poly модели, как правило, не применяются, однако они необходимы в процессе разработки 3D игры, о чем будет рассказано ниже.

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

Низкополигональные модели применяются в основном в играх или для анимации, когда визуальный реализм не имеет первостепенного значения. Есть два основных способа получения низкополигональной модели: непосредственное моделирование с прицелом на малое количество полигонов или упрощение высокополигональной модели. То же справедливо и для high poly моделей (если не брать в расчет 3D сканирование): их получают путем усложнения и добавления полигонов низкополигональной модели, либо моделируют сразу из расчета максимально необходимого количества полигонов. Какой подход применятся в том или ином случае зависит от многих факторов, как то: геометрии самой модели, применяемого программного обеспечения, наличия похожих моделей, принятого в студии-разработчике порядка разработки, предпочтений 3D-художника и т.п.

Хочу особо обратить внимание на то, что разделение на high poly и low poly очень и очень относительно. Зависит от многих факторов, и одна и та же модель может быть как низкополигональной, так и высокополигональной. Например, для игры для ПК была разработана высокополигональная модель персонажа, затем из нее получили низкополигональную, условно, уменьшив количество полигонов в два раза. А позже решили портировать игру на мобильные устройства. И количество полигонов, опять же, условно, для этого сократили в четыре раза по сравнению с изначальной моделью, или в два раза по сравнению с моделью для ПК-версии игры. Ведь мобильные устройства мало того, что не такие мощные, как ПК, так еще и размер экрана не позволяет различить мелкие детали, поэтому такая высокая детализация, как для полноразмерного монитора, там попросту не нужна.

Ниже показаны сферы одинакового диаметра с различным количеством полигонов.

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

Ниже представлена эволюция полигональной Лары Крофт.

Как же получают 3D модели? Традиционно для этого используется полигональное моделирование в специальных программных пакетах, как то: 3ds Max, Maya, Cinema 4D и т. п. В последнее время к разработке также подключают программы для так называемой трехмерной лепки, к примеру ZBrush и 3D-Coat. Ну, и с развитием технологии 3D сканирования, модели получают путем этого самого сканирования с последующей оптимизацией полигональной сетки.

Если используется традиционное полигональное моделирование, то 3D художнику необходимо от чего-то отталкиваться. Для этого используются так называемые референсы, или, по-другому, изображения того, что необходимо смоделировать. Это могут быть фотографии (для реальных предметов или персонажей), концепт-арты (для вымышленных), или даже существующие объекты. К примеру, необходимо смоделировать существующие кубики Lego. Самая в данном случае хорошая идея – иметь их под рукой и моделировать, непосредственно вертя в руках эти самые кубики.
Ниже изображение референса и 3D модели (без текстур).

Теперь вернемся к вопросу: а зачем при разработке 3D игры иметь в наличии сразу две модели одного и того же объекта — high poly и low poly? Высокополигональная модель непосредственно в игре использоваться не будет, но она необходима для такого важного процесса, как запекание текстур. Так называют подготовку целого ряда текстур или, как их еще называют, карт. Это обычные файлы изображений (с необычными, на первый взгляд, рисунками в них) цель которых как можно реалистичнее представить модель в игре и взять на себя, так сказать, часть геометрии. По сути – это создание 3D иллюзии там, где добиться этого полигонами сложно, неподъемно по производительности или просто нецелесообразно.

Возьмем, к примеру, старую доску. В ней может быть множество трещин и мелких сколов. В реальности это перепад высот (или глубин) материала самой доски. И, по-хорошему, полигоны также должны повторять эти перепады. Но тогда модель может оказаться настолько высокополигональной, что никакое железо не потянет это количество полигонов. Поэтому для начала моделируют как можно более подробную высокополигональную модель этой самой доски, а затем с помощью специальных программ генерируют (запекают) карты высот, затенения и т.п. для имитации этих самых трещин и сколов на низкополигональной модели.

Ниже упрощенно схематически показано как смешивание запеченных с high poly модели карт, в сочетании с текстурой дерева, в результате дает реалистичное изображение.

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

Правда, тут есть один недостаток: эффект лучше всего действует когда наблюдатель расположен под углом 90° относительно полигонов с такой вот имитацией дополнительной геометрии. С уменьшением или увеличением угла обзора «обман» становится виден все отчетливее и отчетливее. Но это неизбежная плата за возможность приблизить картинку к реализму, не превратив игру в неиграбельную.

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

Если уж мы говорим про 3D в играх, то следует обязательно упомянуть такую технологию, как LOD, сокращенно от Level of Detail, она же уровень детализации. Суть ее сводится к тому, что в зависимости от того, насколько тот или иной объект близко располагается от игрового персонажа, или какой процент высоты экрана занимает, то используются модели с различного рода детализацией. Опять же, все ради оптимизации. Чем ближе к виртуальной камере тот или иной объект, тем более детализированная модель подставляется. На практике часто количество таких моделей ограничивается тремя: для переднего, среднего и заднего планов. И обозначаются, как правило: LOD_0, LOD_1, LOD_2. Это все варианты низкополигональной игровой модели.

Различные варианты полигональной детализации могут создаваться как в сторонних программах, так и автоматическими игровыми движками (очевидно, не всеми). Причем автоматически в сторону упрощения геометрии, т.е. загруженный в игровой движок вариант по умолчанию воспринимается как LOD_0. Иногда в играх, особенно с большими открытыми мирами, можно заметить как изначально угловатый и неказистый объект вдруг скачкообразно «похорошел» — это произошла замена на более высокополигональный LOD.

Вот, наверно, вкратце и все про полигоны. Если остались необозначенные или нераскрытые моменты – пишите про это в комментариях.

По идее, далее необходимо продемонстрировать этот самый процесс полигонального моделирования, дабы наглядно показать, как это делается. И пример должен быть не очень простой, ради показа хотя бы нескольких приемов моделирования, но и не очень сложный, чтобы не нагонять сон на зрителя. Я думал-думал над предметом моделирования и пришел к выводу, что модель керосиновой лампы неплохо впишется в данную концепцию. Но, дабы не утомлять читателя, решил собственно процесс моделирования вынести в третью, или, если хотите, в 2,5 часть повествования, которую надеюсь опубликовать в ближайшем будущем.

А на этом пока все, до новых встреч!

Теги

3ds Max

polygon

трехмерное моделирование

текстуры

Нарезка стрима

Пошутил) | Лучшие моменты (КЕК!)

1
Новость

Street Fighter 6: больше геймплея, бойцы из DLC и релиз демоверсии

Лина Скорич
7
Новость

Красочный платформер Itorah добрался до консолей

Андрей Маковеев
1
Разбор полетов

Fable. Самая многоОБЕЩАВШАЯ игра Питера Молиньё

97
Первая полоса

Крутые игры, о которых мало кто знает

Редакция
35
Новость

Клифф Блежински хочет воскресить LawBreakers, но надо договориться с издателем

Руслан Присекин
18
Новость

NieR: Automata разошлась тиражом 7,5 миллиона копий

Руслан Присекин
13
Первая полоса

Обзор фильма «Братья Супер Марио в кино»

Алексей Лихачев
15

Полигоны и текстуры (или «учебник по звездному небу»)

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

С момента появления трехмерной компьютерной графики люди искали способы уменьшить сложность, чтобы оборудование могло работать лучше. Это относится как к рендерингу, так и к графике в реальном времени — заставить компьютер рисовать что-то на экране может быть на удивление сложно. Глядя на конкретный 3D-объект или визуализацию, так называемые эксперты обычно повторяют примерно следующее: «Эй, знаешь, ты мог бы сделать это с помощью текстуры вместо всех этих треугольников».
Это чувство всезнайки, хотя обычно исходит из лучших побуждений, не всегда является лучшим советом. На самом деле, иногда бывает с точностью до наоборот.

Знакомо?

Во-первых, давайте покажем пример, когда старый совет «текстура дешевле, чем полигоны» имеет смысл. К счастью, я уже написал учебник, который охватывает эту концепцию. Аргумент «текстура дешевле, чем полигоны», хотя часто и верен, определенно не является универсальным. Вместо этого это скорее полезное напоминание о том, что может существовать альтернатива тому, как вы могли бы что-то создать. В случаях, подобных цепочке в статье, ссылка на которую была приведена ранее, совершенно очевидно, что объект с двумя треугольниками и текстурой будет менее обременительным, чем объект с десятками тысяч треугольников. Но не все ситуации столь однозначны.

О, мои звезды!

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

На этой фотографии запечатлен вид неба, который я хотел создать, со звездами, начинающими проявляться в более темных частях неба. Фото Дэвида Аберкромби

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

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

Другая проблема со звездным фоном заключается в том, что вы несколько застряли с этим конкретным расположением звезд. В предыдущем ролике вы заметите, что на небе есть очень заметные звезды, почти похожие на облака. Может быть, я просто хочу несколько звезд здесь или там — или даже мультяшных пятиконечных звезд и планет. Было бы неплохо иметь возможность отделить небо от любых элементов, появляющихся на нем.

Геометрические узлы спешат на помощь!

Если вы новичок в системе геометрических узлов Blender, это может показаться немного пугающим. Есть еще один учебник, в котором рассматриваются основы (и не только) узлов геометрии, поэтому вы можете сначала проверить его. Но я постараюсь, чтобы здесь все было просто. Кроме того, на самом деле это более простое использование узлов геометрии и хорошее место для начала.

Рождение звезды

Со временем нам понадобится звезда, которая рассеется по нашему небу, поэтому я просто создам ее сейчас. Все, из чего он состоит, — это одна полигональная сетка (2 треугольника — нет необходимости в каких-либо подразделениях) с очень простой текстурой на ней. Я сделал белый круг со слегка размытым краем, но каждая звезда будет так далеко, что любая деталь может быть потеряна. На изображении ниже вы можете видеть, что я установил «Режим наложения» на «Альфа-смешение» или «Альфа-обрезка» (в зависимости от того, насколько мягким должен быть край). У моего изображения не было встроенной альфы (прозрачности), поэтому мне пришлось использовать вывод «Цвет», чтобы передать альфа-вход узла Principled BSDF.

Мое маленькое круглое изображение размером 128×128 не имеет прозрачности, поэтому я использую его цвет для управления альфой (прозрачностью) материала. Не забудьте установить «Режим наложения», иначе вокруг ваших звезд будет черный фон.

Я назову свой меш «Звезда.001», чтобы потом легко было его найти.

Не беспокойтесь о размере сетки звезд. Блендер, вероятно, сделал его 1 или 2 метра (в квадрате), но мы будем контролировать размер другим способом.

💡

Я исключил это из изображения выше, но в итоге я также соединил выход «Цвет» изображения звезды с входом «Излучение» узла Principled BSDF и немного увеличил «Силу излучения». Я хочу, чтобы звезды выглядели освещенными, так что это будет важно, когда они появятся в Hubs.

Что насчет этого графа узлов геометрии?

Нам нужен объект для хранения модификатора Geometry Nodes (и графика), но это может быть что угодно — наш график заменит все, что вы выберете. Я обычно делаю куб по умолчанию или даже одну вершину, это действительно не имеет значения.

Объекту нужен модификатор Geometry Nodes:

Любой объект-сетка может содержать модификатор Geometry Nodes. Модификатор ничего не делает, пока вы не сделаете для него график.

Откройте рабочее пространство Geometry Nodes (меню верхней вкладки), и теперь мы можем увидеть, что произойдет, когда мы создадим для него новый график. Это можно сделать либо в модификаторе узлов геометрии, либо в окне узлов геометрии вверху.

График узлов геометрии по умолчанию. Присвоение имени вашему графику важно, особенно если у вас их несколько.

Все, что делает график по умолчанию, — это берет существующую геометрию объекта, на котором находится график (в моем случае, куба), и передает его на выход — по сути, ничего не делая.

Еще не слишком интересно, не так ли?

Мы можем полностью удалить входной узел. Почему? Ну, куб нас не интересует — это просто контейнер для этого модификатора геоузлов и графа, который он содержит. Когда мы удаляем входные данные, больше не остается никакой геометрии для передачи, поэтому в результате наш куб исчезает.

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

Удаление входных данных Geometry по умолчанию и подключение узла-примитива сетки IcoSphere вместо него.

🔤

Вероятно, вы захотите переименовать свой начальный объект. Мой продолжал сбивать меня с толку, потому что назывался «Куб». Что-то вроде «StarrySky» может иметь больше смысла.

Ближе к концу клипа выше вы можете увидеть, что настроить икосферу с помощью узла очень просто. Эта возможность неразрушающего редактирования является ключом к тому, что делает узлы геометрии такими полезными. По мере продвижения вперед это будет становиться все более и более очевидным — и вы поймете, почему я не начал с создания сетки икосферы вручную в самом начале.

Scattering the Stars

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

Во-первых, мы должны использовать узел под названием «Распределить точки на гранях». Этот узел будет смотреть на входящую геометрию (нашу недавно сгенерированную икосферу) и случайным образом размещать точки на гранях. Для лучшего понимания вы можете вернуться к статье, упомянутой ранее.

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

Далее мы добавим еще один узел в наш график:

Добавление узла «Экземпляр в точках» после узла «Распределение». Здесь я перетаскиваю сетку с одной звездой («Плоскость») прямо на график из Outliner. Это становится геометрией, которая подключается к входу «Экземпляр» узла «Экземпляр в точках».

Проще говоря, график использует объект «Плоскость» (одиночная звезда) и «экземпляр» его для каждой новой точки, созданной узлом «Распределение».

Проблема, которую мы создали сейчас, заключается в том, что мы только указали, на какие точки их поместить — мы не сказали, как мы хотим, чтобы они были ориентированы, поэтому по умолчанию они ориентированы на исходную сетку.

Относительно большие самолеты разбросаны по поверхности икосферы. Они не только слишком велики, но все они обращены в том же направлении, что и первоначальная звездная плоскость. Возможно, это начало новой Звезды Смерти…

Во-первых, мне нужно уменьшить масштаб инстансов звездных плоскостей, чтобы я мог видеть, что происходит. Будет легче понять их ориентацию, если они будут немного меньше. Здесь я просто ввожу новые значения Scale внутри узла «Instance on Points».

Есть лучшие способы работы с масштабом, но иногда вам нужно сразу увидеть вещи более четко. Значение Z-шкалы ничего не делает на этих плоскостях, но хорошо, когда это возможно, сохранять однородность.

Для ориентации мне нужно, чтобы каждая инстанцируемая звездная плоскость выровнялась с самим куполом, чтобы каждая звездная плоскость была обращена к центру икосферы. Для этого нам нужен новый узел под названием «Выровнять Эйлера по вектору». Мы возьмем «Нормальный» вывод узла «Распределение» и подключим его к вводу «Вектор» нашего нового узла. Затем мы передаем вывод «Вращение» во вход «Вращение» узла «Экземпляр в точках». (Это довольно много слов… спасибо вашим звездам за иллюстрации.)

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

💡

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

И последнее, что касается ориентации…

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

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

Backface Culling на материале гарантирует, что мы будем рисовать только передние грани меша, которому он назначен. Но это также показывает, что наши звезды обращены наружу, а не внутрь!

Хм… так что теперь мы можем видеть, что звезды на самом деле смотрят наружу, а не внутрь сцены. Есть несколько способов перевернуть их, но проще всего перевернуть лица икосферы, по которой они были разбросаны. Угадай, что? Для этого есть узел: «Перевернуть лица».

Узел «Отразить грани» просто поворачивает нормали граней на 180 градусов. Это также можно было бы сделать на оригинальной звездной сетке, но поскольку сфера на самом деле должна быть обращена внутрь , этот метод имеет наибольший смысл.

😖

Если вы начинаете чувствовать себя немного подавленным огромным количеством узлов геометрии, не волнуйтесь. Лучший способ выучить их — по одному — использовать их по мере необходимости. Прежде чем вы это узнаете, они станут частью вашего 3D словаря.

Масштабирование звезд (на этот раз лучший способ)

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

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

Здесь я использую удобную технику для создания новых узлов — обратите внимание, как я это делаю:

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

Как только это «Случайное значение» соединится со «Шкалой» «Экземпляра на очках», вы, вероятно, увидите, что ваши звезды сойдут с ума. Они просто показывают значения по умолчанию — в данном случае минимум ноль и максимум 1 по всем трем осям. Попробуйте изменить эти значения, чтобы они имели больше смысла…

Это непросто, правда? Прежде всего, вы пытаетесь изменить 6 значений (ну, 4, которые действительно что-то делают). Между тем, начальный размер исходного звездного меша, вероятно, все еще слишком велик. Это немного головная боль, пытаясь понять конечный результат.

Прежде чем паниковать, обратите внимание, что узел «Случайное значение» имеет раскрывающееся меню. Вы можете изменить его, чтобы он читался как «Плавающий» вместо «Векторный». Это упростит узел, так что он выводит только 2 случайных значения (мин/макс). Побочный эффект (и тот, который нам действительно нужен) заключается в том, что каждая звезда всегда будет масштабироваться единообразно по всем осям. В противном случае каждая звезда, возможно, масштабировалась бы по-разному по осям X и Y — потенциально крутой вид, но не то, к чему мы стремимся.

🔌

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

Мы можем добавить еще один узел для управления общим масштабом. Этот тип операции довольно распространен в узлах геометрии, поэтому хорошо запомнить:

Мы можем умножить значения масштаба, поступающие из узла «Случайное значение», на число, которое уменьшит их все. Для этого мы можем использовать узел «Математика» и установить для него значение «Умножение».

Математические узлы, вероятно, являются наиболее часто используемыми узлами в любом графе узлов геометрии. Загляните в раскрывающийся список, и вы увидите, насколько они универсальны.

Путем настройки случайного минимума/максимума и общей шкалы теперь мы можем добиться лучшего результата.

Наша новая настройка значительно упрощает настройку мин./макс. и общей шкалы.

🎚️

При настройке очень маленьких значений в Blender вы можете удерживать «Shift», чтобы сделать шаг более точным при перемещении значений вверх и вниз. «Ctrl» делает наоборот.

Рандомизация типов звезд

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

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

Дубликаты оригинальной звездной сетки, каждая с уникальной текстурой. Здесь я разложил их, чтобы лучше проиллюстрировать, но обычно лучше оставить их в начале координат (0, 0, 0).

🧠

Более разумным способом обработки нескольких текстур было бы размещение всех различных изображений звезд на одном текстурном листе или «атласе». Затем вы можете просто сместить их UV, чтобы они выглядели по-другому. Преимущество этого заключается в использовании меньшего объема памяти для текстур и меньшем количестве вызовов отрисовки в концентраторах графического процессора или в любом механизме рендеринга в реальном времени.

Ключевым моментом здесь является убедиться, что вы поместили все эти меши со звездами в их собственную коллекцию. (Обратите внимание на коллекцию, обведенную кружком на изображении выше.)

Как и раньше, когда мы перетаскивали звездную сетку на наш график, мы сделаем то же самое, только на этот раз мы перетащим всю коллекцию. На графике создается узел «Информация о коллекции».

Наборы объектов можно перетаскивать в графы узлов геометрии точно так же, как отдельные объекты.

Теперь нам нужно заменить исходный узел звездообразной сетки узлом-коллекцией. Вы заметите, что внезапно каждая звезда была заменена ВСЕМИ звездами. Мы не хотим каждый раз использовать всю коллекцию, поэтому нам нужно включить «Отдельные дочерние элементы» в узле «Информация о коллекции». Наконец, нам нужно включить флажок «Выбрать экземпляр» на узле «Экземпляр на точках».

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

Это не было показано в ролике выше, но теперь вы можете видеть, как каждая звезда получает свой меш из коллекции.

Если вы хотите сделать десятки разных типов — планеты, туманности и т. д. — вам просто нужно добавить их в коллекцию, и ваше небо будет обновляться автоматически!

Завершение (наши UV)

Чтобы завершить все, что мы сделали с графом узлов геометрии, нам нужно сделать пару вещей. Во-первых, нашему графику нужен специализированный узел под названием «Realize Instances» в конце. Это возьмет каждый экземпляр звездной сетки и преобразует его в обычную сетку. Однако (по причинам, по которым я не хотел бы вдаваться в подробности) добавление этого узла приведет к удалению UV-координат со звезд, в результате чего у них не будет текстур.

Узел «Realize Instances» может вызывать проблемы с UV и текстурами. Продолжайте читать, чтобы узнать, как с этим бороться.

Чтобы избежать этой проблемы, есть несколько необычный обходной путь. Мы должны сначала применить модификатор Geometry Nodes. На самом деле это создаст новый набор UV-разверток, но они будут отображаться в другом месте, чем обычные UV-развертки, с которыми вы, возможно, знакомы. На вкладке «Свойства данных объекта» есть раздел «Атрибуты». После применения модификатора у вас будет пара наборов данных внутри «Атрибутов». Выберите тот, который называется « UVMap », затем используйте значок со стрелкой вниз и выберите «Преобразовать атрибут». В следующем всплывающем окне выберите «UV Map» и нажмите «ОК».

Раздел «Атрибуты» является относительно новым для Blender, но именно туда вам нужно перейти, чтобы вернуть текстуры на место.

Как только вы конвертируете данные UVMap, текстуры снова появляются на модели. Вау!

🤔

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

Соединяем все вместе

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

Но вам также может быть проще перейти в режим «Редактировать», установить 3D-курсор в исходную точку, а затем масштабировать все звезды вместе. Это также будет иметь побочный эффект в виде увеличения самих звезд. Но вы можете переключить раскрывающийся список «Transform Pivot Point» на «Individual Origins», а затем масштабировать все грани звезды по отдельности одновременно.

Использование опций Transform Pivot Point в Blender для масштабирования всего неба по сравнению с отдельными звездами.

Наконец, мы можем использовать этот шар из звезд сам по себе (простой фон) или как слой поверх любого выбранного вами фона неба.

Звезды могут работать практически на любом фоне. Регулировка их силы излучения может помочь добиться желаемой яркости.

Идем дальше…

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

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

Если это был ваш первый опыт использования узлов геометрии, поздравляю. Концепции не всегда легко понять сразу, но чем больше вы их используете, тем легче становится. Я все еще изучаю их сам, так что заходите в Hubs Discord, и, возможно, вы могли бы поделиться своими трюками с сообществом по мере того, как ваши навыки улучшаются.

Очень тонко, но звезды мерцают (ультрафиолетовая прокрутка). Что еще более важно, звезды красивые и четкие, а не выглядят размытыми и пикселизированными.

Цифровое картографирование текстуры почвы в полигонах эколеса в Квебеке, Канада

. 2021 23 июня;9:e11685.

doi: 10.7717/peerj.11685.

Электронная коллекция 2021.

Луи Дюшен
¹
, Рок Уимет
¹

принадлежность

• ¹ Управление лесных исследований Министерства лесов, фауны и парков, Квебек, Квебек, Канада.

• PMID:

  34221741

• PMCID:

  PMC8234928

• DOI:

  10.7717/аналог 11685

Бесплатная статья ЧВК

Луи Дюшен и др.

Пир Дж.

2021 .

Бесплатная статья ЧВК

. 2021 23 июня;9:e11685.

doi: 10.7717/peerj.11685.

Электронная коллекция 2021.

Авторы

Луи Дюшен
¹
, Рок Уимет
¹

принадлежность

• ¹ Управление лесных исследований Министерства лесов, фауны и парков, Квебек, Квебек, Канада.

• PMID:

  34221741

• PMCID:

  PMC8234928

• DOI:

  10.7717/аналог 11685

Абстрактный

Текстура сильно влияет на основные функции почвы в лесных экосистемах. В ответ на растущий спрос на информацию о свойствах почвы для моделирования окружающей среды за последнее десятилетие было проведено все больше и больше исследований для оценки пространственной изменчивости свойств почвы в региональном и глобальном масштабах. Эти исследования основаны на сборе и компиляции многочисленных записей почвенных полей и на развитии статистических методов и технологий. Здесь мы использовали алгоритмы машинного обучения случайного леса для моделирования и картирования гранулометрического состава в полигонах эколеса для всей площади управляемых лесов в провинции Квебек, Канада. Мы собрали архивные лабораторные анализы 29570 образцов минеральной почвы (17 901 участок) и набор из 33 ковариат, в том числе 22 переменных, связанных с климатом, пять, связанных с характеристиками почвы, три, связанных с пространственным положением или пространственным контекстом, два, связанных с рельефом и топографией, и одна, связанная с растительностью. После пяти повторений 5-кратной перекрестной проверки результаты показывают, что модели, которые включают две функционально независимые величины относительно гранулометрического состава, объясняют 60%, 34% и 78% дисперсии фракций песка, ила и глины, соответственно, со средним значением. абсолютные погрешности колеблются от 4,0% для илистой фракции до 9.5% для песчаной фракции. Наиболее важными переменными модели являются те, которые наблюдаются в полевых условиях, и те, которые интерпретируются с помощью аэрофотосъемки в отношении характеристик почвы, за которыми следуют параметры высоты и климата. Наши результаты выгодно отличаются от результатов предыдущих исследований картирования текстуры почвы для той же территории, в которых гранулометрический состав был смоделирован в основном из растеризованных климатических и топографических переменных. Карта, которую мы предоставляем, должна отвечать потребностям провинциальных управляющих лесами, поскольку она совместима с картой эколеса, которая составляет основу информации для управления лесами в Квебеке, Канада.

Ключевые слова:

Инвентаризация леса; геостатистика; Машинное обучение; Фотоинтерпретация; Случайный лес; картирование почвы; размер частиц почвы; Образцы почвы; Структура почвы; Пространственные данные.

© 2021 Duchesne and Ouimet.

Заявление о конфликте интересов

Авторы заявляют об отсутствии конкурирующих интересов.

Цифры

Рисунок 1. Лесные подзоны и почвенные провинции…

Рисунок 1. Лесные подзоны и почвенные провинции в Квебеке, Канада.

Карты были созданы с помощью QGIS…

Рисунок 1. Лесные подзоны и почвенные провинции в Квебеке, Канада.

Карты были созданы с помощью программного обеспечения QGIS версии 3.4 (QGIS, 2020). Источники базовой карты: © TerraMetrics, 2021 г., © Google, Esri, 2021 г., HERE, Garmin, © участники OpenStreetMap и сообщество пользователей ГИС.

Рисунок 2. Пространственное распределение минеральных почв…

Рис. 2. Пространственное распределение анализа минерального состава почвы ( n = 29,570) от 3 до

Рисунок 2. Пространственное распределение анализа минерального состава почвы ( n  = 29 570) по 3 провинциальным программам инвентаризации лесов в Квебеке, Канада.

PSP: постоянные пробные площадки; ЭОП: участки экологического наблюдения; SIP: графики индекса сайта. Карта создана с помощью программного обеспечения QGIS версии 3.4 (QGIS, 2020 г.). Источники базовой карты: © TerraMetrics, 2021 г., © Google, Esri, 2021 г., HERE, Garmin, © участники OpenStreetMap и сообщество пользователей ГИС.

Рисунок 3. Наблюдаемые и прогнозируемые значения…

Рисунок 3. Наблюдаемые и прогнозируемые значения ортогональных компонентов V1 и V2 каждого…

Рисунок 3. Наблюдаемые и прогнозируемые значения ортогональных компонентов V1 и V2 гранулометрического состава каждого образца почвы (фракции песка, ила и глины).

Прямая синяя линия соответствует линейной регрессии между наблюдаемыми и прогнозируемыми значениями, а пунктирные линии представляют собой линию 1:1. Значения 0 наблюдаемых V1, выровненные по горизонтали на верхнем графике, соответствуют наблюдениям с идентичным составом песка и ила или почвам, полностью состоящим из песка (100%), а значения наблюдаемых V2 на нижнем графике соответствуют почвам, характеризующимся с 0% глины. Нижние ряды горизонтально выровненных значений V1 (верхний график) соответствуют целочисленным значениям песка песчаных грунтов ( >90%).

Рисунок 4. Наблюдаемый состав почвы (песок,…

Рисунок 4. Наблюдаемый состав почвы (фракции песка, ила и глины) в сравнении с прогнозируемыми значениями, обратно преобразованными…

Рисунок 4. Наблюдаемый состав почвы (фракции песка, ила и глины) по сравнению с прогнозными значениями, обратно преобразованными из прогнозов ILR-преобразования (V1 и V2).

Прямая синяя линия соответствует линейной регрессии между наблюдаемыми и прогнозируемыми значениями, а пунктирные линии представляют собой линию 1:1.

Рисунок 5. Относительные показатели переменной важности…

Рисунок 5. Относительные меры переменной важности в выбранных моделях двух ортогональных…

Рисунок 5. Относительные показатели переменной значимости в выбранных моделях двух ортогональных компонентов (V1: левая панель; V2: правая панель) гранулометрического состава почвы (фракции песка, ила и глины).

Цвет точек указывает на категорию переменной. Показаны только 50 наиболее важных переменных. См. Таблицу 1 для определений ковариат.

Рисунок 6. Вариограммы, иллюстрирующие пространственную зависимость…

Рисунок 6. Вариограммы, иллюстрирующие структуру пространственной зависимости ортогональных составляющих V1 и V2…

Рис. 6. Вариограммы, иллюстрирующие структуру пространственной зависимости ортогональных компонент V1 и V2 наблюдаемого гранулометрического состава почвы горизонта В и невязок модели.

Нижние пунктирные горизонтальные линии обозначают самородки ( y — величина краткосрочной изменчивости данных, связанная с точкой пересечения оси), а верхние линии представляют пороги (общая дисперсия, при которой модель сначала выравнивается). Вертикальные пунктирные линии обозначают диапазон (расстояние, за которым данные больше не коррелируются в пространстве). NSR: отношение самородка к подоконнику.

Рисунок 7. Карта с координатной сеткой (разрешение 15 с)…

Рис. 7. Карта с координатной сеткой (разрешение 15 с) гранулометрического состава почвы (диагностический горизонт В) в…

Рисунок 7. Карта с координатной сеткой (разрешение 15 с) гранулометрического состава почвы (диагностический горизонт B) в полигонах эколеса управляемого леса провинции Квебек, Канада.

На карту нанесены только продуктивные лесные угодья, характеризующиеся минеральными почвами. Были исключены сельскохозяйственные и непродуктивные лесные угодья, органические почвы, антропогенные инфраструктуры и акватории. Добавлен эффект отмывки на основе цифровой модели рельефа с разрешением 1 км. Карта создана с помощью программного обеспечения QGIS версии 3.4 (QGIS, 2020 г.). Источник базовой карты: © TerraMetrics, 2021 г., © Google, 2021 г.

Рисунок 8. Карты гранулометрического состава почвы…

Рисунок 8. Карты гранулометрического состава почвы при двух уровнях масштабирования, для региона на…

Рисунок 8. Карты текстурного состава почвы при двух уровнях масштабирования для региона на южной окраине почвенной провинции Абитиби и низменности залива Джеймс.

На карту нанесены только продуктивные лесные угодья, характеризующиеся минеральными почвами. Были исключены сельскохозяйственные и непродуктивные лесные угодья, органические почвы, антропогенные инфраструктуры и акватории. Карты были созданы с помощью программного обеспечения QGIS версии 3.4 (QGIS, 2020). Источник базовой карты: © TerraMetrics, 2021 г., © Google, 2021 г.

Рисунок 9. Карта с координатной сеткой (разрешение 15 с)…

Рисунок 9. Карта с координатной сеткой (разрешение 15 с) 95% интервалов прогнозирования V1…

Рисунок 9. Карта с координатной сеткой (разрешение 15 с) 95% интервалов прогнозирования ортогональных компонентов V1 и V2 текстурного состава почвы (горизонт B) в полигонах эколеса провинции Квебек.

На карту нанесены только продуктивные лесные угодья, характеризующиеся минеральными почвами. Были исключены сельскохозяйственные и непродуктивные лесные угодья, органические почвы, антропогенные инфраструктуры и акватории. Карты были созданы с помощью программного обеспечения QGIS версии 3.4 (QGIS, 2020). Источник базовой карты: © TerraMetrics, 2021 г., © Google, 2021 г.

См. это изображение и информацию об авторских правах в PMC

Похожие статьи

• Картирование свойств почвы с высоким разрешением с использованием переменных дистанционного зондирования в юго-западной части Буркина-Фасо: сравнение моделей машинного обучения и множественной линейной регрессии.

  Форкуор Г., Хоункпатин О.К., Велп Г., Тиль М.

  Форкуор Г. и соавт.
  ПЛОС Один. 2017 23 января; 12 (1): e0170478. doi: 10.1371/journal.pone.0170478. Электронная коллекция 2017.
  ПЛОС Один. 2017.

  PMID: 28114334
  Бесплатная статья ЧВК.

• Уязвимость тропических лесных экосистем и лесозависимых сообществ к засухе.

  Vogt DJ, Vogt KA, Gmur SJ, Scullion JJ, Suntana AS, Daryanto S, Sigurðardottir R.

  Фогт Д.Дж. и др.
  Окружающая среда Рез. 2016 Январь; 144 (Pt B): 27-38. doi: 10.1016/j.envres.2015.10.022. Epub 2015 6 ноября.
  Окружающая среда Рез. 2016.

  PMID: 26552634

• База данных профилей почв канадских горных лесов и запасов углерода.

  Шоу С. , Хилгер А., Филиатро М., Курц В.

  Шоу С. и др.
  Экология. 2018 Апрель; 99 (4): 989. doi: 10.1002/ecy.2159. Epub 2018 12 марта.
  Экология. 2018.

  PMID: 29364515

• Крупномасштабное цифровое картирование общего содержания азота в верхнем слое почвы с использованием моделей машинного обучения и связанной карты неопределенности.

  Парсаи Ф., Фаррохян Фирузи А., Мусави С.Р., Рахмани А., Седри М.Х., Хомаи М.

  Парсаи Ф. и др.
  Оценка окружающей среды. 2021 5 марта; 193 (4): 162. doi: 10.1007/s10661-021-08947-w.
  Оценка окружающей среды. 2021.

  PMID: 33665671

• Анализ пространственной изменчивости текстуры почвы в тропическом нагорье: случай водораздела Джема, северо-западное нагорье Эфиопии.

  Тайе М., Симане Б., Селссси Ю.Г., Заитчик Б., Сетегн С.

  Тайе М. и др.
  Общественное здравоохранение Int J Environ Res. 2018 1 сентября; 15 (9): 1903. doi: 10.3390/ijerph25091903.
  Общественное здравоохранение Int J Environ Res. 2018.

  PMID: 30200466
  Бесплатная статья ЧВК.

Посмотреть все похожие статьи

Рекомендации

1. 1. Айдоо Э.Н., Мюллер У., Гувертс П., Хайндес Г.А. Оценка геостатистических оценок и их применимость для характеристики пространственных закономерностей уловов любительского рыболовства. Исследования рыболовства. 2015;168:20–32. doi: 10.1016/j.fishres.2015.03.013.

      —

      DOI

      —

      ЧВК

      —

      пабмед

2. 1. Arrouays D, Grundy MG, Hartemink AE, Hempel JW, Heuvelink GBM, Hong SY, Lagacherie P, Lelyk G, McBratney AB, McKenzie NJ, Mendonca-Santos M. d. Л., Минасны Б., Монтанарелла Л., Одех И.О.А., Санчес П.А., Томпсон Дж.А., Чжан Г.Л. Глобальная карта почв. На пути к глобальной сетке свойств почвы с высоким разрешением. Успехи в агрономии. 2014; 125:93–134. doi: 10.1016/B978-0-12-800137-0.00003-0.

      —

      DOI

3. 1. Барнс Э.М., Бейкер М.Г. Мультиспектральные данные для картирования гранулометрического состава почвы: возможности и ограничения. Прикладная инженерия в сельском хозяйстве. 2000; 16: 731–741. дои: 10.13031/2013.5370.

      —

      DOI

4. 1. Бартоломеус Х.