Я хотел бы поделиться воспоминаниями о своих попытках сделать «3D графический движок» «своими руками» практически в до-интернетную эпоху (он как бы уже где-то там конечно был, но у меня его фактически не было). Никакую Америку открыть не удалось, революции тоже не случилось, но было много старания, мучений и фана. С годами память о многих событиях стирается, исчезают детали, тускнеют впечатления — при многочисленных переездах коробка с дискетами были потеряна и никаких артефактов от описываемых событий не осталось.

Общие примечания

Все результаты получены на довольно старой машине (i7 3770+GTX 770), игра запускалась в DirectX 11 со средним качеством. Для анализа использовались RenderDoc и Nsight.

Игра работает на движке Re Engine, ставшем наследником MT Framework — движка предыдущего поколения Capcom R&D. Кроме RE2 он используется в DMC5 и RE7:Biohazard.

Мне не удалось найти в Интернете материалов о RE Engine, поэтому всё в статье основано на догадках (надеюсь, обоснованных). Я рассмотрел примерно 90% структуры кадра и привёл общее описание алгоритмов. Дальнейшее исследование требует большего опыта и времени на реверс-инжиниринг шейдеров.

Вступление

Мне кажется, что нам надо использовать меньше тригонометрии в компьютерной графике. Хорошее понимание проекций, отражений и векторных операций (как в истинном значении скалярного (dot) и векторного (cross) произведений векторов) обычно приходит с растущим чувством беспокойства при использовании тригонометрии. Точнее, я считаю, что тригонометрия хороша для ввода данных в алгоритм (для понятия углов это интуитивно понятный способ измерения ориентации), я чувствую, что что-то не так, когда вижу тригонометрию, находящуюся в глубинах какого-нибудь алгоритма 3D-рендеринга. На самом деле, я думаю, что где-то умирает котенок, когда туда закрадывается тригонометрия. И я не так беспокоюсь о скорости или точности, но с концептуальной элегантностью я считаю… Сейчас объясню.

Этот туториал посвящён интерактивным картам и их созданию в Unity при помощи шейдеров.

Этот эффект может служить основой более сложных техник, например голографических проекций или даже песочного стола из фильма «Чёрная пантера».

Источником вдохновения для этого туториала стал опубликованный Baran Kahyaoglu твит, демонстрирующий пример того, что он создаёт для Mapbox.

Все мы изучали в курсе математики численные методы. Это такие методы, как интегрирование, интерполяция, ряды и так далее. Существует два вида числовых методов: детерминированные и рандомизированные.

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

Раньше облака в играх рисовались обычными 2D спрайтами, которые всегда повернуты в направлении камеры, но последние годы новые модели видеокарт позволяют рисовать физически корректные облака без заметных потерь в производительности. Считается, что объемные облака в игры принесла студия Guerrilla Games вместе с игрой Horizon Zero Dawn. Конечно, такие облака умели рендерить и раньше, но студия сформировала что-то вроде промышленного стандарта на исходные ресурсы и используемые алгоритмы, и в настоящее время любая реализация объемных облаков так или иначе этому стандарту соответствует.

UPD. Картинка обновлена. Изменения описаны в конце статьи.

Иногда отражение в зеркале более реально, чем сам объект…
— Льюис Кэрролл (Алиса в зазеркалье)

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

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

Приглашаю и Вас окунуться со мной в мир отражений.

В этой статье мы исследуем важную концепцию, используемую в недавно выпущенной платформе Lighthouse 2. Wavefront path tracing, как её называют Лейн, Каррас и Аила из NVIDIA, или streaming path tracing, как она изначально называлась в магистерской диссертации ван Антверпена, играет важнейшую роль в разработке эффективных трассировщиков пути на GPU, а потенциально и трассировщиков пути на CPU. Однако она довольно контринтуитивна, поэтому для её понимания необходимо переосмыслить алгоритмы трассировки лучей.

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


Какое-то время назад этот пост появился на главной странице Hacker News. Его обсуждение можно прочитать здесь.

Введение

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

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

• Упаковка и покрытие
• Выпуклые оболочки, ячейки Вороного и треугольники Делоне
• Ядра $$-энергии Риса
• Кубатура и определители

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

Ради краткости в этом посте мы рассмотрим только два критерия: минимальное расстояние упаковки и выпуклую оболочку/сетку Делоне (объём и площадь).

Модели, нормали и развертка

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

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

В этой части мы рассмотрим модели, развертку и нормали. Создадим текстуры для первой полноценной модели (хоть и простой) и настроим ее в Unreal Engine 4.

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

Часть 1. Пиксель здесь.
Часть 2. Маски и текстуры здесь.
Часть 3. PBR и Материалы здесь.
Часть 4. Модели, нормали и развертка — вы ее читаете.
Часть 5. Система материалов здесь.

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

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

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

Недавно я столкнулся лицом к лицу с таким зверем как Autodesk Maya. За плечами у меня не было опыта в работе с 3Д моделированием и пришлось в экстренном порядке прокачиваться, начиная с основ, а также ознакомится с функциональностью данного ПО, чтобы проверить работу плагина (QA), который экспортил всё содержимое сцены в определенный формат. Эта статья рассчитана на людей без опыта либо с минимальным в Autodesk Maya и призвана познакомить вас с полезными функциями и редакторах, которые можно в ней найти. Если же вы не нашли функцию/редактор, который считаете полезным, то либо я с ним еще не работал, либо он не пригодился для моих нужд. Расскажите о них и о реальных случаях их применения в комментариях :-)

Статья разделена на секции, каждая из которых относится к одному из аспектов 3Д модели:

1. Общие инструменты
2. Работа с геометрией (полигональной сеткой)
3. Работа с текстурами
4. Работа с анимацией
5. Shelf Editor, Shelves и немного о MEL (Maya Embedded Language)

В прошлой части тутора мы разобрали принцип работы масок, что такое «текстура», и что абсолютно для всего используются каналы — параметры пикселя. Теперь рассмотрим всеми любимый PBR И соберем текстуры для создания мокрого грязного асфальта.

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

Также, если что-то совсем будет не понятно — очень прошу сообщить об этом, чтобы я мог раскрыть эту тему более подробно.

Часть 1. Пиксель здесь
Часть 2. Маски и текстуры здесь
Часть 3. PBR и Материалы — вы ее читаете.
Часть 4. Модели, нормали и развертка здесь.
Часть 5. Система материалов здесь.

В этой статье представлена реализация на Python алгоритма распознавания источников освещения на картах окружения (LDR или HDR) при помощи равнопромежуточной проекции (equirectangular projection). Однако после внесения незначительных изменений её также можно использовать с простыми фоновыми изображениями или кубическими картами. Примеры возможного применения алгоритма: программы трассировки лучей, в которых требуется распознавать первичные источники освещения для испускания из них лучей; в растеризованных рендерерах он может применяться для отбрасывания теней, использующих карту окружения; кроме того, алгоритм также можно применять в программах устранения засветов, например в AR.

Алгоритм состоит из следующих этапов:

1. Снижение разрешения исходного изображения, например, до 1024.
2. Преобразование изображения в яркость (luminance), при необходимости с размытием изображения.
3. Применение метода квази-Монте-Карло.
4. Преобразование из сферических координат в равнопромежуточные.
5. Фильтрация сэмплов на основании яркости соседа.
6. Сортировка сэмплов на основании их яркости.
7. Фильтрация сэмплов на основании евклидовой метрики.
8. Слияние сэмплов при помощи алгоритма Брезенхэма.
9. Вычисление позиции кластера освещения на основании его яркости.

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

  lum = img[:, :, 0] * 0.2126 + img[:, :, 1] * 0.7152 + img[:, :, 2] * 0.0722

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

[Программист анимаций компании Remedy Хенрик Энквист рассказал, как его команда создала убедительную симуляцию твидового пиджака главного героя игры в жанре хоррор-триллер Alan Wake.]

Главный персонаж нашего экшн-триллера — Алан Уэйк, писатель, попавший в кошмар, где он вынужден сражаться с тёмными силами и решать загадку исчезновения жены. Он не хорошо подготовленный герой боевика, а обычный человек.

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

Чтобы передать иллюзию атмосферы триллера, пиджак Алана Уэйка должен быть как можно более правдоподобным. Пиджак должен развеваться на ветру и добавлять персонажу вспомогательные движения при перемещении по лесу. Как программист, я сразу же начал думать об использовании симуляции ткани.

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

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

Приветствую вас.

Недавно мне на работе довелось протестировать 3д-сканер от компании Hewlett Packard – HP 3D Structured Light Scanner Pro S3. Поэтому я решил поделиться с вами своим опытом его использования. Данный сканер работает по технологии структурированного света SLS. Суть технологии такова, на объект сканирования проецируются различные изображения-шаблоны с помощью обычного LED-DLP проектора. А камера, установленная рядом фиксирует полученные искаженные изображения. После чего специальная программа по этим искажениям оценивает форму, глубину, детали объекта и пересчитывает все эти данные в трехмерное изображение.

Ручная сегментация легких занимает около 10 минут и требуется определенная сноровка, чтобы получить такой же качественный результат, как при автоматической сегментации. Автоматическая сегментация занимает около 15 секунд.

Я предполагал, что без нейронной сети удастся получить точность не выше 70%. Также я предполагал, что морфологические операции – это только подготовка изображения к более сложным алгоритмам. Но в результате обработки тех, хоть и немногочисленных 40 образцов томографических данных, что есть на руках, алгоритм выделил легкие без ошибок, причём после теста на первых пяти случаях алгоритм уже не претерпевал значительных изменений и с первого применения правильно отработал на остальных 35 исследованиях без изменения настроек.

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

О статье

Этот пост — небольшая заметка, предназначенная для программистов, которым хочется больше узнать о том, как GPU обрабатывает ветвление. Можно считать её введением в эту тему. Рекомендую для начала просмотреть [1], [2] и [8], чтобы получить представление о том, как в общем виде выглядит модель выполнения GPU, потому что мы будем рассматривать только одну отдельную деталь. Для любопытных читателей в конце поста есть все ссылки. Если найдёте ошибки, то свяжитесь со мной.

Содержание

• О статье
• Содержание
• Словарь
• Чем ядро GPU отличается от ядра ЦП?
• Что такое согласованность/расхождение?
• Примеры обработки маски выполнения
  • Выдуманная ISA
  • AMD GCN ISA
  • AVX512
• Как бороться с расхождением?
• Ссылки

Всем хорошего настроения и температуры за окном пониже. Как и обещал, публикую продолжение статьи по супер-пупер современному OpenGL. Кто не читал первую часть — Суперсовременный OpenGL. Часть 1.

Возможно повезет и я смогу весь оставшийся материал впихнуть в эту статью, это не точно…

Всем привет. В этот раз мне хотелось бы затронуть тему разработки компьютерных игр, показать некоторые идеи и прототипы. Конкретно в этой статье речь пойдёт о проектах и набросках, вдохновлённых игрой Вангеры, она же Vangers: One For The Road. Пристёгивайтесь поудобнее, трюм полон интересностей, спираль заряжена, поехали.



Продолжение, часть вторая: Невангеры: Road is changed
Часть третья: Spice must flow
Часть четвёртая: Feed for speed
Часть пятая: Division impossible