что такое фростом в unity
У Unity всё плохо
На просторах интернета, и в частности хабра, очень трудно встретить статьи с критикой игрового движка Unity. Я решил это исправить, и приготовил вам текст о переходе на DOTS, насилию над C#, знаменитых UI пакетах, MonoBehaviour, универсальности и о многом другом.
Статья не требует от вас знаний о создании игр на Unity, я ее писал с учетом того, что ее будет читать обычный программист, который сравнивает плюсы и минусы разных движков, чтоб выбрать подходящий для своего проекта. В конце концов, может вам будет просто интересно узнать, что же это за движок такой, для которого курсы рекламируются на каждом шагу.
В данный момент Unity активно переходит на новый стек технологий под названием DOTS. Транзит сопровождается лозунгом «Производительность по умолчанию» и идеей того, что С# может быть таким же быстрым как C++ у UnrealEngine и других движков. Главные фронтмены данного действа это Entities, Jobs и Burst.
Теория
Если вы уже знаете, что из себя представляет пакет DOTS, тогда можете смело переходить к пункту Имплементация.
Entities представляет из себя реализацию популярного в игровой индустрии паттерна ECS. ECS это паттерн, где код делится на сущности к которым добавляются компоненты с данными, состоянием компонентов у сущностей управляют системы, которые эффективно перебирают сущности с нужными им компонентами и изменяют данные компонентов по надобности.
Реализаций ECS есть великое множество, но в основном, используют следующие способы оптимизации перебора сущностей:
Хранение компонентов эффективно в памяти в соответствии с архетипом существа к которому они привязаны. Архетип это уникальное сочетание компонентов у существа. В случае Unity, компоненты хранятся в чанках по 16кб в соответствии с архетипом. Выходит, что чанки с компонентами хранятся друг за другом в памяти.
Распараллеливание обработки существ системой. Тут всё очевидно, двигать 50 тысяч снарядов в каком-то шутере быстрее в 32х потоках одновременно. От программиста не требуется особых телодвижений для управления многопоточностью, потенциально ECS может эффективно управлять потоками самостоятельно. В Unity роль управления потоками делегирована фреймворку Jobs.
Такой паттерн хорошо подходит сложным играм, в которых есть очень много сущностей которые надо очень часто перебирать (к примеру ММО). Вдобавок, ECS управляет зависимостями, позволяя игре становиться все больше и больше без последствий.Но есть и обратная сторона медали, ECS плохо подходит играм, в которых мало сущностей и их не надо часто перебирать (например 99% мобильного рынка).
Jobs это реализация безопасной мультипоточности путем создания экземпляра «работы». Работу можно запланировать, получить ее обработчик и выполнить ее. Также работу можно запланировать после другой работы, или вместе с другими работами. Таким образом создаются целые цепи последовательных задач. Сами задачи выполняются сразу в нескольких потоках. Например, вам надо умножить все числа массива А с вместительностью в 100 элементов и положить их в массив B. Это можно сделать в десяти потоках, в каждом из них задача будет обрабатывать по 10 элементов.
Burst это компилятор, который транслирует IL байткод в оптимизированный нативный код с помощью LLVM. В основном, используется для компиляции работ с Jobs.
Имплементация
Теперь, когда вы понимаете что из себя представляет новый стек технологий теоретически, можно поговорить об имплементации. А она, как всегда, не выдержала столкновения с реальностью.
Начнем с того, как же команда Unity хочет сделать C# таким же быстрым, как C++, а именно:
Создали новый компилятор для Работ с векторизацией и intrinsics (разве что без блекджека)
Создали нессылочные альтернативы массиву, списку, очереди и т.д которые дружат с Burst’ом. Особенность в том, что эти контейнеры надо аллоцировать и после их жизненного цикла освобождать, иначе утечка. Причем, аллоцировать надо не абы как, а с правильными лейблами (Persistent/Temp/TempJob).
Ввели в использование указатели на списки и указатели на функции. Также вам может понадобиться использовать Malloc, MemMove, MemCpy и подобные brand-new функции.
Я думаю, вы уже поняли к чему я клоню. Они решили, что лучший способ сделать сишарп таким же быстрым как и плюсы, это сделать из сишарпа плюсы! *занавес, бурные овации, публика в шоке*
Ладно указатели, ладно Dispose у контейнеров, но когда вы начали писать новый компилятор для языка, можно же было что-то заподозрить! Пытаться уже третий год реализовать стек технологий на языке, который не подходит вашему стеку, и при этом переделывать* язык, это же сумасшествие!
Ещё один пример несовместимости DOTS и C# это Jobs с Работой IJobChunk и производными. Для того, что бы проитерировать 3 компонента c помощью IJobChunk, вам надо 43 строки кода. Ситуацию могли бы спасти макросы, но они в C# предательски отсутствуют!
Следующая проблема нового стека Unity это недостаток многих функций, которые, иногда, могут вам пригодиться в создании игры, например:
Звук. Версия пакета для звука 0.1.0-preview17 и за 3 года он так и не обновлялся.
Интерфейс. Тут всё проще, пакета для интерфейса с поддержкой Entities просто нет.
2д. Существует com.unity.2d.entities, но он создан для Project Tiny и работает в общем-то только с ним, о Project Tiny тоже позже.
Анимации. Пакет тоже существует, версия 0.9.0-preview.6, в теории использование возможно, на практике не очень.
Всё элементы движка, которые не требуют очевидного отдельного пакета. Свет, камера, партиклы и т.д, всеми ими нельзя управлять через Entities, что угодно делайте. Можете создавать псевдо-сущность с компонентом, к примеру, камеры, и отдельной системой в главном потоке синхронизировать поля между MonoBehaviour камерой и вашей псевдо-камерой, можете другие костыли городить. За 3 года решения от Unity так и нет.
*под переделыванием языка я подразумеваю минимизирование использования ссылочных объектов и, как следствие, кучи путем создания кастомных аллокаторов, компиляторов которые не поддерживают кучу и т.п.
Проблемы
Предположим, что отсутствующие пакеты можно дописать, а текущую имплементацию можно ещё починить (в конце концов, можно переписать Roslyn!). Но проблемы самой DOTS как концепции, быстро решить не выйдет.
DOTS по умолчанию сложен. ECS требует полного понимания, как он работает, программисту надо знать на что влияет Read/Write доступ к компонентам, что такое Sync point и как сократить их количество, зачем нужен ECB, WriteGroup, гибридные компоненты и многое, многое другое. Также есть Jobs со своими контейнерами на указателях и такой же морокой с Read/Write доступом, Burst с миллиардом приспособлений для оптимизиации и примерами в документации из ассемблера.
Такая сложность явно не идёт на руку движку, одна из основных преимуществ которого простота. Unity занял свое место на рынке как «движок для дизайнеров, а не программистов», на нём делают Cuphead, Ori, Hollow Knight и другие игры которые не Factorio по сложности исполнения и требуемой оптимизации. У Unity занят рынок мобильных игр, маленьких кросс-платформенных инди игр, игр уровня «мы с парнями другие движки не знали, пришлось на этом пилить» (таким образом получаются Rust и Tarkov), в общем, идиллия. ААА игры не будут делать на Unity даже с полностью реализованным DOTS, ведь для них уже пишут отдельные движки на основе опенсоурса (UE) или вообще с нуля, а сложные инди игры делают энтузиасты на своих микро-движках, фреймворках или на том же UE.
В общем, плюсы от перехода на DOTS неочевидны, а минусы из-за нехватки ресурсов компании на поддержку и развития старых решений из уже уходящей эры MonoBehaviour присутствуют.
Project Tiny
В дополнение к выше написанному, хочу упомянуть Project Tiny. Это этакий набор мини-фреймворков для DOTS, которые должны помочь в разработке «Instant games» или, если выражаться русским языком, сделанные за 2 недели Егором из 9Б гипер казуальные игры типа тривряд. Также для Project Tiny команда Unity написала новую среду выполнения DOTS Runtime, вот вам документация (кстати в гугл доках, такого я не видел). Опять пересказывать то, что они пытаются переделать C#, смысла я не вижу, просто обозначу, что факт существования данного набора пакетов подтверждает то, что они хотят именно переделать движок с новым стеком DOTS, что в свою очередь, делает проблемы, описанные выше, ещё более значимыми.
Unity, но без DOTS
Под данным заголовком я хочу описать проблемы как старого архитектурного решения Unity, так и самого Unity как движка.
MonoBehaviour
Такое решение довольно простое в понимании и не требует вообще никаких навыков у программиста, у вас все под рукой. Для больших проектов это, естественно, никуда не годится. Тут нет какой-то внятной архитектуры, у вас логика приложения находится сразу же в структуре с данными (компоненте). MonoBehaviour почти не предоставляет никаких абстракций, не дает инструмента для управления зависимостями, методы для поиска объектов с MonoBehvaiour на сцене де факто антипаттерн из-за производительности, методы для вызова Message-методов у других MonoBehaviour ещё больше антипаттерн из-за ещё худшей производительности.
В принципе создание чего-то сложнее тривряд с активным использованием MonoBehaviour не рекомендуется, а поскольку модульность в старом Unity отсутствует как понятие, просто убрать пакет с MonoBehaviour и написать что-то свое вы, конечно, не можете. Так и живут разработчики под Unity с гайдлайнами по оптимизации, в которых рекомендуют не использовать половину функций движка.
Команда Unity давным давно забила на попытки хоть как-то развить эту систему и пофиксить проблемы с производительностью.
Editor и UI
Разработчики Unity не умеют в UI. За 16 лет они не смогли создать пакет для адекватного интерфейса с xml/css/js и имплементировать редактор своего движка на нем. Для игр они сделали какой-то хлам с Canvas-ом и перетаскиванием панелей по иерархии сцены, а для редактора они предоставили что-то невообразимо ужасное с IMGUI на C# и рефлексией.
Можно было бы сказать, что реализовать полный набор функций CSS движка довольно сложно, но вот Valve создали свой фреймворк Panorama с JS’ом, анимациями, масками, фоном, партиклами, сценами и многим другим. Благодаря ему, у игр Valve одни из самых лучших интерфейсов в индустрии. Понятно, что сравнивать Valve с Unity не совсем корректно, но это пример успешной реализации xml/css/js интерфейса в движке.
Декларируемая универсальность
Уже не совсем техническая, но огромная проблема Unity прошлого, настоящего и будущего. Unity старается быть универсальным, но игровой движок по природе своей не может быть универсальным. Нельзя сделать движок, который одинаково подходил бы сандбокс игре с процедурной генерацией мира, кооперативному FPS шутеру и мобильному кликеру. У разных игр разные требования к архитектуре движка, и если ваш движок это не каркас для плагинов как vim, то сделать его одинаково подходящим для всех не выйдет.
В случае с Unity это выливается в то, что ни одно отдельно взятое общее решение движка просто не подходит вашей конкретной проблеме. Как итог, вы постепенно отказываетесь от предоставленных движком решений и пишете свои, от чего попросту теряете время.
Этой проблеме, по сравнению с остальными, выделено не так много места в статье, но она фундаментальна. Именно эта проблема, скорее всего, потратит тонну вашего времени и похоронит проект, или уже похоронила. Если разработчики Unity сразу бы решили, для каких игр они делают свой движок, этой статьи бы не было.
Другое
Руководствуясь больше долгом о написании всех недочетов Unity, чем здравым смыслом, хочу отметить ещё немного мелких проблем которые не заслуживают отдельного параграфа, но заслуживают упоминание:
Существование авто-сериалайзера Unity который работает хуже чем любой другой из существующих в мире, я думаю что сериалайзер на конвейерах в Factorio работал бы лучше, и как минимум, поддерживал бы сериализацию словаря.
Перезагрузка всех ресурсов с надписью «Hold on» после каждой правки кода. Команда Unity клянется что ничего не могут с этим сделать, но это нетерпимо.
В Unity до сих пор нет поддержки C# 9, я просто напомню, что последняя версия уже C# 10. Поддержку #9 давно добавили.
Асинхронные юнит тесты обещали, но конечно, не сделали. Приходиться создавать костыли.
Конец
Статья вышла немного больше, чем я думал и наверняка я где-то допустил ошибку, так что прошу в комментарии. А если вы тот самый человек из начала статьи, который ищет движок для своего проекта, можете ознакомиться со следующим списком:
Для небольших игр с простой 3д или 2д графикой
Unity. Не смотря на все минусы перечисленные выше, скорее всего для простых игр он вам подойдет.
Godot. Сам не пробовал, по ощущениям Unity v2, но опенсоурс и не будет требовать от вас деньги и ставить свой логотип в начале.
GameMaker: Studio. Создан для 2д игр, на нем сделали Undertale. Без подписки минимум за 10$ делать ничего не хочет.
Microsoft XNA. Не движок, но фреймворк для создания игр на C#, больше не поддерживается (но есть форки). На нем создают довольно много разных инди игр и по сей день, одна из самых популярных это Stardew Valley.
Для средних или больших игр с 3д графикой
UnrealEngine. Больше мне советовать нечего, скорее всего он вам подойдет. Писать код на C++ это сжигание тонны времени, но блюпринты могут вас спасти.
Другое
Amethyst. Движок на Rust, пока без своего редактора, естественно опенсоурс. Разработка движка прекращена.
Bevy. Конкурент предыдущего движка, можете попробовать оба.
Unity: системы частиц
Системы частиц похожи на соль: даже небольшое количество может добавить готовящемуся «блюду» стиля. Современные игры, в которых не используются системы частиц, выглядят довольно бледно.
В прошлом нам приходилось каждую струйку дыма программировать самостоятельно. К счастью, благодаря встроенной модульной системе частиц Unity Shuriken делает создание частиц достаточно простой задачей. Эта система частиц проста в изучении и позволяет создавать сложные эффекты.
В этом туториале вы научитесь следующему:
Примечание: в этом туториале подразумевается, что вы знакомы с основами работы в Unity. Если вы новичок в Unity или вам нужно освежить свои знания, то для начала изучите наш туториал Introduction to Unity.
Приступаем к работе с системами частиц
Скачайте заготовку проекта для этого туториала и распакуйте её в удобное для вас место. Учтите, что для работы с туториалом вам понадобится как минимум Unity 2017.2.
Откройте Starter Project в Unity. Ассеты внутри него распределены по нескольким папкам:
Добавление системы частиц
В общем случае система частиц испускает частицы в случайных точках в пределах заранее определённого пространства, которое может иметь форму, например, сферы или конуса. Система определяет время жизни самой частицы, и когда оно заканчивается, система уничтожает частицу.
В системах частиц удобно то, что они являются компонентами, которые можно добавлять к любому GameObject в сцене. Хотите, чтобы из глаз акул вырывались лазерные лучи? Просто добавьте к GameObject глаза акулы систему частиц!
Откройте сцену Torch в окне Project Window и запустите сцену:
Пока здесь не происходит ничего интересного. Факел висит на стене, но на нём не видно огня. Для начала нам нужно добавить систему частиц.
Остановите выполнение сцены и выберите TorchFireParticles в Hierarchy. В Inspector нажмите на кнопку Add Component. Найдите Particle System и нажмите, чтобы добавить её:
Примечание: вы могли заметить, что я не добавил систему частиц непосредственно к GameObject MedievalTorch. Я сделал так, чтобы частицы испускались из ёмкости с топливом в верхней части, а не из середины факела.
Запустите сцену, и вы увидите, что частицы уже испускаются:
Примечание: вы можете видеть вместо белых розовые частицы. Похоже, это баг Unity с заданием текстуры по умолчанию. Если у вас произошло такое, то не волнуйтесь, скоро мы зададим правильную текстуру пламени. Если вы хотите исправить этот баг уже сейчас, то нажмите на раздел Renderer системы частиц, нажмите на точку рядом с полем Material и в открывшемся окне дважды щёлкните Default-Particle.
При выборе GameObject с присоединённой к нему системой частиц вы заметите в правом нижнем углу окна сцены чёрное диалоговое окно. Это диалоговое окно позволяет симулировать или останавливать систему частиц. Нажатие на кнопку Simulate активирует систему частиц и заменяет её на кнопку “Pause”. Чтобы остановить симуляцию, нужно нажать на кнопку “Stop”.
Это диалоговое окно полезно при создании систем частиц, выполняемых в течение ограниченного периода времени, например, для взрывов.
Рассмотрим систему частиц внимательнее
Взгляните на Inspector. Вы заметите, что добавленный нами компонент системы частиц имеет несколько подразделов:
Каждый из этих подразделов называется модулем (Module). В этих модулях содержатся параметры системы частиц. Развёрнутый по умолчанию модуль называется модулем Main:
Модуль Main — фундамент любой системы частиц в Unity. Здесь находятся самые основные параметры частиц:
Сверху: 8 секунд. Внизу: 3 секунды
Сверху: 2. Снизу: 10
Задайте значение скорости 0.75; так эффект пламени будет медленнее и плотнее.
Примечание: изменяя параметры системы частиц, вы будете видеть её предварительный обзор в окне Game. В процессе выполнения туториала посматривайте на этот предварительный обзор.
Запустите сцену, чтобы посмотреть, как повлияли внесённые изменения:
Мы настроили факел, но эффект огня пока оставляет желать лучшего. К счастью, в модуле Main есть дополнительные опции, позволяющие усовершенствовать форму и поведение факела.
Другие свойства модуля Main
Выберите в иерархии GameObject TorchFireParticles и прокрутите вниз, к системе частиц. В модуле Main Module посмотрите на следующие свойства:
Сверху: 0.2. Внизу: 1.
Сверху: 0°. Внизу: 45°
Сверху: local space. Внизу: world space
Снова запустите сцену, чтобы увидеть, как на неё повлияли изменения:
С каждым разом становится всё больше похожим на пламя, правда?
Однако нам нужно больше частиц. Для этого нам нужно изменить emission системы.
Знакомство с модулем Emission
Модуль Emission управляет количеством и временем испускаемых частиц в системе и позволяет создавать любые эффекты, от постоянного потока до резкого взрыва частиц.
Находясь в Inspector системы частиц, нажмите на заголовок модуля Emission:
При этом откроется модуль Emission:
Rate over Time представляет количество частиц, испускаемых за секунду. Задайте для Rate over Time значение 15.
Запустите сцену снова; теперь система частиц будет больше походить на горящее пламя.
Но заметно, что она всё ещё больше похожа на дым. И здесь мы внесём самое большое изменение на текущем этапе туториала: собственную текстуру!
Добавление собственной текстуры
У всех частиц есть материал частиц и текстура, задающая их внешний вид. С текстурой по умолчанию мы можем сделать только это. Заменив текстуру, мы можем создавать эффекты наподобие волшебных звёздочек, дыма и, разумеется, огня.
Заменить текстуру частиц достаточно просто. До этого момента частицы отрисовывались на экране с помощью материала Default-Particle, который является материалом частиц с круговой градиентной текстурой:
Чтобы заменить этот материал, выберите в иерархии GameObject TorchFireParticles. Затем найдите в инспекторе компонент системы частиц и откройте модуль Renderer системы частиц.
Откройте папку Materials в окне Project View и перетащите на FireMaterial Material на свойство Material:
Затем запустите сцену, чтобы увидеть, как применяется наша выбранная текстура:
Чувствуете жар? Однако пламя слишком широкое; Чтобы исправить это, нам нужно изменить форму системы частиц.
Изменение формы системы частиц
Модуль Shape, как можно понять из названия, управляет формой и поведением частиц в этой форме. Можно выбрать одну из нескольких различных форм; каждая имеет свои собственные параметры. Это позволяет создавать частицы в параллелепипеде, в сфере или даже в собственном меше!
Разверните модуль Shape в инспекторе:
В качестве формы (shape) системы частиц выбран конус (cone), то есть частицы испускаются из основания base и движутся наружу под углом (angle):
В показанном выше примере основание окрашено синим, угол зелёным, а частицы — красным. Также стоит заметить, что при развёрнутом модуле Shape мы видим в окне Scene удобный предварительный обзор конуса:
Меняя Angle, можно изменять размер конуса, делая его шире или уже. Укажите значение 7; так мы получим удобную узкую границу, которая немного расширяется, когда частицы поднимаются вверх.
Меняя Radius, мы можем менять размер основания. Чем больше значение, тем больше будут рассеиваться частицы при испускании. Выберите значение 0.2; так мы обеспечим создание пламени внутри ёмкости для топлива факела.
Запустите сцену и посмотрите, как изменилась форма пламени:
Оно начинает походить на настоящее пламя! Последнее, что можно сделать — изменять размер частиц с течением времени их жизни.
Изменение размера с течением времени жизни
С помощью модуля Size over Lifetime можно создавать частицы, увеличивающиеся или уменьшающиеся с течением их жизни, или даже пульсирующие, как светлячки в лесу.
Найдите в списке модулей системы частиц раздел Size over Lifetime. По умолчанию от выключен, поэтому поставьте флажок рядом с названием модуля:
Разверните модуль Size over Lifetime, нажав на его название. Так вы откроете тёмно-серый фон с плоской кривой (Curve) в верхней части:
Нажмите на тёмно-серый фон, чтобы открыть редактор кривых в нижней части инспектора. Горизонтальная ось отображает время жизни частицы, а вертикальная ось — её размер:
Для редактирования кривой можно перемещать ключевые точки с обоих сторон красной линии; добавлять новые ключи можно двойным нажатием на любое место кривой. Для удаления ключевых точек нажмите правой клавишей мыши на точку и выберите Delete Key. Также можно выбрать одну из заранее созданных кривых в нижней части окна:
Вспомните, как ведут себя языки пламени в реальном мире: они уменьшаются при поднятии частиц вверх. Чтобы имитировать такое поведение, мы выберем третью готовую кривую справа для создания плавно опускающейся кривой:
Запустите сцену, чтобы увидеть эффект во всей его полноте!
Поздравляю! Вы узнали, как настраивать новую систему частиц и изменять её по своему усмотрению для создания красивого эффекта огня.
В следующем разделе мы разбудим в себе внутреннего Майкла Бэя, чтобы научиться создавать эффекты взрывов!
Создание эффекта бомбы
Создать эффект взрыва в Unity довольно просто. Как только вы разберётесь, как создавать экземпляры частиц по своему усмотрению, вы сможете использовать этот эффект для таких вещей, как колёса автомобиля, выбрасывающие искры при трении о землю, или воздушные шары, которые взрываются и выбрасывают из себя конфетти.
Откройте Bomb scene в Project Window и запустите сцену:
В нижней части сцены есть пол, но кроме него в сцене больше ничего не происходит.
Запустите сцену снова, чтобы увидеть, как появляются бомбы:
Откройте скрипт Bomb в папке Scripts окна Project Window.
Добавьте в Start() следующий код:
Теперь бомбы при падении красиво вращаются. Но я обещал вам взрывы!
В иерархии нажмите на кнопку Create и выберите Create Empty. Нажмите на созданный GameObject и назовите его ExplosionParticles. Далее добавьте к этому GameObject новую систему частиц. Если вы забыли, как создавать систему частиц, то посмотрите первый раздел туториала.
Создав систему частиц, перетащите GameObject ExplosionParticles из иерархии в папку Prefabs в Project Browser. После этого удалите GameObject ExplosionParticles из Project Hierarchy.
Затем выберите префаб Bomb в папке Prefabs и перетащите префаб ExplosionParticles в слот Explosion Particles Prefab Bomb следующим образом:
Как и в случае с факелом, мы будем использовать для системы частиц материал Fire.
Выберите префаб ExplosionParticles в окне Project Window, а затем разверните в инспекторе модуль Renderer. Перетащите FireMaterial из папки Materials из окна Project Window в слот Material, как показано ниже:
Чтобы завершить эффект, нам нужно изменить следующие параметры в модуле Main:
Создание взрыва
Если вы решили, что это модуль Emission, то вы молодец!
Разверните Emission Module. Rate — это количество частиц, создаваемых за секунду. Для взрыва нам нужен не постоянный поток частиц, а резкая вспышка.
Задайте Rate over Time значение 0. Теперь перейдите к Rate over Distance и вы увидите список Bursts, который по умолчанию пуст:
Burst — это набор частиц, испускаемых одновременно в определённый момент времени.
Нажмите на кнопку + в нижнем правом углу, чтобы добавить новый Burst. Вы увидите два поля: Time и Count:
Оставьте Time равным 0, и задайте Count значение 150. Такие параметры заставят систему частиц одновременно испускать 150 частиц в начале системы.
Запустите сцену. Как всё выглядит теперь?
Для начала развернём модуль Shape:
Мы уже использовали этот модуль для формы пламени факела, но здесь можно выбрать и другие формы. Нажмите на раскрывающееся поле, в котором написано Cone, чтобы увидеть все доступные варианты:
Каждая форма влияет на эмиттер по-своему. На каждой показанной ниже анимации показан одинаковый эмиттер, у которого меняется только форма:
От одной системы можно получить множество различных эффектов, просто меняя её форму! Для создания реалистичного взрыва выберите форму Sphere.
Запустите сцену и готовьтесь взорваться:
Теперь всё выглядит потрясающе!
Изменение цвета
Открыв систему частиц в инспекторе, нажмите на флажок рядом с модулем Color over Lifetime, чтобы включить его, а затем разверните его. Вы сразу увидите слово Color с белым блоком рядом с ним. Нажмите на белый блок:
При этом откроется редактор градиента:
Изменение цвета в течение времени жизни частиц представлено в виде градиента. Начальный цвет находится слева, и частицы постепенно изменяют цвет на указанный в правой части:
Четыре белые полосы по краям называются маркерами; нажмите между двумя имеющимися маркерами, чтобы добавить новый. Чтобы удалить маркер, перетащите его с полосы:
Верхние маркеры управляют Alpha или непрозрачностью цвета, а нижние — значениями цвета RGB (Red, Green, Blue).
Нажмите на самый правый альфа-маркер. В нижней части редактора градиента будет показано текущее значение альфа-канала:
Перетащите ползунок к 0. Теперь частицы будут постепенно становиться прозрачными в течение времени свой жизни.
Снова запустите сцену, чтобы посмотреть, как повлияли внесённые изменения:
Хотите ещё больше улучшить сцены? Вернитесь к сцене с факелом и сделайте так, чтобы пламя использовало модуль Size Over Lifetime Module для получения похожего эффекта.
Куда двигаться дальше?
Готовый проект можно скачать отсюда.
В этом туториале вы узнали, как в Unity работают системы частиц и их модули, а также научились тому, как настраивать их для получения нужного эффекта. Поэкспериментируйте с различными параметрами, чтобы увидеть, каких ещё эффектов можно добиться.
Подробную информацию о системе частиц Shuriken и её модулях см. в официальной документации Unity и в видео о системах частиц. Также о скриптинге систем частиц можно подробнее узнать здесь.