Как сделать небо в unity

Обновлено: 08.07.2024

Независимый разработчик Дмитрий Лукаш рассказал ЦП о том, как выжать максимально красивую графику для вашей игры на Unity, а также об особенностях пятой версии популярного движка.

Итак, небольшой обзор рендера Unity. Изначально он создавался с оглядкой, да что там с оглядкой, в основном под мобильные платформы, поэтому его сделали максимально гибким и минимально привязанным к какому-то конкретному железу. То есть если очень хочется попользоваться какими-то специфичными функциями от нужной нам железяки — Nvidia или AMD, — не всегда получится.

Из преимуществ: в Unity есть два варианта рендера (в Unity5 три) — forward, deferred, и, для Unity5, legacy deferred (deferred от Unity4). Различие, если кратко, в принципе просчета освещения.

быстрый и достаточно хорошо кастомизируемый графический движок, который работает даже на очень старом РС-шном железе и новых мобильных платформах достаточно быстро;
позволяет использовать разные пути расчета в зависимости от задач;
неплохо документирован, возможность замены любых стандартных шейдеров (идут в комплекте в исходном коде) на свои — это огромный плюс;
батчинг деревьев и их билбордов.

сложность системы освещения — недостаточное количество информации в G-Buffer Unity4 делает написание шейдеров освещения для него затруднительным;
сложность понимания и взаимовлияния между проходами (хотите узнать, где у вас тень на меше в диффузном шейдере, — а тут не так все просто);
ограниченные возможности расширения G-Buffer, ограниченные возможности в deferred-режиме для различных моделей освещения и материалов;
система террейна и встроенный конструктор деревьев — очень интересные, но очень нелогичные вещи, заточенные на оптимизацию, но никак не на удобство.

64 бита. Наконец-то. Можно делать большие уровни и использовать 8К-текстуры;
при наличии напильника можно без особой боли перепилить старый проект под новый движок. Если нет лайтмаппинга, разница почти незаметна;
возможности GI (global illumination), PBS (physically based shading) из коробки и прочие вкусности, новые PCF-тени (менее жесткие и быстрые);
высокая кастомизация — исправление встроенных шейдеров, дописывание своей логики в редактор, возможность использования и расширения разных путей рендера.

измененная логика проходов (зависимость попадания источника тени с Z-Buffer: кто не отбрасывает тень, в Z-Buffer не попадает. Чертовски неудобно местами, убран проход Shadow-Collector);
встроенные деревья работают очень странно (были непонятные артефакты по контурам веток);
обычный deferred не так уж и быстр — при буфере в 192 бита на пиксель скорости не добавляется;
все еще в бете, работа GI и лайтмаппинга постоянно дорабатывается.

Думаю, читателя больше всего интересует, как быстро сделать, чтобы его игра или проект стал красивым и нарядным. Желательно, сразу и одной кнопкой. Попробуем сделать это в Unity4.

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

1. Определить, где происходит действие — внутри или снаружи помещений. Будет ли использовано большое количество источников света. Если снаружи, и нет множества источников света — проще использовать forward, если внутри или есть много световых источников — deferred. Если свет запекается — почти все равно.

2. Определиться со сменой погоды и временем суток. Если смены нет — все проще. Одно небо в HDR. Если есть — нужно подготовить несколько вариантов неба. Потом написать процедурную смену.

Теперь за работу. Есть несколько наборов пакетов, которые позволяют достаточно серьезно поменять картинку. Первый из них — Marmoset SkyShop. Второй на выбор — Alloy, Lux или Shader Forge. Все эти пакеты шейдеров дают красивую дополнительную картинку для корректного отображения физических материалов. Однако обычно хватает SkyShop.

Третий — Amplify Color, ProFlares или SSAO Pro. Хорошие и профессиональные цветокорректоры, профессиональные блики от линз, и SSAO с дополнительными параметрами (для отключения влияния затенения на туман).

Сразу замечу — все пакеты платные.

Поставьте и подключите SkyShop. Настройте небо и переключите шейдеры сцены, где нужно. Поставьте Lux (если это действительно нужно) и подстройте оставшиеся шейдеры.

Итак, мы активировали IBL-освещение. Для краткого понимания, что это такое: когда-то отражения в воде делали через cubemap от текущего skybox. Вода всегда отражала окружающее небо и ничего больше — очень быстро и очень просто. Этот же подход позже применили для освещения объектов окружающим их skybox. То есть небо и окружение вносит свой вклад в освещение всех элементов сцены, что делает общее впечатление от сцены гораздо более реалистичным.

Установите Amplify Color и настройте цветокоррекцию. Добавим эффекты SSAO Pro (screen space ambient occlusion — дополнительное затемнение в зависимости от геометрии сцены) и SkyShaft (он же GodRays — пробивающиеся лучики солнышка из стандартных пресетов), не забывая указать на источник света, GLobal Fog — и вот картинка уже гораздо веселее.

1. Основная составляющая картинки для фотореалистичного рендера — освещение. Если с освещением плохо, убедить игрока полностью не получится. Субъективно, ощущение от освещения — 40% ощущения от картинки. Освещение — сложная тема. Рассмотрим ее подробнее. Для понимания, как это работает, проще рассмотреть пошаговое изменение картинки, при включении всех возможностей, которыми мы хотели бы воспользоваться. Для начала я убрал цвета текстур (albedo), чтобы лучше видеть влияние освещения.

Здесь нет ничего, кроме контуров геометрии. Включаем один источник света. Да будет свет!

Мы включили источник освещения без теней. Все цвета albedo установлены на 50% серого. Включим тени и изменим цвет на белый.

Здесь у нас один источник, жесткие тени и белый цвет. Прохладно. Заменим тени на мягкие.

Картинка становится интереснее, однако освещение все еще очень искусственное. Добавим SSAO — систему затемнения на стыках геометрии внутри сцены.

Получается достаточно натурально. А теперь добавим IBL — освещение сцены в зависимости от окружающего неба.

Вот этот коричневатый оттенок — влияние окружающего освещения на картинку. Для лучшего понимания включим цвет на небе.

А теперь сравним, что получится, если мы сменим небо на другое.

Замена неба очень сильно влияет на картинку. В данном случае в IBL-компоненте присутствует и дифузная, и спекулярная составляющие.

Посмотрим на детальный срез технологий и улучшение картинки в черно-белом варианте.

Вот визуальное отличие. Каждая дополнительная технология освещения вносит свою долю реалистичности в картинку. Теперь отключаем IBL и включаем цвет.

Темно и грустно. Попробуем добавить SSAO.

Реалистичнее, но еще темнее. Попробуем увеличить интенсивность источника света.

Вот этот вариант более похож на стандартное освещение Unity4. Либо все темное, либо выглядит очень искусственно и пересвечено. Убираем интенсивность источника, убираем SSAO, включаем IBL.

Получилось почти то, что нам надо. Посмотрим на эту же картинку с другим небом. Положение и интенсивность источника света оставим без изменений — то есть дорожка к солнцу будет расположена некорректно. Однако нам это необходимо.

Картинка сильно изменилась. И выглядит очень натурально. Сравнение:

Здесь присутствуют стандартные постпроцессы: SSAO, Bloom, SunShafts, GlobalFog. Получилось практически то, что нужно. Можно еще добавить по вкусу эффект глубины резкости — для размытия контуров дальних деревьев.

Итак, работа над картинкой завершена. Посмотрим с другого ракурса:

Пока же просто покажем, как модель, воссозданная по фотографиям, чувствует себя среди IBL-освещения. В данном случае я взял модель коряги, восстановленную после фотограмметрирования по 170 фотографиям. Геометрия модели достаточно сложная, однако удалось восстановить её достаточно детально. Затем сделать низкополигональную модель и снять нормали. Скриншоты модели из MeshLab.

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

IBL действует очень хорошо. Стоит заметить, что для натуральных природных вещей спекулярный компонент влияет крайне незначительно, как и френель.

Итак, с базовыми элементами освещения разобрались.

2. Модели — текстуры и геометрия.

Создание хорошей и качественной геометрии и текстур — задачка тоже не из легких. Однако если раньше требовалось специально оптимизировать меши и соединения вершин, то сейчас все несколько упростилось. Напомню, что в картинке по-прежнему максимум 2 млн треугольников и до 2 тысяч drawcalls для PC. Если вы делаете шутер и хотите 60 и более FPS — и того меньше. Не забываем модный нынче PBR и текстурки для него в моделях.

Замечу, что Marmoset SkyShop в Unity4 использует не совсем полную поддержку PBS, однако в большинстве случаев ее хватает с головой. Также стоит определиться, какой подход для создания текстур и материалов вам более удобен. Сейчас их два — металлик и спекулярный.

Unity5 официально поддерживает оба подхода, однако SkyShop поддерживает урезанный спекуляр-подход. Для металлик-подхода можно использовать другие пакеты шейдеров, однако их совместимость с IBL от SkyShop периодически оставляет желать лучшего. Разница в подходах детально описана здесь. Где найти модели.

3. Если игра на природе — позаботьтесь о деревьях, траве, кустах. Тут, как и с освещением. Долгая история. Особенно в Unity.

4. В некоторых играх важно не забыть о воде. Речной, озерной, океанской. Динамической или статической.

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

5. В постэффектах сложно соблюсти правильные пропорции.

Многие увлекаются DOF, bloom и прочими вкусностями. Рекомендации — хороший туман и ленсфлар с SSAO. Bloom по вкусу, но лучше не переборщить. Для линейного цветового еще tonemapping. Обычный GlobalFog и SSAOPro неплохо сочетаются.

6. Тени. В Unity они есть, очень неплохие из коробки. Можно не трогать (неужели тут что-то все-таки можно не трогать?).

7. Небо. Проще всего использовать один или несколько статических скайбоксов в Marmoset. Так как если делать IBL, то динамическое небо резко становится несколько проблемным.

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

Для десктоп-систем стоит ориентироваться на два вида — офисные и игровые. Офисные компьютеры более слабые, имеют встроенные видео-подсистемы. Игровые или домашние обычно несколько более продвинуты.

Чтобы получить хорошую картинку, нужно обратить внимание на два фактора — drawcalls (в Unity5 — batches), и миллионы треугольников в сцене. Для офисных систем это, в идеале, около 1 тысячи drawcalls и 1 млн треугольников. Для игровых — 1,5-1,8 тысяч drawcalls и 1,5-2 млн треугольников (или даже больше).

Это необходимое, но недостаточное условие. Уменьшение числа drawcalls обязательно, иначе процессор просто не будет успевать подготавливать данные и обмениваться с видеоадаптером. А вот что касается треугольников и вершин — здесь производительность зависит уже от используемых шейдеров и модели освещения. Чем тяжелее шейдеры, тем меньше треугольников. То есть прямой зависимости нет.

Первым делом уменьшаем количество геометрических фигур. Для уменьшения треугольников используем LODs, oclussion culling, правильно настраиваем появление billbords-деревьев и pixel error в террейне. Следим, чтобы количество треугольников не сильно менялось в зависимости от угла зрения.

Затем занимаемся drawcalls. Здесь есть два варианта — уменьшение количества используемых в сцене материалов и батчинг мешей — объединение геометрии различных статических мешей в одну. Сильно оптимизировать стоит только если очень хочется заморочиться. Можно просто взять один из компонентов из Asset Store, который неплохо это делает. Однако важно помнить, что для успешного объединения меши должны разделять один материал. Хорошо справляется с задачей Advanced Foliage System, но он не совсем совместим с Marmoset.

Все это можно увидеть в информации Stats на панели Game.

В Unity Pro также есть профайлер, который позволяет посмотреть, что именно рендерится дольше всего или вызывает задержку — CPU, GPU, или что-то еще.

Итак, мы оптимизировали геометрию и материалы. Следует предостеречь от использования двусторонней геометрии (автозашивание — создание второго слоя геометрии, для листьев, например). Используйте шейдеры для односторонней геометрии, иначе рискуете столкнуться с Z-fighting — стробированием близко стоящих элементов геометрии, или их теней.

Тени. Включение теней добавляет два drawcalls на каждый материал с тенью. Один на прием тени, один на отбрасывание. Итого, включение теней умножает количество drawcalls на два в Unity4. В Unity5 проход приема теней отключен, потом drawcalls меньше. Динамические тени следует использовать аккуратно, существенно уменьшив расстояние их появления.

Подключаем воду, если нужно. Вода — тема бесконечная, но Unity-вода очень даже неплохая.

Подключаем эффекты. Все, что подключили и настроили, ослабляем чуть больше чем вполовину. Рекомендуется поставить SSAO (подпилить, чтобы через туман не пролезал — или просто купить SSAO Pro), GlobalFog (подпилить, чтобы не пролезал через воду), SunShafts стандартный, ToneMapping (если HDR), и далее — по желанию. Можно также настроить Amplify Color и Motion Blur, Bloom, Dirt Lenses и Lens Flares.

Настройки картинки для постпроцессов — это отдельная история.

Здесь, например, стандартный SSAO, Bloom, SunShafts (Blur 3), Depth Of Field (DX11) с Bokeh. Но в постпроцессах главное правило — не переборщить, и не совать всё что есть, без разбора.

Эффекты едят производительность. Особенно SSAO и прочие. Если используется deferred, можно поставить antialiasing постэффектом — так как MSAA нормально работать не будет. Но встроенные antialias-фильтры не слишком хороши. Посмотрели производительность эффектов, ненужное выбросили.

В итоге получили неплохое освещение — lightmapping + dynamic + shadows + soft shadows (осторожно, мягкие тень кушают производительность). Если поставили Marmoset — получите отличный IBL с переключаемыми зонами, хиленький и не очень честный PBR (ограничение архитектуры буфера глубины и нормалей в Unity4), и все это достаточно неплохо смотрится и почти не тормозит даже на достаточно слабых компьютерах.

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

Вот и все, продолжение следует.

Forward позволяет быстро рассчитывать четыре источника света per pixel, еще до четырех в режиме per vertex, и еще два в режиме сферических гармоник. В случае первых четырех на каждый, кроме первого, используется свой дополнительный проход.

Deferred позволяет получить очень большое количество источников света, которые не отбрасывают теней. Ограничение — в варианте Unity4 в базовых шейдерах deferred доступно только освещение по схеме Blinn-Phong.

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

Deferred в Unity5 состоит из:

diffuse color (rgb);
specular color (rgb);
smoothness (a), была заменена на roughness позже;
world normal (rgb, 10.2);
emission/light — Floating Point 16, если включен HDR;
Z-buffer: depth.

Требует OpenGL ES 3.0 на мобильных платформах и не работает на старом РС-железе (десятилетней давности). Для сравнения в Crysis 3.0 — 96 бит на пиксель MRT3 (D24S8, 32,32).

Unity как графический движок: преимущества и недостатки

Преимущества и недостатки Unity4

быстрый и достаточно хорошо кастомизируемый графический движок, который работает даже на очень старом РС-шном железе и новых мобильных платформах достаточно быстро;
позволяет использовать разные пути расчета в зависимости от задач;
неплохо документирован, возможность замены любых стандартных шейдеров (идут в комплекте в исходном коде) на свои — это огромный плюс;
батчинг деревьев и их билбордов.

сложность системы освещения — недостаточное количество информации в G-Buffer Unity4 делает написание шейдеров освещения для него затруднительным;
сложность понимания и взаимовлияния между проходами (хотите узнать, где у вас тень на меше в диффузном шейдере, — а тут не так все просто);
ограниченные возможности расширения G-Buffer, ограниченные возможности в deferred-режиме для различных моделей освещения и материалов;
система террейна и встроенный конструктор деревьев — очень интересные, но очень нелогичные вещи, заточенные на оптимизацию, но никак не на удобство.

Преимущества и недостатки Unity5

64 бита. Наконец-то. Можно делать большие уровни и использовать 8К-текстуры;
при наличии напильника можно без особой боли перепилить старый проект под новый движок. Если нет лайтмаппинга, разница почти незаметна;
возможности GI (global illumination), PBS (physically based shading) из коробки и прочие вкусности, новые PCF-тени (менее жесткие и быстрые);
высокая кастомизация — исправление встроенных шейдеров, дописывание своей логики в редактор, возможность использования и расширения разных путей рендера.

измененная логика проходов (зависимость попадания источника тени с Z-Buffer: кто не отбрасывает тень, в Z-Buffer не попадает. Чертовски неудобно местами, убран проход Shadow-Collector);
встроенные деревья работают очень странно (были непонятные артефакты по контурам веток);
обычный deferred не так уж и быстр — при буфере в 192 бита на пиксель скорости не добавляется;
все еще в бете, работа GI и лайтмаппинга постоянно дорабатывается.

Как сделать красиво в Unity4

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

Сразу замечу — все пакеты платные.

Детальный тюнинг

Составляющие картинки

Здесь нет ничего, кроме контуров геометрии. Включаем один источник света. Да будет свет!

Здесь у нас один источник, жесткие тени и белый цвет. Прохладно. Заменим тени на мягкие.

Получается достаточно натурально. А теперь добавим IBL — освещение сцены в зависимости от окружающего неба.

А теперь сравним, что получится, если мы сменим небо на другое.

Посмотрим на детальный срез технологий и улучшение картинки в черно-белом варианте.

Темно и грустно. Попробуем добавить SSAO.

Реалистичнее, но еще темнее. Попробуем увеличить интенсивность источника света.

Картинка сильно изменилась. И выглядит очень натурально. Сравнение:

Итак, работа над картинкой завершена. Посмотрим с другого ракурса:

Итак, с базовыми элементами освещения разобрались.

2. Модели — текстуры и геометрия.

4. В некоторых играх важно не забыть о воде. Речной, озерной, океанской. Динамической или статической.

5. В постэффектах сложно соблюсти правильные пропорции.

Улучшаем картинку — практические советы

Все это можно увидеть в информации Stats на панели Game.

Подключаем воду, если нужно. Вода — тема бесконечная, но Unity-вода очень даже неплохая.

Настройки картинки для постпроцессов — это отдельная история.

Вот и все, продолжение следует.

Приложение

Принципы rendering paths для Unity4 и 5

Deferred в Unity5 состоит из:

diffuse color (rgb);
specular color (rgb);
smoothness (a), была заменена на roughness позже;
world normal (rgb, 10.2);
emission/light — Floating Point 16, если включен HDR;
Z-buffer: depth.

Эффект, который вы найдете в каждой 2D игре за последние 15 лет называется параллакс-эффектом. Короче говоря, идея заключается в том, чтобы перемещать фоновые слои с разной скоростью (т.е. чем дальше слой, тем медленнее он движется). Если все сделано правильно, то создается иллюзия глубины. Это здорово, красиво и просто в использовании.

Давайте реализуем все это в Unity. Добавление оси скроллинга – задача непростая, и нам придется поразмыслить, как написать остальной код игры с учетом этого аспекта. Над этим стоит задуматься, прежде чем начать кодировать :) Мы можем воспользоваться несколькими решениями:

Игрок и камера двигаются, все остальное неподвижно
Игрок и камера неподвижны. Все остальное движется

Первый вариант представляет собой достаточно сложную задачу, если у вас режим камеры Perspective (камера будет отображать объекты в режиме перспективного просмотра). Параллакс очевиден: фоновые элементы отличаются большей глубиной. Поэтому кажется, что они движутся медленнее.

Но в стандартной 2D игре в Unity мы используем ортографическую камеру (которая будет отображать объекты в ортогональном режиме, т.е. без эффекта глубины). У нас не будет такой величины, как глубина, в принципе.

Немного о камере: помните такое свойство нашей камеры, как "Projection"? В нашей игре оно установлено на Orthographic . Режим
Perspective означает, что мы имеем дело с классической 3D камерой с управлением глубиной. Когда мы переключаетмся на ортографическую камеру, все объекты отображаются с одинаковой глубиной. Это особенно полезно для графического интерфейса или 2D игры.

Чтобы добавить в нашу игру эффект параллакс-скроллинга, нам придется использовать оба эти способа. Итого у нас будет два скроллинга:

Игрок движется вперед вместе с камерой.
Фоновые элементы движутся с разной скоростью (в дополнение к движению камеры).

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

В играх жанра shmup, камера ограничивает передвижения игрока. Если камера перемещается вслед за игроком и по горизонтальной, и по вертикальной оси, игрок свободен в своих передвижениях и может идти, куда захочет. Но в нашем случае игрок ДОЛЖЕН находиться внутри четко обозначенной области.

Мы бы также порекомендовали использовать камеру в качестве самостоятельного объекта в 2D играх. Даже в платформере камера не строго привязана к игроку: она следует за его передвижениями с некоторыми ограничениями. В качестве одного из лучших примеров реализации камеры в платформере можно привести всем известную игру Super Mario World.

Спавн (место появления) врагов

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

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

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

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

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

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

Слой	Повторяющееся	Позиция
Задний фон с небом	Да	(0, 0, 10)
Задний фон (1-й ряд летающих платформ)	Нет	(0, 0, 9)
Средний фон (2-й ряд летающих платформ)	Нет	(0, 0, 5)
Передний план с игроками и врагами	Нет	(0, 0, 0)

Мы также можем добавить слои впереди игрока. Просто следите за тем, чтобы координаты оси Z находились между [0, 10] , иначе вам придется долго настраивать камеру.

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

В стандартных пакетах Unity есть кое-какие скрипты для параллакс-скроллинга (взгляните на демо 2D платформера в Asset Store). Вы, конечно, можете воспользоваться ими, но я подумал, что было бы интересно написать его с нуля. Вообще, старайтесь не использовать стандартные пакеты, поскольку они не дают вашему разуму развиваться. Вы ведь не ходите создать бесполезный клон, который никто и не вспомнит?

Простой скроллинг

Мы начнем с легкого: прокрутка фона без цикла. Помните, "MoveScript", который мы использовали ранее? Принцип тот же: скорость и направление, применяемые на протяжении определенного промежутка времени.

Создайте новый скрипт и назовите его "ScrollingScript":

Прикрепите скрипт к объектам игры со следующими значениями:

Слой	Скорость	Направление	Связан с камерой
0 - Задний фон	(1, 1)	(-1, 0, 0)	Нет
1 - Фоновые элементы	(1.5, 1.5)	(-1, 0, 0)	Нет
2 - Средний слой	(2.5, 2.5)	(-1, 0, 0)	Нет
3 - Передний план	(1, 1)	(1, 0, 0)	Да

А теперь, давайте добавим элементы на сцену:

Добавьте третий слой после двух предыдущих.
Добавьте несколько небольших платформ в слое 1 - Фоновые элементы .
Добавьте платформы в слое 2 - Средний слой .
Добавьте врагов с правой стороны на слое 3 - Передний план , подальше от камеры.

Неплохо! Но мы видим, что враги двигаются и стреляют когда они находятся вне камеры, даже до начала спавна!

Более того, проходя мимо игрока, они не исчезают (уменьшите изображение в режиме "Scene" и посмотрите налево: Poulpies все еще двигаются). Поэкспериментируйте со значениями.

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

Бесконечный фон

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

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

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

Найдите правильный баланс между потреблением ресурсов и гибкостью для вашей игры.

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

Небольшая заметка о том, как правильно использовать рендерер: Этот метод не работает для видимых объектов (то есть, тех к которым привязаны скрипты). Но вряд ли вам когда-нибудь понадобиться применять его для невидимых объектов.

Скрипт "RendererExtensions"

Поясним комментарии с цифрами:

Действительно, backgroundPart точно отражает то, что происходит в нашей сцене.

Не забудьте включить свойство "Is Looping" в "ScrollingScript" для 0 - Background на панели "Inspector". В противном случае (и это очевидно) мы ничего не добьемся.

Нажмите на картинку выше, чтобы увидеть анимацию.

Почему мы не используем методы OnBecameVisible() и OnBecameInvisible() ? Потому что здесь они не работают.

Смысл этих методов заключается в исполнении фрагмента кода при появлении объекта на экране (или наоборот). Они работают как методы Start() или Stop() (если вы решили использовать один из них, просто добавьте нужный метод в MonoBehaviour , Unity применит его).

Проблема в том, что эти методы также применяются при использовании режима "Scene" в редакторе Unity. А значит, поведение объектов в редакторе Unity и самой игре (независимо от платформы) будет отличаться. Это опасно и абсурдно. Мы всячески рекомендуем избегать этих методов.

Бонус: Улучшение написанных скриптов

Давайте обновим наши предыдущие скрипты.

Враг, версия 2 со спавном

Мы ранее говорили, что враги должны быть отключены, пока они не видны камерой.

Они также должны использоваться повторно, полностью пропав из поля зрения.

Мы должны обновить "EnemyScript", сделав вот что:

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

(Цифры указывают на комментарии в коде)

Давайте теперь запустим нашу игру. Хммм. ошибочка.

Отключение "MoveScript" привело к нежелательному результату: игрок никогда не дойдет до врагов, так как все они двигаются вместе со скроллингом слоя 3 - Foreground :

Помните: мы добавили "ScrollingScript" к этому слою, чтобы перемещатьть камеру вместе с игроком.

Но есть простое решение: переместить "ScrollingScript" со слоя 3 - Foreground на игрока!

В конце концов, почему бы и нет? Единственный объект, который двигается в этом слое – это сам игрок, и скрипт не прописан специально для определенного типа объекта.

Враги отключены до начала спавна (то есть, пока камера не достигнет точки, в которой они находятся).
Затем они исчезают, когда они находятся за пределами камеры.

Вы наверняка заметили, что игрок еще не ограничен рамками камеры. Нажмите "Play", затем кнопку со стрелочкой влево – и он покинет кадр.

Как видите, ничего сложного.

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

Что дальше?

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

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

Снижение размеров спрайта.
Настройка скоростей.
Добавление новых врагов.

В следующей главе мы еще немного поработаем над нашей игрой, поэкспериментируя с частицами!

Sergey Tenditniy про используемые им методы создания своих выдающихся модульных игровых окружений в Unity.

Перевод статьи с портала 80 level

Добрый день, меня зовут Сергей, я родом из Украины, но последние 3 года живу в красивой стране Словении.

Идея

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

Именно тогда меня посетила идея сделать что-то подобное в виртуальной среде, ведь если люди с удовольствием посещают такие места в реальности, то и виртуальное путешествие будет кому- то интересно.

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

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

Сначала я не предполагал продавать этот проект на площадке Unity Asset Store. Чуть позже я пришел к выводу, что правильнее будет создать целостное игровое окружение, а не просто сцену для красивого рендера. Мне хочется чтобы люди могли использовать созданное мной в своих собственных проектах.

Основные фото–референсы, сделанные мной во Франции:

Моделинг

Первые скриншоты по ходу этапов работы:

Основные этапы рабочего процесса:

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

2. Далее я добавил имеющимся домикам больше деталей и создал несколько новых.

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

4. Добавлен окончательный набор растительности. Проведена чистовая проработка детализации домиков. Настроено освещение и пост-процессинг. Уже практически готов финальный вид части моего городка. Это послужило мне стилевым и цветовым референсом при проработке остальных улиц и ассетов.

Для этого проекта я решил создать часть домиков на основе одного меша, не используя модульности их структуры. А вторую часть домиков я сделал полностью модульными, чтобы их можно было сложить из отдельных составных частей. Такой подход нужен был из-за того, что я выставил этот городок на продажу, и хотелось чтобы, покупатели имели выбор – пользоваться уже готовыми моделями или собрать их из модульных составных частей (двери, окна, стены и т.п.)

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

На рисунке вы видите, как он выглядит, и из каких элементов собран:

Все элементы:

Поликаунт:

Создаем ассеты

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

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

Растительность

Растительность создавалась очень просто. Ничего нового:

1. Первым делом я создал высокополигональный лист.

2. Использовал запекание нормалей и прозрачность.

3. Затем немного изменил его и с помощью клонирования создал всю ветку.

4. Для создания дерева использовал сферы, затем добавил ранее созданные ветки.

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

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

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

Текстурирование

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

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

Эти 5 текстур использованы на 95% поверхности того, что вы перед собой видите. Также я использовал текстуры в градациях серого для возможности добавления цвета с использованием vertex color в Unity, всё разнообразие цветов, грязь и потертости древесины я добавил, используя функционал vertex color texture blending с использованием vertex alpha. Я использовал специальный шейдер, созданный в Shader forge, он дал мне возможность смешения с использованием vertex alpha и одновременно overlay vertex color поверх текстур с использованием градаций серого.

На этом изображении вы видите, что я использовал только 4 материала для оформления домиков (древесина, бетон, черепица, стекло), но так, как я использовал vertex color – композиция выглядит интересной и достаточно разнообразной. Один цвет на изображении это один материал в игре.

Все разнообразие цвета создано с использованием vertex color, так каждый из этих домов в сцене может иметь уникальное сочетание цветов, одновременно, это очень не требовательно к ресурсам.

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

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

Инструменты

На первых этапах работы я применил vertex color в Maya, чтобы получить базовые цвета для домиков. А в среде Unity использовал инструмент vertex paint tool для добавления цветов. Из всего разнообразия я выбрал free face paint, при этом можно добавлять цвет сразу на весь полигон и это быстрее чем на каждый вертекс по отдельности. Если у Вас есть шейдер поддерживающий vertex color или смешение текстур, то можно прямо в сцене Unity очень быстро изменить общий вид ваших ассетов.

Вы можете посмотреть, как я это реализовал на этих изображениях:

Освещение

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

Я использовал только real-time направленный свет в этой сцене. Для всего непрямого освещения использовались стандартные средства Unity.

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

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

Также нужно наметить разделение заднего плана от переднего используя стандартный туман Unity. Ощущение солнечного дня создает контраст между затененными и освещенными зонами.

Все остальное сделано с помощью пост-эффектов.

Пост-процессинг

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

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

Заключение

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

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

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

Читайте также: