VG

2021-02-13 12:12:28 ​Screen Space Shadows

Ещё один способ посчитать тени. Как понятно по названию, используется только информация, которая есть в скрин спейсе.

Как это работает? Для каждого пикселя (для которого хотим посчитать screen space shadows) трейсится луч от этого пикселя к источнику света. Если в какой-то момент глубина луча "перекрывается" глубиной в depth buffer'е, то считаем, что луч от источника света не дошел до нашей точки, поэтому она в тени.
Можно твикать разные параметры типа длины луча, примерной глубины поверхности и прочего.

Зачем вообще нужен этот способ, когда есть классические шадоу мапы? Screen space shadows добавляют детали. Особенно заметно на лицах персонажей. Конечно, можно увеличить разрешение шадоу мапы в 10 раз и получить более детализированную картинку, но это будет работать в разы медленнее.

И да, забыл сказать, что screen space shadows обычно используются вместе с шадоу мапами, а не сами по себе.

На скриншоте отрендеренный кролик с использованием только скрин спейс теней.

Очень простая и понятная статья по screen space shadows.
Имплементация в CryEngine 5.6. Открыть/Комментировать

2021-02-11 00:59:13 ​Когда потратил часов 10, чтобы записать в буфер пиксели двух цветов, один из которых образует треугольник, но чувствуешь себя хорошо, так как делал это на Vulkan.

Заняло 700 строк кода с GPU selection, swapchain resize и с фиксом всех validation error'ов. На OpenGL 1.0 что-то такое можно получить за 50 строк, даже не используя GLFW.

Делал по этой серии видео от разработчика Roblox. Открыть/Комментировать

2021-02-07 14:06:47 Несколько советов начинающим low-level программистам от Jamie Hayes'а (рендер программиста в Epic Games):

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

2. Смотрите на дизассембли, который генерирует ваш компилятор.

3. Изучите ABI своей платформы. Поможет дебажить краши в оптимизированных билдах. (То есть в билдах, в которых почти нет дебаг информации. Также в таких билдах операции не обязательно выполняются в том порядке, в котором вы написали на high-level языке).

4. Изучите atomic'и и то, как они работают. Важно для многопоточного кода.

5. Разберитесь в кэшах и в доступе к памяти. Используйте эти знания при написании эффективных структур данных.

6. Разберитесь в бинарным представлением floating-point значений.

7. Поиграйтесь с SIMD (Single-Instruction Multiple-Data) инструкциями. Открыть/Комментировать

2021-02-02 19:08:09 Cem Yuksel, преподаватель компьютерной графики в университете Юты, совсем недавно начал заливать свои лекции на YouTube. Как я понял, лекции для начинающих. Так что это ещё один хороший способ "ворваться" в рендеринг. Открыть/Комментировать

2021-01-31 15:07:09 ​Собственно приложить сам скриншот я забыл. Открыть/Комментировать

2021-01-31 14:51:00 Рейтрейсинг в Киберпанке содержит весь мир. То есть в теории на объекты, находящиеся в центре города, могут влиять баунсы с объектов, которые находятся вообще за городом! Это первая такая игра.

Скриншот взят отсюда. За качество видео не ручаюсь. Открыть/Комментировать

2021-01-30 15:57:07 ​Недавно наткнулся на визуализацию генерации террейна через noise функцию. Именно так я и делал в своих воксельных движках.

То есть друг на друга "накладываются" noise функции с разной амплитудой и частотой (octaves), чтобы получить итоговую высоту.

Вот здесь можно прочитать про это, а также подёргать слайдеры и посмотреть, как изменяется результат при разных значениях. Открыть/Комментировать

2021-01-26 15:14:00 ​Последние пару недель я чувствовал, что потерялся в своём "программистском приключении".

Мне всегда хотелось быть "game engine programmer'ом". Сидя дома я делал всё: архитектуру движка, физику, многопоточность, рендеринг, системы профилирования и тд. Грубо говоря, я приписывал к движку всё, кроме геймплей кода.

В реальном мире всё оказалось по другому - здесь свои рендер программисты, программисты физики, программисты *вставить нужное*.

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

Вспомнил про один "твиттер тред" от главного разработчика движка Godot.

Он пишет, как у него получается быть generalist'ом, почему их так мало, и в целом высказывает свои мысли об этом. Мне эти посты очень помогли. Если я работаю рендерщиком, это не значит, что я должен задрачивать графику дома. Я могу заниматься, чем хочу. Почему-то мне было сложно прийти к этой мысли.

Ну, и подходящая пикча нашлась. Открыть/Комментировать

2021-01-21 21:37:22 Зачем изобретать велосипед. Часть 2

В этом посте мы посмотрим на "выжимку" ответа Кейси Муратори на вопрос "Зачем изобретать велосипед". Тут можно прочитать первую часть поста.
К слову, этот вопрос на английском звучит как "Why reinvent the wheel", то есть "Зачем изобретать колесо".

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

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

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

Даже если ты используешь Unreal/Unity, понимание того, как они работают "изнутри", делает тебя намного лучше в этих движках.

Во-вторых, "изобретать колесо" - очень неправильная фраза. Колесо - это что-то идеальное. Ничего, из того что мы создали за последние 30 лет в геймдеве, не является "колесом". Открыть/Комментировать

2021-01-13 15:12:00 ​HDR and Tone Mapping

Яркость пикселей на экране ограничена.
Например, OpenGL не позволяет записать в буфер значение больше 1.0 (если оно больше, то просто "превращается" в единицу).

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

Мы можем выполнять наши вычисления, используя значения больше 1.0, то есть используя High Dynamic Range (HDR).
Но перед записью в буфер перевести HDR значения в Low Dynamic Range (LDR), который представим на мониторе.

Процесс перевода значения из HDR в LDR называется tone mapping.
Есть различные способы tone mapping'а, но в основном они достаточно простые.

На скриншоте можно заметить, что без tone mapping'а некоторые участки кожи персонажа просто белые, но с tone mapping'ом есть более гладкий переход между цветами. Открыть/Комментировать