Рендер_финал_точнофинал_v002_23_07_2020
Глобально — рендер и рендер. Единственное, что здесь нужно упомянуть — это то, что любой рендер нужно проверять Большинство современных программных решений и рендер-движков очень хороши, но не идеальны
В нашей студии был случай, когда из-за программной ошибки двое наших продюсеров вылетели в Екатеринбург один за другим с перерывом в 8 часов. И это мы еще отсмотрели рендер, ошибка вылезла на большом экране. С тех пор у нас в студии висит проектор, с помощью которого можно посмотреть картинку на большом экране
Самый простой способ — просмотр контента тем человеком, который этой ночью спал (если это возможно)
Второе — проверка технических требований по чек-листу. В чек-листе — разрешение, кодек, fps, название файлов и т.п.
Этот шаг мы еще сами внедряем, если честно
Такая простая схема сделает Вашу жизнь чуточку проще
Напоминаю, что этот цикл статей был сделан для организаторов мероприятий, режиссеров, продюсеров мультимедийных проектов
Пишите в комментариях, если хотите получить 30-минутную лекцию нашего директора, Артема, на тему этой системы
На этом цикл статей завершен, мы искренне желаем, чтобы все Ваши проекты проходили также легко, как прошел для Вас этот цикл
Не забывайте следить за нами в Инстаграм, там каждый день мы в течение уже 34 недели выкладываем по одной творческой работе в день в рамках Daily Render Challenge.
Материал подготовлен командой FoxMotion
«Семь раз проверь — один раз рендерь». Или как рендериться один раз без правок
Глобально — мы собираем сетап в АЕ таким образом, чтобы в него можно было раскладывать файлы, которые мы рисуем по заранее выданной маске.
Если по простому — то мы собираем таким образом, чтобы художники могли подкладывать свои файлы в проект, а они сами становились в нужные места мультимедийной декорации, экрана, проекционной поверхности или чего-либо в этом роде.
Для больших сложных проектов иногда используют профессиональные системы превизуализации, такие как L8 (ex. LightConverse), Capture, Wyziwig.
В этих системах можно кроме контента визуализировать также и свет, экраны, декорации и все, что душе угодно в рамках технического оснащения мероприятий и шоу
Зачем так заморачиваться?
Превиз экономит время рендера, т.к. превиз всего проекта считается относительно недолго, а полноценный рендер может занимать несколько часов на один файл
Принцип такой: утвердили превизы — встали на рендер. И в процессе рендера нашего Клиента не терзают сомнения на тему того, что он получит, т.к. он уже все видел на превизах и сюрпризов быть не должно
P.S. Превизы — важная штука. Её довольно часто ленятся делать, т.к. нужно дополнительно что-то собирать, что-то городить.
Но. Занимает это 10 минут, а времени рендера может сэкономить пару дней, если не неделю.
И да. Все любят сюрпризы. Кроме режиссеров, продюсеров мультимедийных проектов и организаторов мероприятий, когда это касается их работы
Именно поэтому вся система направлена на то, чтобы максимально исключить такие сюрпризы
Следите за нами в Инстаграм, там каждый день мы в течение уже 33 недели выкладываем по одной творческой работе в день в рамках Daily Render Challenge.
Материал подготовлен командой FoxMotion
3D рендеринг: отрисовка сцены
Всем привет! Команда Fractured Byte снова с вами на UE4 Daily. Сегодня мы рассмотрим на практике, как отрисовывается сцена на GPU, используя знания, полученные в первой части статьи. Рекомендуем освежить в памяти основные моменты, описанные в первой статье, а тем кто не читал ее совсем — рекомендуем сделать это в обязательном порядке, так как в ней мы разбирали основные ресурсы, методы и функции, используемые GPU для отрисовки сцены.
Самой же интересной частью этой статьи является интерактивное демо, в котором буквально можно “пощупать” кадр прямо в браузере.
Вот мы и добрались до отрисовки сцены. В отрисовке сцены участвует как CPU, так и GPU. Задача CPU — подготовить контент и сказать GPU, что отрисовать. GPU просто выполняет команды, которые ему приходят. CPU отправляет команды на GPU через драйвер, используя определенный интерфейс — некий «стандарт общения». На данный момент этих стандартов довольно много — OpenGL, DirectX, Metal, WebGL, Vulkan и т.д., которые предоставляют нам определенные аппаратные возможности для отрисовки.
При создании демки на HTML5 мы столкнулись с проблемой wireframe геометрии — она просто не рисовалась. Оказалось, WebGL (а в браузере в качестве «стандарта общения» с GPU используется именно он) не поддерживает отрисовку «незакрашенных» примитивов, но зато есть поддержка отрисовки других примитивов — линий. Мы создали свой компонент на основе CustomMeshComponent , чтобы преобразовать геометрию в набор линий для демонстрации.
В интерактивной демке мы проиллюстрировали два подхода отрисовки сцены — Forward Rendering и Deferred Rendering. Эти основные методы, все остальные — их вариации или модификации, с учетом новых возможностей (например — LightPrePass).
Первое, что нужно сделать для отрисовки сцены — загрузить модели в память. Наша игра загружает карту, которая содержит ссылки на ассеты с моделями. Всё это хранится в оперативной памяти. Также наша игра отсылает данные о моделях на видеокарту в память GPU.
Когда все ресурсы созданы на GPU, шейдера скомпилированы — можно что-то и отрендерить.
В интерактивной демке мы специально вставили несколько слайдов, чтобы продемонстрировать процесс загрузки моделей, а также то, что геометрия на этом этапе представляет собой не ту модель, которую вы импортировали в движок. Хотим уточнить, что ресурсы загружаются один раз и не стоит обновлять их каждый фрейм.
Когда все ресурсы загружены, можно приступать к отрисовке сцены. Отсылать на отрисовку всё, что есть в сцене — плохая идея, так как мы можем быстро потратить все вычислительные ресурсы GPU. Что же делать? В действие вступают техники Куллинга (Culling). Мы не расскажем здесь, как работает куллинг и не будем приводить разные варианты его реализации, поговорим только о его разновидностях. В текущем кадре у нас есть камера, которой мы задали позицию, ориентацию в пространстве и собственно она и определяет, что мы увидим на экране. Понятно, что на GPU нужно отсылать только то, что мы можем увидеть. Мы хотели бы остановится на двух видах кулинга: это Frustum Culling, который определяет, какие объекты находятся в пределах кадра:
Второй вид куллинга — Occlusion Culling. Даже когда объект находится в камере, он может быть закрыт другими объектами. На кадре ниже мы можем увидеть, что цилиндр, который в некоторых моментах находится за сферой, можно не отсылать на отрисовку. В то же самое время, маленький цилиндр за конусом — нет, потому что конус — прозрачный объект.
После куллинга, который происходит на CPU, на выходе появляется список объектов, которые нужно отрисовать. Если точнее — это списки прозрачной и непрозрачной геометрии.
Одна из техник, которую зачастую используют перед рендерингом кадра — z-prepass. Идея в том, чтобы отрисовать непрозрачную часть сцены сначала в z-buffer, не используя пиксельный шейдер. Таким образом, запись в z-buffer можно будет отключить для следующих пасов. Это позволит избежать ситуации, когда мы вычисляем цвет пикселя, который впоследствии будет перезаписан. В такой простой сцене эта техника не окупит себя, но вот в более сложных сценах без неё не обойтись.
Вот мы и подошли к моменту, когда начинаем отправлять геометрию на отрисовку. Но перед этим давайте разберем отличия между Forward Renderer и Deferred Renderer.
Forward Renderer появился раньше. Его идея была достаточно проста: для каждого объекта на экране выставлялись сразу все параметры (источники света, дополнительные параметры), и каждый объект рисовали за один раз. Всё было хорошо, если бы не сложность отрисовки, разные вариации шейдеров для разных материалов, разные виды источников света. Чтобы хоть как-то ускорить этот процесс, придумали Deferred Renderer. Его идея состоит в том, чтобы отложить процесс шейдинга/освещения на более поздние этапы конвейера. Deferred Renderer происходит в два прохода. В первом проходе мы сохраняем все параметры материалов в массив текстур, который называется GBuffer (когда-то возможность рендеринга в несколько текстур сразу была невозможна, Multiple Render Targets или MRT). Во втором проходе эти параметры декодируются из GBuffer и используются для вычисления освещения.
Какие же плюсы и минусы использования каждой из техники? Для Deferred Renderer требуется возможность рендерить сразу в несколько текстур, он использует больше памяти под GBuffer , например, UE4 использует 7 текстур для GBuffer (GBufferA – GBufferE, GBufferVelocity + еще одна дополнительная текстура), но он должен быть быстрее за счет вынесения освещения в отдельный проход. Тем не менее, при рендеринге прозрачных объектов всегда используется Forward Renderer.
Так что же лучше? Сейчас в пользу использования Forward Renderer указывают только ограничения GPU (если нету поддержки MRT) или ограничение по памяти. Его обычно используют на мобильных устройствах, да и Opengl ES2 не поддерживает MRT. UE4 использует Forward Renderer для мобильных устройств, хотя есть возможность переключиться на Deferred Renderer при использовании Metal или ES3.1.
Продолжаем рендеринг
Разобравшись с отличиями этих подходов рендеринга, давайте продолжим рендерить нашу сцену. В целях экономии времени, мы не будем повторять одни и те же этапы для каждого прохода, а опишем лишь различия между ними. Для Forward Renderer сначала рендерим все непрозрачные объекты один за другим:
Deferred Renderer: записываем всю информацию из материалов в GBuffer . Для удобства в демо мы используем разные проходы, хотя все текстуры рендерятся за один раз. Также мы проиллюстрировали только самые важные текстуры в GBuffer .
Deferred Renderer: после того как наш GBuffer сформирован, мы вычисляем освещение для каждого пикселя.
Одним из недостатков Deferred Renderer является невозможность его работы с прозрачной геометрией, из-за чего приходится рендерить её, используя Forward Renderer. Это связано с тем, что каждый пиксель в GBuffer может хранить информацию только про один материал, а с прозрачной геометрией нам нужно знать еще и цвет пикселя под текущим объектом. Прозрачную геометрию обычно сортируют по дистанции перед рендером (от самой дальней к самой ближней точке) для достижения правильного наложения объектов друг на друга на экране. Хотя такой подход и не гарантирует сортировку на уровне пикселей, но фактически эффективнее пренебречь этой дорогой операцией для прозрачной геометрии.
Основная картинка готова, но нужно добавить еще щепотку пост процессов и интерфейса по вкусу.
В нашем демо представлено 2 постпроцесса: Bloom и DoF (Depth Of Field). Оба эффекта отображают процессы, которые происходят в камере и добавляют реалистичности финальной сцене.
Основным отличием отрисовки пост-процесса от рендера геометрии является то, что он работает в экранном пространстве (которое является двумерным). Мы используем специальную геометрию, которая уже находится в экранном пространстве, таким образом, наш вершинный шейдер ничего не делает, а просто передает вершины дальше для растеризации.
Начнём с Bloom (свечение). Он по своей природе является артефактом, появляющемся в камерах в реальном мире. Суть его в том, что наиболее яркие участки изображения размываются для получения эффекта Гало и накладываются поверх уже отрендеренного кадра.
Глубина резкости — тоже артефакт, который появляется в камерах, и направлен он для достижения реалистичности. Для его реализации движок, так же как и в случае с Bloom, размывает отрендеренный кадр, получая таким образом для каждого пикселя экрана два его состояния: когда он находится в фокусе и когда нет, но это только его самые крайние состояния. Чтобы вычислить финальный цвет пикселя, нужно вычислить, насколько он должен быть размыт в зависимости от расстояния до точки фокуса и размера региона фокуса.
В UE4 все эти постпроцессы уже реализованы и их нужно только настроить по своему усмотрению.
Вот мы и рассмотрели все важные этапы конвейера рендера. Надеемся, что вы узнали для себя что-то новое или поняли принцип работы того, о чем уже знали. Начиная со следующей статьи, весь материал будет тесно связан с UE4 и будет требовать понимания написанного в этой статье, так что рекомендуем еще раз почитать те моменты, которые могли остаться непонятными после первого прочтения. Спасибо и до встречи в следующий раз!
Как отличить настоящее фото актера от рендера из The Callisto Protocol?
Пользователь реддита с ником NixothePaladin выложил для сравнения два изображения: модель персонажа из игры The Callisto Protocol и фото актера Джоша Дюамеля. Качество графики оказалось настолько высоким, что пользователи решили, что перед ними два одинаковых фото. Разбираемся, как такое возможно.
Как видите, фото и правда практически невозможно отличить от рендера. В комментариях сразу высказали сомнения, что автор просто шутит и выставил два одинаковых фото. Но нет, это не так.
Справа действительно фото актера, а слева — трехмерная модель на Unreal Engine.
Пользователь Disco_Pancake предложил скосить глаза, глядя на картинку, как будто вы рассматриваете стереоизображение. Так разница становится чуть более очевидной: глаза, ресницы, блики под носом и контур ушей слегка отличаются. Компьютерная модель чуть менее резкая, чем фото, — но все это скорее нюансы, чем реальные различия, два изображения почти идентичны. Как такое может быть?
Во-первых, Unreal Engine действительно мощный, и ему под силу выдавать фотореалистичные кадры Еще одно изображение из The Callisto Protocol. Справа — фото, слева — рендер. . Во-вторых, это все-таки не модель из самой игры, а статичное изображение, приведенное к максимальному соответствию с фото.
Но и непосредственно в геймплее нас ждет впечатляющее качество изображения. Уже в Dead Space, вышедшей почти 15 лет назад, были моменты полного фотореализма. Темные коридоры выглядели практически идеально — 3D-художники давно научились прятать огрехи дизайна в тенях. За прошедшие годы технологии значительно шагнули вперед.
В ролике Ars Technica авторы говорят, что свет и звук — это 80% успеха любого хоррора. Громадное внимание уделяется освещению: в первую очередь разработчики занимаются им, а только потом настраивают все остальное. Так авторы заранее исключают ситуацию, когда уровень полностью собран, а правильно осветить его забыли — тогда приходится в последний момент доводить дизайн, получается тяп-ляп, атмосфера мгновенно выветривается. В The Callisto Protocol такого точно не случится.
Отдельно нужно отметить скафандр героя: в духе фильма «Прометей» 
, он устроен так, что лицо персонажа всегда освещено 
. То есть сам герой — это источник света, разгоняющий мрак жуткой космической тюрьмы. Не терпится увидеть его в деле , и ждать осталось совсем недолго: The Callisto Protocol выходит уже 2 декабря.