Привет, Хабр!

Как законодатели мод по теме Unity на российском рынке предлагаем вам почитать интересное исследование о практическом использовании алгоритма WFC (Wave Function Collapse), построенного по образу и подобию известного принципа квантовой механики и очень удобного при процедурной генерации уровней в играх. Ранее на Хабре уже публиковался подробный рассказ об этом алгоритме. Автор сегодняшней статьи Мариан Кляйнеберг рассматривает алгоритм в контексте трехмерной графики и генерации бесконечного города. Приятного чтения!

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


Рисунок 1. Сравнение различных квазислучайных последовательностей с низким расхождением. Заметьте, что предлагаемая мной $$-последовательность создаёт более равномерно распределённые точки, чем все остальные методы. Более того, все остальные методы требуют тщательного подбора базовых параметров, а в случае неправильного подбора приводят к вырожденности (например справа вверху)

Рассматриваемые в статье темы

• Последовательности с низким расхождением в одном измерении
• Методы с низким расхождением в двух измерениях
• Расстояние упаковки
• Множества с многоклассовым низким расхождением
• Квазислучайные последовательности на поверхности сферы
• Квазипериодический тайлинг плоскости
• Маски дизеринга в компьютерной графике

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

При записи во фреймбуфер значения яркости цветов приводятся к интервалу от 0.0 до 1.0. Из-за этой, на первый вгляд безобидной, особенности нам всегда приходится выбирать такие значения для освещения и цветов, чтобы они вписывались в это ограничение. Такой подход работает и даёт достойные результаты, но что случится, если мы встретим особенно яркую область с большим количеством ярких источников света, и суммарная яркость превысит 1.0? В результате все значения, большие чем 1.0, будут приведены к 1.0, что выглядит не очень красиво:

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

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

Дисплей компьютера способен показывать цвета с яркостью в диапазоне от 0.0 до 1.0, но у нас нет такого ограничения при расчёте освещения. Разрешая цветам фрагмента быть ярче единицы, мы получаем намного более высокий диапазон яркости для работы — HDR (high dynamic range). С использованием hdr яркие вещи выглядят яркими, тёмные вещи могут быть реально тёмными, и при этом мы будем видеть детали.

Кубические карты

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

Кубическая карта, по сути, является одним текстурным объектом, содержащим 6 отдельных двухмерных текстур, каждая из которых соотносится со стороной оттекстурированного куба. Зачем может пригодиться такой куб? Зачем сшивать шесть отдельных текстур в одну карту вместо использования отдельных текстурных объектов? Суть в том, что выборки из кубической карты можно совершать используя вектор направления.

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

За последние десять лет через меня прошло много начинающих разработчиков. Да и чего греха таить, я тоже когда-то был начинающим разработчиком. За это время я получил тысячи вопросов а-ля “как стать разработчиком”, а также просьб взять людей к себе на практику. К сожалению, даже под чутким руководством более опытных специалистов, далеко не каждому хватает сил и мотивации перейти на качественно новый уровень. Статистика — вещь упрямая: количество “пытающихся” и “достигающих успеха” распределяется согласно принципу Парето, т.е. 20/80, где из десяти человек максимум двоим удается пройти первоначальное испытание. Остальные отваливаются по дороге или процесс обучения у них растягивается на долгие годы. И все же, каким должен быть начинающих разработчик, какими навыками и знаниями он должен обладать? Об этом и пойдет речь в статье.

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

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

Middle Earth: Shadow of Mordor была выпущена в 2014 году. Сама игра стала большим сюрпризом, и то, что она была спин-оффом сюжетной линии вселенной «Властелина кольца» оказалось довольно неожиданным. Игра обрела большой успех, и на момент написания статьи компания Monolith уже выпустила сиквел — Shadow of War. Графика игры очень красива, особенно учитывая то, что она была выпущена для разных поколений консолей, в том числе Xbox 360 и PS3. Версия для PC довольно хорошо отполирована, содержит дополнительные графические опции и пакеты текстур высокого разрешения, полностью раскрывающие потенциал игры.

В игре используется относительно новый отложенный рендерер DX11. Я воспользовался Renderdoc, чтобы глубоко изучить приёмы рендеринга игры. При работе использовались максимально возможные параметры графики (ultra) и были включены все возможные «примочки», такие как независимая от порядка прозрачность, тесселяция, окклюзия в экранном пространстве и различные motion blur.

«Нет ничего хуже чёткого образа размытой концепции». – фотограф Энсел Адамс

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

Основываясь на уже имеющемся у нас коде, мы итеративно решим уравнение рендеринга, сформулированное Джеймсом Каджия в 1986 году и преобразуем наш рендерер в трассировщик пути, способный передавать вышеупомянутые эффекты. Мы снова будем использовать C# для скриптов и HLSL для шейдеров. Код выложен на Bitbucket.

В предыдущем уроке был дан обзор основам реализации физически правдоподобной модели рендеринга. В этот раз мы перейдем от теоретических выкладок к конкретной реализации рендера с участием непосредственных (аналитических) источников света: точечных, направленных или прожекторного типа.

Привет, друг! В этот раз я опять подниму вопрос о графике в ААА-играх. Я уже разобрал методику HDRR (не путать с HDRI) тут и чуть-чуть поговорил о коррекции цвета. Сегодня я расскажу, что такое SSLR (так же известная как SSPR, SSR): Screen Space Local Reflections. Кому интересно — под кат.

Физически-корректный рендеринг

PBR, или физически-корректный рендеринг (physically-based rendering) это набор техник визуализации, в основе которых лежит теория, довольно хорошо согласующаяся с реальной теорией распространения света. Поскольку целью PBR является физически достоверная имитация света, он выглядит гораздо более реалистичным по сравнению с использованными нами ранее моделями освещения Фонга и Блинна-Фонга. Он не только лучше выглядит, но и дает неплохое приближение к реальной физике, что позволяет нам (и в частности художникам) создавать материалы, основанные на физических свойствах поверхностей, не прибегая к дешевым трюкам дабы заставить освещение выглядеть реалистично. Главным преимуществом такого подхода является то, что создаваемые нами материалы будут выглядеть как задумано независимо от условий освещения, чего нельзя сказать о других, не PBR подходах.

SSAO

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

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

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


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

Однажды, разглядывая очередную демку с эффектом, возник вопрос: а можно ли сделать SSAO на мобильном девайсе так, чтобы и выглядело хорошо и не тормозило?
В качестве устройства был взят Galaxy Note 3 n9000 (mali T62), цель — фпс не ниже 30, а качество должно быть как на картинке выше.

Тень — это отсутствие света. Если лучи от источника света не попадают на объект, так как поглощаются другим объектом, то первый объект находится в тени. Тени добавляют реализма к изображению и дают увидеть взаимное расположение объектов. Благодаря ним сцена приобретает "глубину". Сравните следующие изображения сцены с тенями и без:

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

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

Один из методов — карты теней (shadow maps) — относительно простой в реализации, используется в большинстве видеоигр и даёт достойные результаты. Карты теней не так уж и трудно понять, они довольно дёшевы с точки зрения производительности и их легко улучшить до более продвинутых алгоритмов (типа теней от точечного источника света или каскадных карт теней)

В предыдущих статьях мы использовали прямое освещение (forward rendering или forward shading). Это простой подход, при котором мы рисуем объект с учётом всех источников света, потом рисуем следующий объект вместе с всем освещением на нём, и так для каждого объекта. Это достаточно просто понять и реализовать, но вместе с тем получается довольно медленно с точки зрения производительности: для каждого объекта придётся перебрать все источники света. Кроме того, прямое освещение работает неэффективно на сценах с большим количество перекрывающих друг друга объектов, так как большая часть вычислений пиксельного шейдера не пригодится и будет перезаписана значениями для более близких объектов.

Отложенное освещение или отложенный рендеринг (deferred shading или deferred rendering) обходит эту проблему и кардинально меняет то, как мы рисуем объекты. Это даёт новые возможности значительно оптимизировать сцены с большим количеством источников света, позволяя рисовать сотни и даже тысячи источников света с приемлемой скоростью. Ниже изображена сцена с 1847 точечными источниками света, нарисовання с помощью отложенного освещения (изображение предоставил Hannes Nevalainen). Что-то подобное было бы невозможно при прямом расчёте освещения:

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

Концепция кватернионов была придумана ирландским математиком сэром Уильямом Роуэном Гамильтоном в понедельник 16 октября 1843 года в Дублине, Ирландия. Гамильтон со своей женой шёл в Ирландскую королевскую академию, и переходя через Королевский канал по мосту Брум Бридж, он сделал потрясающее открытие, которое сразу же нацарапал на камне моста.

$$

Памятная табличка на мосту Брум Бридж через Королевский канал в честь открытия фундаментальной формулы умножения кватернионов.

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

Всем привет! Целых 4 года я не писал на Хабр. Последняя моя серия постов была о различных инструментах и приемах, которые мы применяли на нашей прошлой игре (разрабатывая ее на Unity). С тех пор игру ту мы благополучно выпустили, а также выпустили и новую. Так что теперь можно немного выдохнуть и написать несколько новых статей, которые могут быть кому-то полезны.


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

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

Для начала, кратко перечислю из чего собирается картинка в нашей игре:

Это длиннющие следующие три части из цикла «где мои деньги, чувак» в которых мы будем говорить о важности оформления странице на Steam, работе с комьюнити и важности региональных ограничений. Посмотрим на дистрибьюторов и рынок 3d-party дистрибуции, альтернативных открытых платформах, бандлах, фондах и лучших практиках краудфандинга в 2018 году. Наконец, посмотрим на то, что важно для безболезненной локализации игр и сколько это стоит.

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

«Это легко. Берём метрику Шварцшильда, ищем символы Кристоффеля, вычисляем их производную, записываем геодезическое уравнение, меняем некоторые декартовы координаты (чтобы не страдать), получаем большое многострочное ОДУ — и решаем его. Примерно так».



Теперь ясно, что чёрные дыры меня засосали. Они бесконечно увлекательны. В прошлый раз я разбирался с визуализацией геометрии Шварцшильда. Меня поглотила проблема точного представления, как кривизна такого пространства-времени влияет на внешний вид неба (поскольку фотоны из удалённых источников движутся вдоль геодезических линий, изогнутых чёрной дырой) для создания интерактивного моделирования. Вот результат (работает в браузере). Хитрость в максимально возможном предрасчёте отклонения световых лучей. Всё работает более-менее нормально, но конечно, такая симуляция далека от идеала, потому что в реальности там не производится никакой трассировки (для неспециалистов: восстановление назад во времени местонахождения световых лучей, падающих в камеру).

Мой новый проект исправляет этот недостаток, отказавшись от эффективности/интерактивности самым простым образом: это рейтрейсер чисто на CPU. Трассировка выполняется максимально точно и максимально долго. Рендеринг изображения вверху занял 15 5 минут (спасибо, RK4) на моём ноутбуке.