Как сделать тени в unity3d
Shadows
Unity’s lights can cast Shadows from an object onto other parts of itself or onto other nearby objects. Shadows add a degree of depth and realism to a scene since they bring out the scale and position of objects that can otherwise look “flat”.
Scene with objects casting shadows
How Do Shadows Work?
Consider the simplest case of a scene with a single light source. Light rays travel in straight lines from that source and may eventually hit objects in the scene. Once a ray has hit an object, it can’t travel any further to illuminate anything else (ie, it “bounces” off the first object and doesn’t pass through). The shadows cast by the object are simply the areas that are not illuminated because the light couldn’t reach them.
Another way to look at this is to imagine a camera at the same position as the light. The areas of the scene that are in shadow are precisely those areas that the camera can’t see.
A “light’s eye view” of the same scene
In fact, this is exactly how Unity determines the positions of shadows from a light. The light uses the same principle as a camera to “render” the scene internally from its point of view. A depth buffer system, as used by scene cameras, keeps track of the surfaces that are closest to the light; surfaces in a direct line of sight receive illumination but all the others are in shadow. The depth map in this case is known as a Shadow Map (you may find the Wikipedia Page on shadow mapping useful for further information).
Enabling Shadows
You can enable shadows for an individual light with the Shadow Type property in the inspector.
The Hard Shadows setting produces shadows with a sharp edge. Hard shadows seldom occur in everyday life (unless you are an astronaut) but they involve less processing overhead than the more realistic Soft Shadows and are acceptable for many purposes. Also, soft shadows tend to reduce the “blocky” aliasing effect from the shadow map. The Strength setting determines how dark the shadows are; in general, some light will be scattered by the atmosphere and reflected off other objects, so you usually don’t want shadows to be set to maximum strength. The Resolution property sets the rendering resolution for the shadow map “camera” mentioned above. If you find your shadows have very visible edges then you might want to increase this value. The near plane property allows you to choose the value for the near plane when rendering shadows. Any objects closer than this distance to the light will not cast any shadows.
Each Mesh Renderer in the scene also has properties called Cast Shadows and Receive Shadows which must be enabled as appropriate.
Cast Shadows has simple On and Off options to enable or disable shadow casting for the mesh. There is also a Two Sided option to allow shadows to be cast by either side of the surface (ie, backface culling is ignored for shadow casting purposes) while Shadows Only allows shadows to be cast by an otherwise invisible object.
Shadow Mapping and the Bias Property
The shadows for a given light are determined during the final scene rendering. When the scene is rendered to the main view camera, each pixel position in the view is transformed into the coordinate system of the light. The distance of a pixel from the light is then compared to the corresponding pixel in the shadow map. If the pixel is more distant than the shadow map pixel, then it is presumably obscured from the light by another object and it will get no illumination.
Correct shadowing
A surface directly illuminated by a light can sometimes appear to be partly in shadow. This is because pixels that should be exactly at the distance specified in the shadow map will sometimes be deemed farther away (a consequence of using a low resolution image for the shadow map; or using shadow filtering). The result is arbitrary patterns of pixels in shadow when they should really be lit, giving a visual effect known as “shadow acne”.
Shadow acne in the form of false self-shadowing artifacts
To prevent shadow acne, a bias value can be added to the distance in the shadow map to ensure that pixels on the borderline will definitely pass the comparison as they should; or while rendering into the shadow map, objects can be inset a bit along their normals. These values are set by the Bias and Normal Bias properties in the light’s inspector when it has shadows enabled.
Do not set the Bias value too high though, however, since areas of a shadow near to the object casting it can then sometimes be falsely illuminated. This effect is known as “Peter Panning” (i.e. the disconnected shadow makes the object look as if it is flying above the ground, like Peter Pan).
Too high a Bias value makes the shadow appear “disconnected” from the object
Likewise, setting the Normal Bias value too high will make the shadow appear too narrow for the object:
Too high a Normal Bias value makes the shadow shape too narrow
The bias values for a light may need a bit of tweaking to make sure that neither shadow acne nor Peter Panning occur. It is generally easier to gauge the right value by eye rather than attempt to calculate it.
Как я делал 2D тени в Unity
Что первое приходит в голову разработчику инди-игры, когда он сталкивается с необходимостью добавления фичи, представления о реализации которой толком не имеет? Разумеется, он идёт искать следы тех, кто уже прошёл этот путь и удосужился записать свой опыт. Так поступил и я некоторое время назад, приступая к созданию теней в своей игре. Найти нужную информацию — в виде статей, уроков и гайдов — не составило особого труда. Однако, к моему удивлению, я обнаружил, что ни одно описанное решение мне попросту не подходит. Поэтому, реализовав своё собственное, я решил поведать о нём миру.
Стоит предупредить заранее, что данный текст не претендует на бытие неким ультимативным гайдом или мастер-классом. Использованный мною метод может быть не универсальным, далеко не самым эффективным и не закрывающим задачу создания двухмерных теней в полной мере. Это скорее история о том, к каким ухищрениям пришлось прибегнуть неопытному разработчику в моём лице для достижения удовлетворяющего его требованиям результата.
Сам результат перед вами:
А подробности пути к его достижению ждут вас под катом.
Постановка задачи
Итак, на момент принятия решения о добавлении в игру теней, у меня имелось:
Для всего этого необходимы были самые простейшие тени, повторяющие контуры объекта, и отбрасываемые от единственного фиксированного источника освещения.
При этом следовало трепетно отнестись к производительности. Ввиду специфики жанра и особенностей его реализации, большинство объектов, отбрасывающих тени, в каждый момент времени находятся непосредственно на экране. А их общее число может составлять больше сотни, если говорить об игровых сущностях, и пару тысяч, если говорить об отдельных спрайтах.
Реализация
Собственно, основная загвоздка оказалась в том, что Dwarfinator, грубо говоря — 2,5D игра. Подавляющее большинство объектов существует в двухмерном пространстве с осями X и Y, а ось Z используется крайне редко. Визуально же, и отчасти, геймплейно, ось Y используется для отображения как высоты, так и глубины, разделяясь таки образом на виртуальные оси Y и Z. Использовать в такой ситуации для создания теней стандартные средства Unity не представлялось возможным.
Но на самом деле, честного освещения мне и не требовалось, достаточно было иметь возможность вручную создавать тень для каждого объекта. Поэтому самое простое, что мне пришло в голову — просто разместить позади каждой сущности её копию, повёрнутую в трёхмерном пространстве так, чтобы имитировать нахождение на поверхности локации. Всем спрайтам такой псевдотени задавался чёрный цвет, при этом сохранялась иерархическая структура хозяина тени, что позволяло синхронно с хозяином анимировать её таким же аниматором.
Выглядела такая синхронная анимация примерно так:
Однако тени требовалась прозрачность. Самым простым решением было задать её каждому спрайту тени. Но такая реализация выглядела неудовлетворительно — спрайты накладывались друг на друга, образуя в месте наложения менее прозрачные области.
Стало очевидно, что прозрачность нужно накладывать на тень как на цельный объект. Первым экспериментом на эту тему стало навешивание на тень камеры, отрисовывающей эту тень в RenderTexture, которая потом уже использовалась в качестве материала прикреплённым к родителю тени Plane. Ему уже можно было без проблем задавать прозрачность. Сами же тени находились за пределами кадра, чтобы избежать наложения друг на друга областей захвата камер. Подход работал, но оказалось, что уже пара десятков теней вызывает серьёзные проблемы с производительностью, преимущественно, из-за числа находящихся на сцене камер. Кроме того, ряд анимаций предполагал значительное перемещение отдельных спрайтов моба в рамках его корневого объекта, из-за чего в поле зрения камеры должна была находиться область, значительно превышающая размер реального изображения в отдельный момент времени.
Решение нашлось быстро — если нельзя отрисовывать каждую тень отдельной камерой — почему бы не отрисовывать одной камерой все тени? Всё, что нужно было сделать — отвести под тени отдельную область сцены, несколько выше поля зрения основной камеры, направить на эту область дополнительную камеру, и отображать её вывод между локацией и остальными сущностями.
Ниже можно наблюдать пример вывода этой камеры:
Производительность от такой реализации страдала гораздо меньше, так что решение было сочтено рабочим и применено ко всем мобам, статичным объектам и снарядам. Далее последовала очередь спрайта локации. Использовать один спрайт на все объекты, как это было реализовано ранее, оказалось невозможным. Использование копии объекта в качестве его же тени хорошо работает только до тех пор, пока объект полностью плоский. Уже при создании теней для мобов было заметно, что разнесённые по третьей координате точки соприкосновения с поверхностью нарушают корректность тени относительно этих точек.
Следующий скриншот демонстрирует пример такого нарушения. За точку соприкосновения с поверхностью принята пятка моба, но тени ступней уже выходят за рамки самих ступней.
И если в случае с ногами огра ещё можно немного изменить положение тени и замаскировать проблему, то для нескольких десятков стволов деревьев на это нет и шанса. Все объекты локации, которые должны были отбрасывать тень, следовало сделать отдельными GameObject. Именно так я и поступил, разместив на префабе локации экземпляры соответствующих разрушаемых объектов и отключив им неиспользуемые в таком положении скрипты. Заодно благодаря этому стало возможным включить их в общую сортировку объектов сцены, и улетающие за пределы локации снаряды больше не отрисовывались строго поверх всех объектов, а пролетали между ними. К тому же стало возможным сделать сами объекты анимированными.
Но тут меня поджидала новая неприятность. С тенями и десятками новых объектов максимальное количество одновременно находящихся на сцене GameObject, а вместе с ними и компонентов Animator и SpriteRenderer, возросло более чем в два раза. Когда я выпускал на локацию всю волну мобов, что составляло порядка 150 штук, Profiler укоризненно показывал мне примерно 40мс, уходивших только на рендеринг и анимацию, а частота кадров в целом колебалась в районе 10. Я отчаянно оптимизировал собственные скрипты, борясь за каждую миллисекунду, но этого было недостаточно.
В поисках дополнительных средств оптимизации, я набрёл на просторах документации и гайдов на динамический батчинг.
Frame Debugger показывал, что батчатся у меня, в лучшем случае, детали каждого объекта или моба по отдельности. Создав для первых и для вторых по атласу спрайтов, я добился батчинга теней до всего нескольких вызовов отрисовки, но владельцы этих теней батчиться между собой упорно отказывались.
Эксперименты на отдельной сцене показали, что динамический батчинг ломается при наличии у объектов компонента SortingGroup, который я использовал для сортировки отображения сущностей на экране. Обойтись без него, в теории, было возможно, однако выставление значений сортировки для каждого спрайта и системы частиц в объекте по отдельности могло выйти ещё дороже, чем отсутствие батчинга.
Но кое-что мне не давало покоя. Объект-тень, являясь в реальной сцене потомком объекта-хозяина, технически входил в тот же самый SortingGroup, однако с динамическим батчингом объектов-теней проблем не возникало. Единственное отличие было в том, что объекты-хозяева отрисовывались основной камерой сразу на экран, а объекты-тени — сначала в RenderTexture.
В этом и оказалась загвоздка. Что именно является причиной такого поведения — интернету неведомо, но при рендеринге камерой изображения в RenderTexture, SortingGroup больше не ломали батчинг. Решение казалось весьма странным, нелогичным, и вообще самым что ни на есть костылём. Но реализовав рендеринг сущностей тем же методом, что и рендеринг теней, и получив таким образом помимо слоя теней, ещё и слой сущностей, я добился уже вполне приемлемых значений производительности.
Скриншот ниже демонстрирует пример отрисовки слоя сущностей.
Итого в общем случае рендеринг некоторой сущности в координате Y выглядит так:
На скриншоте ниже камера редактора переведена в трёхмерный режим для демонстрации расположения слоёв относительно друг друга.
Нюансы
Но как выяснилось в процессе тиражирования решения на другие сущности, общий случай не покрывал все возможные сценарии. Например, существовали сущности, находящиеся на некоторой высоте относительно поверхности, в частности, снаряды и некоторые персонажи катсцен. Кроме того, снаряды ещё и имели свойство поворачиваться в зависимости от направления своего движения по экрану, из-за чего помимо выставления им точки пересечения объекта и его тени, понадобилось выделять вращаемую часть в отдельный дочерний объект, править логику вращения снаряда и их анимации.
Следующий скриншот показывает пример вращения снарядов и их теней.
Летающие персонажи же, как и запланированные летающие мобы, могут вдобавок перемещаться в рамках своей виртуальной Y координаты, что потребовало создания механизма расчёта положения тени из положения её хозяина на виртуальной оси Y.
На гифке ниже изображён пример перемещения объекта по высоте.
Другим выбивающимся из общей концепции случаем оказался танк. В отличие от всех остальных сущностей, танк имеет весьма существенный размер по виртуальной оси Z, а общая реализация теней, как уже упоминалось, требует, чтоб объект был практически плоским. Самым простым способом это обойти были вручную нарисованные формы теней для отдельных деталей танка, благо поместить на слой теней можно было что угодно.
Для корректного построения рисованных вручную теней мне пришлось на основе скриншота уже существующей тени собрать конструкцию из линий, которую можно наблюдать на скриншоте ниже.
Если отмасштабировать и разместить эту конструкцию таким образом, что верхняя часть будет находиться в некоторой точке родительского объекта, а нижняя — в точке его соприкосновения с поверхностью, правый угол конструкции покажет место, в котором должна находиться соответствующая точка тени. Спроецировав таким образом несколько ключевых точек, не составляет особого труда построить по ним всю тень.
Помимо этого, отдельные детали танка могли иметь разную высоту крепления дочерних деталей, что, как и в случае с летающими персонажами и мобами, требовало подстройки положения тени каждой конкретной детали.
На скриншоте ниже показан танк, его тень в сборе и она же в виде отдельных частей.
Отдельной болью оказались тени стен. На момент начала работы над тенями стены имели ту же природу, что и детали танка — один объект из нескольких десятков отдельных спрайтов. Однако при этом у стен имелось по нескольку состояний, управляемых аниматором.
Крепко задумавшись, что с ними делать, я пришёл к выводу, что концепцию стен необходимо менять. В результате стены были разделены на секции, каждая из которых имеет собственный набор состояний, собственный аниматор и собственную тень. Это позволило использовать для параллельных оси X секций такой же подход к созданию теней, как и с мобами, а для тех секций, что не подходили под это правило уже придумывать что-то своё. В отдельных случаях пришлось создавать для тени секции собственный аниматор и вручную задавать положение спрайтов.
Например, в случае секции, отображённой на скриншоте ниже, тень сделана путём применения искажения для каждого отдельного бревна вместо всей секции целиком.
Работа с освещением в Unity — теория и практика
В течение последних пары лет мне приходилось много работать с “лайтмаппингом” как по работе, так и на своём собственном инди-проекте. Когда у вашей команды мало производственных ресурсов и вы не можете выделить много времени на создание уникальной графики для игровых локаций, освещение становится одним из ключевых факторов, помогающих оживить и разнообразить картинку.
Теория освещения
Отражённый свет
Давайте определимся с терминологией. Освещение в компьютерной графике делится, условно говоря, на две категории:
Global Illumination (GI) представляет из себя наиболее “честный” способ симуляции отражённого света. Из источника света вылетают фотоны — частички, несущие информацию о цвете и яркости света. Ударяясь о какую-либо поверхность, они освещают её, но теряют часть энергии, вследствие чего их цвет и яркость изменяются. Затем фотоны отскакивают и ударяются о следующую поверхность, повторно теряя часть энергии. Так происходит несколько раз в зависимости от настроек рендерера.
Final Gather (FG) раскидывает по сцене точки, — final gather points, — из которых в разные стороны вылетают лучи. После столкновения с какой-либо поверхностью, лучи возвращают в родительскую точку информацию о цвете и его яркости. Представьте себе такую картину: вечер, солнце почти зашло за горизонт; становится темно, но небольшая часть комнаты ещё залита оранжевым закатным светом. Находящаяся на полу final gather point отправляет в разные стороны несколько лучей, некоторые из них дотягиваются до освещённой части комнаты и с этой информацией возвращаются в исходную точку, тем самым слегка освещая пол «отражённым» оранжевым светом. Это не такой “честный” способ, как GI, но он производит хороший результат, и им часто пользуются, чтобы заполнять сцены красивым мягким освещением.
Для следующей картинки я выкрутил параметры отражённого света до безумных значений, таким образом вы можете наглядно увидеть, как частички света отскакивают от объектов.
Ambient Occlusion
Кроме отражённого света, нам интересен так называемый Ambient Occlusion (AO). Это эффект затенения в углах, трещинах, узких проёмах. Представьте, что луч света залетает в угол комнаты, он несколько раз отражается от обеих стен, постепенно затухая. Чем дальше в угол, тем меньше света туда доходит.
Как правило, Ambient Occlusion используется, чтобы художественно подчеркнуть эффект затенения, — в реальности лучи света не теряют энергию столь быстро, чтобы в углах комнаты сгущалась такая же тьма, как показывают нам в играх. Если вы рендерите физически корректное освещение, ваш движок сам высчитывает скорость потери энергии лучом света, и вам не нужно отдельно рендерить карту (текстуру) Ambient Occlusion. Но вы можете это сделать, если потребуется для реализации художественного замысла.
Текстурные атласы
Следующим термином, который вам следует следует знать, является текстурный атлас. Грубо говоря, это одна большая текстура, в которой содержатся несколько маленьких текстурок. Чаще всего текстурные атласы создаются для экономии вычислительных ресурсов. Приведу крайне упрощённый пример, — спецы, спрячьте факелы и вилы! Пусть у вас в игре есть таверна, в которой 20 деревянных предметов (столы, стулья, ложки. ), у каждого своя текстура. В итоге CPU будет 20 раз обращаться к GPU, требуя отрендерить каждый объект по отдельности. Если мы назначим всем деревянным объектам один материал, обращающийся к одному текстурному атласу, в который зашиты все 20 текстур, то GPU сможет отрендерить 20 объектов за один вызов (он же — draw call, в конце статьи предоставлю интересные ссылки по этой теме).
В случае с “лайтмаппингом”, для каждого объекта создаётся дополнительная маленькая текстурка, в которой “запекается” информация об освещении. Затем много-много маленьких текстурок разных объектов размещаются в крупных текстурных атласах. Как и в случае с деревянной мебелью, мы также получаем прирост производительности.
Работа с Unity
Общая информация
Но вернёмся к “лайтмаппингу” в самом Unity. Прежде всего запаситесь терпением и, по возможности, мощным компьютером. Процесс рендера имеет свойство полностью занимать процессор и оперативную память, поэтому я включаю его перед тем, как ухожу на работу или иду спать. Таким образом, я возвращаюсь к компьютеру как раз в тот момент, когда рендер уже завершён.
Забегая вперёд, предупрежу, что Unity кэширует промежуточные результаты вычислений освещения. Если вы увидите, что на системном диске у вас пропало 10 гигабайт места — это оно. Чтобы настроить кэш надо зайти в: Edit — Preferences — GI Cache. Здесь вы можете указать, куда он сохраняется и его максимальный размер. Можно убрать компрессию, “весить” будет больше, но работать пошустрее. Тут же вы можете почистить кэш, но имейте ввиду, что если у вас открыта сцена с готовым “лайтмапом”, то он тоже будет удалён, будьте внимательны.
В Unity доступно 5 типов источников света:
Параметры источников света
Хочу обратить внимание на насколько ключевых настроек источников света (доступные настройки различаются в зависимости от типа источника света):
Настройка освещения сцены
Окно настроек освещения сцены вызывается через Window — Lighting, и состоит из трёх вкладок: Object, Scene, Lightmaps. Для запуска рендера освещения используется кнопка Build в самом низу окна. Там же есть галочка Auto, которая автоматически запускает рендер каждый раз, когда вы вносите изменения в сцену; используйте её, если у вас мощный компьютер. Ещё ниже находится информация о количестве и размере “лайтмапов”, появится по завершению процесса “лайтмаппинга”.
Раздел — Object
В Object отображаются настройки конкретного объекта. Если вы выделите элемент окружения на вашей сцене, то здесь увидите ряд настроек и параметров. При условии, что объект является статичным, будет стоять галочка на чекбоксе Lightmap Static. Чаще всего вы будете использовать здесь поле Scale in Lightmap. Как я говорил ранее, для каждого объекта освещение “запекается” в отдельную маленькую текстурку, которая потом размещается в крупном “лайтмап”-атласе. Параметром Scale in Lightmap вы можете регулировать, сколько места будет занимать эта текстурка. Разумеется, чем меньше места ей выделяется, тем хуже будет качество “запечённого” в неё освещения. По умолчанию здесь стоит “1”, но если вы знаете, что объект будет редко попадать в поле зрения или он расположен далеко на фоне, вы можете смело уменьшить этот параметр вплоть до 0.1 или даже меньше.
Раздел — Scene
В Scene расположены ключевые настройки рендера освещения. Я рассказываю основы работы со светом, а также делюсь опытом “лайтмаппинга” конкретно под мобильные платформы, поэтому умышленно пропускаю такие вещи, как realtime GI или использование HDR-текстуры в качестве источника света.
В Ambient Source вы настраиваете заполняющий источник света Ambient Light, который я уже упоминал. Вам предлагается выбрать между небом-текстурой, небом из единственного цвета, а также созданным на основе цветового градиента небом. Я предпочитаю выбирать Gradient. Он позволяет настроить три цвета — купол неба, экватор и землю, что создаст для вашей сцены достаточно сложный и интересный заполняющий свет. Ambient Intensity указывает яркость этого света. В зависимости от художественного замысла, вы можете иметь даже очень светлую сцену, освещённую посредством одного Ambient Light.
Во вкладке Baked GI находятся основные настройки качества освещения, как прямого, так и отражённого, включая и GI, и FG.
Прежде чем углубимся в эти настройки, хочу дать один совет. Всегда имейте ввиду, что размещая на сцене источники света, настраивая тени и Ambient Light, после рендера “лайтмапа” вы получите совершенно иную картинку, только отдалённо напоминающую то, что вы делали. Поэтому я рекомендую работать итерациями: вы выставляете минимальное качество освещения, чтобы рендер происходил быстро, смотрите на результат рендера, после чего вносите правки и запускаете повторный рендер. Когда вы более-менее довольны результатом, можно повысить качество рендера и включить Final Gather. Это займёт длительное время, поэтому есть смысл включать такой рендер перед тем, как вы отходите от компьютера на сравнительно долгий отрезок времени.
Настройки во вкладке Baked GI оперируют такой единицей, как texel. Если говорить упрощённо, тексель — это пиксель, но не на экране, а в текстурном пространстве трёхмерной модели. Но не забивайте голову, — трудно сказать, как Unity оперирует текселями и как они зависят от масштаба объектов, поэтому просто-напросто двигайтесь эксперементальным путём. Например, для своей мобильной RPG я делаю финальный рандер с Baked Resolution выставленным в 25.
Тексель (сокращение от англ. Texture element) — минимальная единица текстуры трёхмерного объекта. Пиксель текстуры.
Проще всего объяснить значение термина «тексель» на примере трёхмерных игр. Если подойти вплотную к стене в какой-нибудь старой 3D-игре — (Wolfenstein или Duke Nukem), то можно наблюдать, как текстура стены распадается на однотонные квадраты, которые увеличиваются при приближении и собираются обратно в осмысленный рисунок при отдалении. Эти квадраты и называются текселями, и чем крупнее исходный рисунок текстуры, тем меньше становятся тексели. Для идеального отображения текстуры количество текселей должно совпадать с количеством пикселей на мониторе, но практически все движки разрешают зрителю приблизиться к стене ближе чем того разрешает детальность.
Ниже я расскажу про каждый параметр отдельно, но перед этим вам нужно знать ещё кое-что. Если вы запустите в Unity рендер освещения, то справа снизу будет написано, чем именно движок занят в текущий момент. В самом конце процесса рендера там будет написано Compositing.
Дело в том, что “лайтмап” генерируется послойно. Во время рендера создаются несколько отдельных текстур. Мне неизвестно, какие именно карты делает Unity, но среди них есть либо все, либо часть из списка: Diffuse (прямой свет), GI (Global Illumination), FG (Final Gather), AO (Ambient Occlusion) и другие. После этого движок берёт эти карты и сливает друг с другом. Например, в основе может лежать слой Diffuse, над ним кладётся слой FG в режиме смешивания Lighten (прямо как в Photoshop’е), а повыше кладётся слой AO в режиме Multiply… В итоге эти слои сливаются в одну картинку и на выходе получается финальный “лайтмап”.
Вкладка — Baked GI
Вкладка — General GI
Давайте пройдёмся по интересующим нас настройкам во вкладке General GI:
Вкладка — Fog
И, наконец, туман! Fog, то бишь. К рендеру освещения он не имеет никакого отношения, может включаться и выключаться в любое время. Тут всё предельно просто, поэтому берите и экспериментируйте. Скажу лишь, что туман является крайне мощным художественным средством. Вы можете радикально изменять атмосферу сцены посредством тумана, благодаря ему солнечная сцена станет ярче, мрачная — мрачнее.
Кроме того, туман может использоваться как инструмент повышения производительности. Например, вы хотите вдалеке выключить у всех объектов текстуры и скрыть их за туманом. В более старых версиях World of Warcraft, если вы играли, вы не могли не заметить, какой густой там был туман.
Раздел — Lightmaps
Третьим разделом является Lightmaps, где будут расположены отрендеренные “лайтмапы”. Причем если атласов много, в верхней части вкладки вы не сможете увидеть все атласы, скролл в том окошке неактивен. Поэтому смотрим в нижнее и прокручиваем колесиком мышки.
Здесь нам важно увидеть насколько заполнен последний, самый нижний “лайтмап”-атлас. Если он почти пуст, то либо увеличиваем качество “лайтмапа”, чтобы заполнить весь атлас, либо уменьшаем, чтобы атлас оказался пустым и был удален. На картинке ниже изображены два хорошо заполненных атласа, а один — постольку-поскольку.
“Лайтмапы” хранятся в файлах EXR с глубиной в 32 бита.
Light Probes
Ещё я обещал рассказать про Light Probes. Они представляют из себя небольшие сферы, вбирающие в себя информацию об освещении окружающего пространства. Когда таких сфер много, они создают своебразную карту освещённости вашего уровня или локации. Затем они используются для освещения динамических объектов, в которые не “запекается” свет.
Чтобы лучше понять их смысл, дам пример. На вашей сцене находится один Point Light, у которого стоят настройки Baked, то есть он используется для “запечения” света. Вы не делаете его Real-time, потому что это дорого в плане производительности, причём многие мобильные устройства вообще не поддерживают такой источник света. Далее вы “лайтмапите” сцену и видите, что ваш Point Light освещает окружение. Но если вы возьмёте монстра и поставите рядом с источником света, он останется тёмным, потому что принадлежит к классу динамических объектов, а ваш Point Light влияет только на статические.
Теперь вы расставляете вокруг источника света сетку из Light Probes, снова запекаете освещение. И теперь ваш монстр может ходить вокруг Point Light’а и освещаться им! Это крайне эффективный и недорогой способ имитации освещения. Чтобы добавить “пробы” на сцену, заходите в Game Object — Light — Light Probe Group. На сцене появится кубик из четырёх сфер. Для выбора отдельных сфер, используйте ctrl + click. В Inspector появятся несколько кнопок, позволяющие добавлять или удалять сферы. Вы также можете использовать комбинацию ctrl + D для дублирования сфер.
Расставляйте Light Probes аккуратно, размещайте их там, где вы хотите, чтобы они вбирали в себя информацию об освещении, чтобы потом передавать её динамическим объектам. Во избежание графических артефактов и мерцающего света, следите за тем, чтобы Light Probes образовывали ровную, красивую сетку.
Ниже скриншот корректно выставленной сетки. Если приглядеться, можно заметить, что Light Probes выставлены не в случайном порядке, а окружают источники света, стремясь эффективно поймать переход от света к тени и обратно.
Заключение
Напоследок хочу дать совет по созданию моделей окружения под “лайтмаппинг”. Создавая контент для игры, я знал, с какой стороны будет смотреть игровая камера, поэтому ради сомнительной оптимизации удалял задние стенки некоторых объектов. В то время у меня был опыт рендера “лайтмапов”, но только в Maya, а не в Unity. Выяснилось, что при рендере освещения в Unity возле объектов, имеющих дыры, то есть удалённые полигоны, появляются жесткие, хорошо заметные артефакты. Имейте ввиду.