Рубрика «рендеринг» - 3

в 14:50, , рубрики: nvidia nsight, PIX, renderdoc, Дизайн игр, Игры и игровые приставки, конвейер рендеринга, Работа с 3D-графикой, разработка игр, рендеринг, рендеринг трёхмерной графики
image

Предисловие

После выхода последней игры из серии «Метро» я потратил несколько часов на изучение её внутренней работы и решил поделиться тем, что может показаться интересным с технологической точки зрения. Я не буду проводить подробный анализ или изучать дизассемблированный код шейдеров, а покажу высокоуровневые решения, принятые разработчиками в процессе создания игры.

На данный момент разработчики ещё не рассказывали об использованных в игре техниках рендеринга. Единственным официальным источником информации является доклад с GDC, который нельзя больше найти нигде в Интернете. И это досадно, ведь игра работает на очень интересном собственном движке, эволюционировавшем из предыдущих игр серии «Метро». Это одна из первых игр, в которых используется DXR.

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

Первые шаги

На поиск среды, способной работать с этой игрой, у меня ушло несколько дней. Протестировав несколько версий RenderDoc и PIX, я остановился на изучении результатов трассировки лучей с помощью Nvidia NSight. Я хотел изучать рендеринг без функций raytracing, но NSight позволял исследовать подробности и этой функции, поэтому я решил оставить её включённой. Для всего остального рендеринга вполне подошёл PIX. Скриншоты сделаны с помощью обоих приложений.
Читать полностью »

в 9:45, , рубрики: naughty dog, Physically Based Shading, Unreal Engine, Дизайн игр, освещение, Работа с 3D-графикой, рендеринг

Джои Ленц из Naughty Dog подробно рассказал нам об освещении в UE4: о значениях, источниках, световой температуре, освещении в PBR, ресурсах, по которым можно изучать освещение, а также обо многом другом. На официальном сайте Джои polyplant.co есть множество полезных советов о работе с освещением.

Энциклопедия освещения художника Naughty Dog - 1

Про PBR

PBR (physically-based rendering, основанный на физике рендеринг) благодаря использованию замеренных данных реального мира предоставляет удобные средства для создания материалов/освещения с предсказуемыми, неизменными результатами при разных условиях освещения. Для студий разработки игр это означает, что их художники могут тратить меньше времени на итерации создания контента и его переработку для создания «корректного» внешнего вида в разных уровнях. В свою очередь, это экономит студиям деньги. На освоение PBR художникам, привыкшим к старым методологиям, потребуется какое-то время. Иногда сложнее всего им избавиться от привычки добавления в albedo-текстуры информации об освещении/затенении. Однако как только они освоятся с этим рабочим процессом, то быстро понимают, что им гораздо проще управлять, чем традиционными средствами рендеринга текстур.
Читать полностью »

в 8:55, , рубрики: chromium, discard, hibernate, Алгоритмы, Блог компании Яндекс, браузеры, интерфейсы, оптимизация программ, производительность javascript, Разработка веб-сайтов, рендеринг, слои, тайлинг, тайлы, яндекс.браузер

Несмотря на рост производительности устройств, веб становится всё более требовательным к памяти и процессору. Правильный рендеринг и умное распределение ресурсов по вкладкам — важная часть решения этой проблемы. Константин Крамлих посвятил своё выступление на конференции «Я Frontend» алгоритмам, которые улучшают производительность и экономят ресурсы как в проекте Chromium, так и в Яндекс.Браузере.

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

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

— Меня зовут Костя, я руководитель группы разработки внутренних компонентов в команде Яндекс.Браузера. В Браузере я чуть больше пяти лет, занимался разными вещами: от всего декодирования в браузере, всех HTML5-видео, до отрисовки, рендеринга и других подобных процессов.

Читать полностью »

в 8:26, , рубрики: gpu, Tomb Raider, Дизайн игр, игровые движки, конвейер рендеринга, Работа с 3D-графикой, разработка игр, реверс-инжиниринг, рендеринг
Как рендерится кадр Rise of the Tomb Raider - 1

Rise of the Tomb Raider (2015 год) — это сиквел превосходного перезапуска Tomb Raider (2013 год). Лично я нахожу обе части интересными, потому что они отошли от стагнирующей оригинальной серии и рассказали историю Лары заново. В этой игре, как и в приквеле, центральное место занимает сюжет, она предоставляет увлекательные механики крафтинга, охоты и скалолазания/исследований.

В Tomb Raider использовался разработанный Crystal Dynamics движок Crystal Engine, также применявшийся в Deus Ex: Human Revolution. В сиквеле использовали новый движок под названием Foundation, ранее разрабатывавшийся для Lara Croft and the Temple of Osiris (2014 год). Его рендеринг можно в целом описать как тайловый движок с предварительным проходом освещения, и позже мы узнаем, что это означает. Движок позволяет выбирать между рендерерами DX11 и DX12; я выбрал последний, по причинам, которые мы обсудим ниже. Для захвата кадра использовался Renderdoc 1.2 на Geforce 980 Ti, в игре включены все функции и украшательства.

Анализируемый кадр

Как рендерится кадр Rise of the Tomb Raider - 2

Чтобы не было спойлеров, скажу, что в этом кадре плохие парни преследуют Лару, потому что она ищет артефакт, который разыскивают и они. Этот конфликт интересов никак не разрешить без оружия. Лара ночью пробралась на вражескую база. Я выбрал кадр с атмосферным и контрастным освещением, при котором движок может показать себя.Читать полностью »

в 7:41, , рубрики: adminhtml, Magento, magento 2, UI, рендеринг

Выход версии 2.3.0 приблизил использование PWA на фронте Magento-приложений на расстояние вытянутой руки. И если для фронта видны какие-то подвижки в применяемых технологиях, то с админкой всё гораздо стабильнее — старый добрый лабиринт из различных типов файлов, которые нужно поредактировать, чтобы на UI проявилось что-то полезное, усовершенствовать не планируется. В этой статье я описываю создание собственного рендерера для колонки грида в админке — вещи довольно несложной и, в то же самое время, довольно полезной при правильном применении. Например, рендерер для формирования в гриде заказов ссылки на карточку клиента, оформившего заказ:

image

Читать полностью »

в 8:55, , рубрики: 3d, Gamedev, unity, unity3d, Анализ и проектирование систем, архитектура, Блог компании Pixonic, геймдев, доклад, конференции, митап, мобильные игры, проектирование, производительность, разработка игр, рендеринг, юнити

Мы в компании давно работаем с Unity и не могли не пригласить их ребят на Pixonic DevGAMM Talks, который был в сентябре. Field Engineer Валентин Симонов рассказал, как планировать архитектуру игр с учетом преимуществ новых технологий. Unity работает над ними уже несколько лет, чтобы добиться недостижимого ранее уровня производительности. Послушать выступление можно на YouTube, а почитать расшифровку со слайдами — сразу под катом.

Читать полностью »

в 6:34, , рубрики: playstation 4, raycasting, raytracing, spiderman, Работа с 3D-графикой, разработка игр, рендеринг
Иллюзия пространства: как новый Spiderman рендерит помещения без геометрии - 1

В недавно выпущенной игре Marvel's Spider-Man во многих зданиях за окнами есть интерьеры. Они выглядят замечательно, но похоже, что их реализовали с помощью хитрого рендеринга — геометрии интерьеров на самом деле не существует и она сгенерирована шейдером. Я не видел никаких официальных заявлений Insomniac о том, как они это сделали, но исходя из того, как выглядит эффект, здесь с большой вероятностью реализована техника interior mapping, которую я придумал в 2007 году в процессе работы над диссертацией. Раньше я не писал о ней в блоге, поэтому сейчас подходящий момент для объяснения любопытного небольшого шейдера, который я придумал.

Давайте начнём с просмотра геймплея Marvel's Spider-Man. Игра выглядит просто потрясающе. Сайт Kotaku записал отдельный ролик, посвящённый окнам:

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

в 12:12, , рубрики: disney, pbrt, Компьютерная анимация, моана, Работа с 3D-графикой, рендерер, рендеринг
image

У меня есть ветка pbrt, которую я использую для проверки новых идей, реализации интересных мыслей из научных статей и в целом для исследования всего того, что в результате обычно оказывается в новой редакции книги Physically Based Rendering. В отличие от pbrt-v3, который мы стремимся сохранять как можно ближе к описанной в книге системе, в этой ветке мы можем менять что угодно. Сегодня мы увидим, как более радикальные изменения системы позволят значительно снизить использование памяти в сцене с островом из диснеевского мультфильма «Моана».

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

При рендеринге последней островной сцены из «Моаны» для хранения описания сцены pbrt-v3 использовал 81 ГБ ОЗУ. На текущий момент pbrt-next использует 41 ГБ — примерно в два раза меньше. Для получения такого результата достаточно было небольших изменений, вылившихся в несколько сотен строк кода.
Читать полностью »

в 12:02, , рубрики: disney, pbrt, Компьютерная анимация, моана, Работа с 3D-графикой, рендерер, рендеринг
image

Сегодня мы рассмотрим ещё два места, в которых pbrt тратит много времени при парсинге сцены из диснеевского мультфильма «Моана». Посмотрим, удастся ли и здесь улучшить производительность. На этом мы закончим с тем, что разумно делать в pbrt-v3. Ещё в одном посте я буду разбираться с тем, насколько далеко мы можем зайти, если откажемся от запрета на внесение изменений. При этом исходный код будет слишком отличаться от системы, описанной в книге Physically Based Rendering.

Оптимизация самого парсера

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

Я наконец-то собрался с силами и реализовал написанный вручную токенизатор и парсер для сцен pbrt. Формат файлов сцен pbrt парсить довольно просто: если не учитывать закавыченных строк, токены разделяются пробелами, а грамматика очень прямолинейна (никогда не возникает потребности заглядывать вперёд дальше, чем на один токен), но собственный парсер — это всё равно тысяча строк кода, которые нужно написать и отладить. Мне помогло то, что его можно было протестировать на множестве сцен; после исправления очевидных сбоев я продолжал работу, пока мне не удалось отрендерить в точности те же изображения, что и раньше: не должно возникать никаких различий в пикселях по причине замены парсера. На этом этапе я был абсолютно уверен, что всё сделано верно.
Читать полностью »

в 12:10, , рубрики: disney, pbrt, Компьютерная анимация, моана, Работа с 3D-графикой, рендерер, рендеринг
image

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

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

Память
BVH-дерево 9,01 ГиБ
Кривые 1,44 ГиБ
MIP-текстуры 2,00 ГиБ
Меши треугольников 11,02 ГиБ

Что касается времени выполнения, то встроенная статистика оказалась краткой и выдала отчёт только о выделении памяти под известные объекты размером в 24 ГБ. top сообщил, что на самом деле использовано около 70 ГБ памяти, то есть в статистике не учтено 45 ГБ. Небольшие отклонения вполне объяснимы: распределителям динамической памяти требуется дополнительное место для регистрации использования ресурсов, часть теряется из-за фрагментации, и так далее. Но 45 ГБ? Здесь определённо скрывается что-то нехорошее.
Читать полностью »

1...234...7
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js