Мне нужен был простой и быстрый шейдер, создающий туман, освещённый точечными источниками света. Для его реализации я написал эффект экранного пространства, результаты работы которого показаны ниже. Конвейер почти столь же прост, что и для обычных точечных источников. Он не требует структур данных объёмов, ray marching, и может быть без проблем подключен к уже существующему шейдеру освещения.

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


Небольшая сцена с космическим кораблём, отрендеренная в тумане при помощи моей техники

Постановка задачи

Рассмотрим задачу нахождения угла поворота и смещения облака точек. Под облаком точек подразумевается набор точек на плоскости, сохраняющие взаимное расположение друг от друга, при их пространственном перемещении.

Т.е. есть два набора точек: исходное облако и облако преобразованное произвольным образом в пространстве (см. Рис. 1). Любое преобразование облака точек в пространстве можно интерпретировать как поворот и смещение. Таким образом, необходимо определить на какой угол требуется повернуть исходное облако точек и на какое расстояние его передвинуть от исходного облака точек, чтобы получить то самое, преобразованное произвольным образом облако точек.

Рис. 1 Пример облака точек, к которому применен поворот на 15 градусов, и смещение по оси Х: 10, по оси Y: 30

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

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

Первые созданные человеком 3D-модели выглядели примерно так:


Это замечательно, но у такой модели есть очевидное ограничение: она выглядит слишком полигональной.

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

Хотя Close Quarters преимущественно является многопользовательской игрой, в ней всё равно должны присутствовать сложные ИИ-боты, чтобы игроки продолжали играть при плохом Интернет-соединении или отсутствии других онлайн-игроков. Кроме того, боты играют важную вспомогательную роль в некоторых режимах игры. Поэтому они должны вести себя правдоподобно и демонстрировать набор сложных поведений, в том числе использование укрытий, применение предметов в подходящее время, обход с флангов, бросание гранат и убегание от них.

Окружение и ограничения

Игровое окружение состоит из полигонов. Большинство полигонов блокирует движение, область видимости и стрельбу, однако есть и «низкие» полигоны, только блокирующие движение. Окружение плотно заставлено препятствиями и укрытиями.

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

Было мучительно наблюдать за выпуском DLC второго сезона Samurai Shodown. Игра продолжает расти и развиваться, не стремясь решить свою самую большую проблему: ужасный онлайн-режим. Есть ли вообще смысл развивать соревновательную игру, как бы ни была она красиво и хорошо сделана, если большинство игроков едва может играть друг против друга?

Сама игра потрясающа. Когда мы собираемся с друзьями, я часто запускаю Samurai Shodown; она великолепна и дружелюбна к новым игрокам, а мощные удары заставляют затаить дыхание всех в комнате. Всем очень нравится в неё играть, вне зависимости от уровня навыков.


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

Онлайн-файтинги заслуживают много большего. NetherRealm Studios (Mortal Kombat) и Capcom (Street Fighter) со временем создали превосходный сетевой код, и даже мелкие инди-игры, в том числе такие шуточные, как файтинг мемов Fight of Animals, благодаря улучшенным технологиям добились отличных результатов.

Но лидеры жанра, такие как SNK и Arc System Works, вместе с другими разработчиками, в основном из Японии, на протяжении долгих лет не меняли своего подхода к онлайн-боям, даже выпуская новые восхитительные игры. Хотя Granblue Fantasy Versus находится на острие прогресса 3D-анимации, уровень её сетевого кода остался в далёком прошлом.

Автор статьи Дуглас Макилрой — американский математик, инженер и программист. Наиболее известен разработкой конвейера в операционной системе Unix, принципов компонентно-ориентированного программирования и нескольких оригинальных утилит: spell, diff, sort, join, speak, tr.

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

Поделитесь, какие программы вас тоже настолько поразили?

PDP-7 Unix

Для начала, сама система PDP-7 Unix. Её простота и мощь заставили меня перейти с мощного мейнфрейма на крошечную машину. Здесь квинтэссенция иерархической файловой системы, отдельная оболочка и управление процессами на уровне пользователя, что Multics на мейнфреймах не смогла реализовать после сотен человеко-лет разработки. Недостатки Unix (например, структура записей в файловой системе) были столь же поучительными и освобождающими, как и её новшества (например, перенаправление ввода-вывода в оболочке).

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

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

Игра начинала создаваться на Unreal Engine 4.18, сейчас последний билд в магазине использует UE 4.24. Сначала игра была выпущена на Android, после я занялся выпуском ее на iOS.



Кому может быть интересна статья:

• разработчикам игр на UE 4, которые решат выложить свой труд в App Store.
• разработчикам приложений для iOS (некоторые части статьи повествуют только об экосистеме Apple без привязки к UE 4).

Краткий обзор

Иерархический буфер глубин — это многоуровневый буфер глуби (Z-буфер), используемый как ускоряющая структура (acceleration structure) для запросов глубин. Как и в случае mip-цепочек текстур, размеры каждого уровня обычно являются результатами деления на степени двойки размеров буфера полного разрешения. В этой статье я расскажу о двух способах генерации иерархического буфера глубин из буфера полного разрешения.

Сначала я покажу, как генерировать полную mip-цепочку для буфера глубин, сохраняющую точность запросов глубин в пространстве координат текстуры (или NDC) даже для размеров буферов глубин, не равных степеням двойки. (В Интернете мне встречались примеры кода, не гарантирующие этой точности, что усложняет выполнение точных запросов на высоких mip-уровнях.)

Затем для случаев, в которых требуется только один уровень даунсэмплинга, я продемонстрирую, как сгенерировать этот уровень при помощи одного вызова вычислительного (compute) шейдера, использующего атомарные операции в общей памяти рабочей группы. Для моего приложения, где требуется только разрешение 1/16 x 1/16 (mip-уровень 4), способ с вычислительным шейдером в 2-3 раза быстрее, чем обычный подход с даунсэмплингом mip-цепочки в несколько проходов.

Давайте представим, что нам нужно запустить футбольный мяч на орбиту Земли. Никакие ракеты не нужны! Хватит горы, высотой 100 километров и недюжинной силы. Но насколько сильно нужно пнуть мяч, чтобы он никогда больше не вернулся на Землю? Как отправить мяч в путешествие к звёздам, имея только грубую силу и знание небесной механики?

Сегодня в программе:

• Бесконечные возможности одной формулы
• Как взять энергию у Юпитера
• Откуда у планет берутся кольца
• Как математика помогла открыть Нептун

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

Друзья, разрешите представить проектик GSM сигнализации на Arduino. В сети довольно много проектов по типу «Arduino + модем + датчики», однако я часто вижу в них некоторую незаконченность (в особенности, с программной точки зрения): отсутствие гибкости в настройках и конфигурировании. В представленном решении я попытался сделать устройство максимально готовое к «боевым» условиям, предусмотрев все, что может понадобится среднестатистическому пользователю (на мой взгляд).

TL; DR программно и аппаратно задуманное реализовано, тест в реальных условиях запущен, исходники и бинарники опубликованы, корпус не осилил.

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


Фото с омского «Хакатона по применению малых БПЛА»

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

Всем привет.

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

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

Итак, поехали. Какие же варианты структур данных для «графохранения» мы имеем.

Недавно я читал книгу «Компьютерные системы: архитектура и программирование. Взгляд программиста». Там, в главе про систему ввода-вывода Unix, авторы упомянули о том, что в конце файла нет особого символа EOF.



Если вы читали о системе ввода-вывода Unix/Linux, или экспериментировали с ней, если писали программы на C, которые читают данные из файлов, то это заявление вам, вероятно, покажется совершенно очевидным. Но давайте поближе присмотримся к следующим двум утверждениям, относящимся к тому, что я нашёл в книге:

1. EOF — это не символ.
2. В конце файлов нет некоего особого символа.

Что же такое EOF?

Прим. перев.: Новая статья с критикой полюбившейся многим Git Flow получила столь заметное внимание, что даже оригинальный автор модели обновил публикацию 10-летней давности, актуализировав свой взгляд на её применение сегодня. Публикуем перевод как самой критики, так и официальной реакции.



Git-flow — это методология ветвления и слияния, сильно популяризированная заметкой 2010 года под названием «A Successful Git branching model» (была переведена на хабре как «Удачная модель ветвления для Git» — прим. перев.).

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

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

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

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

Как часть этого проекта я реализовал Tyler — тайловый растеризатор, который мы проанализируем в данной статье. Моей целью при разработке этого проекта были масштабируемость. настраиваемость и понятность растеризатора для людей, которые хотят немного больше понять в этой теме и поэкспериментировать с ней. Эта статья достаточно сильно связана с тем, что объяснено в серии «Растеризация за одни выходные», поэтому лучше будет прочитать и её. Я не буду предполагать, что вы её изучили, но в статье будет больше высокоуровневых объяснений — я не хочу повторять уже сказанное и то, что можно найти в других источниках.

Краткий обзор

Тайловый рендеринг (tile-based rendering или tiled rendering) — это улучшенный по сравнению с традиционным immediate-mode-рендерингом; в нём render target (RT) разделяется на тайлы (т.е. субрегионы кадрового буфера), каждый из которых содержит примитивы, которые можно рендерить в тайлы по отдельности.


Обратите внимание на выражение «по отдельности», потому что оно подчёркивает одно из самых больших преимуществ этой техники по сравнению с immediate-mode: ограничение всех операций доступа внутри тайла буферами цветов/глубин, которые остаются в «медленной» DRAM благодаря использованию отдельного тайлового кэша на чипе.

В этой статье Максим Шестаков, DevOps Engineer в студии Plarium Krasnodar, делится опытом сборки и доставки пользователям приложений для iOS, который накопился в процессе отладки CI/CD.

Вершина технологий того времени.

В 1993 году id Software выпустила шутер от первого лица Doom, который быстро превратился в феномен. Сегодня считается, что это одна из игр, оказавших самое большое влияние за всю историю.

Десять лет спустя после выпуска Doom, в 2003 году, журналист Дэвид Кушнер опубликовал книгу об id Software под названием Masters of Doom, которая с тех пор стала каноническим описанием процесса создания Doom. Я прочитал Masters of Doom несколько лет назад и почти ничего уже не помню, но одна история из книги о ведущем программисте Джоне Кармаке сохранилась в моей памяти. Моё описание будет не совсем точным (подробнее см. ниже), но если вкратце, то на раннем этапе разработки Doom Кармак осознал, что написанный им для игры 3D-рендерер при рендеринге отдельных уровней начинал тормозить. Это было неприемлемо, потому что Doom должен был стать активной и даже бешеной игрой. Осознав, что проблема рендерера была настолько фундаментальной, что ему придётся искать более оптимальный алгоритм рендеринга, Кармак начал читать исследовательские статьи. В результате он реализовал технику под названием «двоичное разбиение пространства» (binary space partitioning, BSP), которая раньше никогда не применялась в видеоиграх, и значительно ускорил таким образом движок Doom.

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

Привет всем, меня зовут Андрей Токарев, и снова я бы хотел поделиться опытом участия и победой в Russian AI Cup.

Если кто не знает, Russian AI Cup (далее РАИК) это чемпионат по программированию искусственного интеллекта, где мы (точнее наша программа) должны управлять одним или несколькими персонажами (юнитами), которые соревнуются между собой. В этом году игра представляла собой 2-х мерный платформер, напоминающая компьютерные игры начала 90-х, а юниты являлись вооруженными человечками, которые должны были убивать таких же человечков противника. Более детально об этом можно почитать в анонсе



В этот раз заседания не было когда пришла повестка о начале РАИК-а, так что перейдем сразу к сути.

Машинное обучение продолжает проникать в самые разные сферы человеческой деятельности, и такая технологичная область, как разработка ПО, конечно, не могла стать исключением. По прогнозу специалиста по ИИ и машинному обучению Сергея Маркова, озвученному в лекции «Итоги ИИ-2019», в 2020-м году появится большое количество инструментов разработки, использующих машинное обучение. Это навело меня на мысль, что какие-то из этих инструментов  должны быть доступны на рынке уже сейчас — могут ли они в таком случае помочь «в быту» обычному веб-девелоперу, пишущему на Java, Python и JS? 

Забегая вперед, скажу, что, к моему сожалению, решений, способных генерировать хоть сколько-нибудь «боевой» код, в открытом доступе сейчас нет. Ближе всего к этому подошли Bayou и DeepCoder, но и эти проекты всё еще слишком сырые. Больший прогресс наблюдается в смежных направлениях — таких как автокомплит, статический анализ, генерация тестов. Об этом я и расскажу в статье.

Это сборник информации, которая мне понадобилась, чтобы реализовать этап установления соединения между участниками сетевой игры типа «равный к равному» (peer-to-peer) с использованием протокола UDP.

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

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