Примечание: полный исходный код проекта выложен на Github [здесь]. В репозитории также содержится подробная информация о том, как читать и использовать код.

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

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

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

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

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

В своём методе я стремлюсь одновременно и к простоте, и к реализму ценой небольшого повышения сложности базовой системы эрозии. Рекомендую прочитать мою предыдущю статью об этой системе [здесь, перевод на Хабре], потому что новая модель строится на её основе.

Видеоигры существуют более 50 лет. За это время технологии скакнули от текстовой The Oregon Trail до фотореалистичной Red Dead Redemption 2. Не говоря уже о VR-тайтлах вроде Half-Life: Alyx, которая выходит в конце марта.

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

Для того, чтобы получить реалистичный мир внутри игры, необходимо учитывать взаимодействие различных форм рельефа между собой и с другими моделями. И если видимые линии пересечения между 3D-моделями портят органичность изображения, стоит задуматься над тем, как их устранить. Самый распространенный случай таких линий, который может быть знаком многим, — пересечение билбордов частиц с непрозрачной геометрией.



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



Помимо разнообразных методов сглаживания (SSAA, MSAA, CSAA, FXAA, NFAA, CMAA, DLAA, TAA и др.), которые пусть и смягчают вызывающий внешний вид таких линий пересечений, но не исправляют ситуацию в полной мере, существуют и более действенные приемы. Их мы и рассмотрим.

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


Панель управления квартирой в феврале 2020 года (Home Assistant)

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


Строительство нашего дома в процессе — ноябрь 2016 года

Возможно, прозрачность не кажется какой-то интересной темой. Формат GIF, позволявший некоторым пикселям просвечивать сквозь фон, опубликован более 30 лет назад. Почти в каждом приложении для графического дизайна, выпущенном за последние два десятка лет, поддерживается создание полупрозрачного контента. Эти понятия давно перестали быть чем-то новым.

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

Введение

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

Персонаж — это личность. Без истории нет индивидуальности. Каждый хороший персонаж начинается с истории, а дизайн персонажа должен рассказать эту историю.

В своей предыдущей статье How To Make Low Poly Look Good я говорил, что главная цель низкополигонального (low poly) дизайна — донести сообщение через наименьшее количество форм.

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

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

---

Я буду работать в Blender. В Maya, Max и других 3D-редакторах есть похожие инструменты, так что не беспокойтесь об этом.

Вступление

Задача для оружия была сформулирована одновременно с задачей о персонажах. Оружие изготовлено для sci-fi сетевого шутера под VR платформы. Стиль оружия был выбран под впечатлением дизайна 90-х годов, c небольшим уклоном в Retro design. Проект является VR экспериментом и находится в разработке.

В данной статье рассматривается перехват функций графического API на примере DirectX 9 под x64 применительно к игре Dota 2.

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

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

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

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

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

Итак, сегодня я покажу, как отрисовывать подобные картинки:

Я всегда хотел написать подробное руководство для начинающих о том, как создать roguelike, содержащее как общие, так и более специфические советы. Проведённый в этом году очередной праздник Roguelike Celebration показался мне отличной возможностью наконец-то заставить себя это сделать, поэтому я подготовил получасовой доклад по этой теме.

У меня есть довольно большой опыт — в течение последних семи лет я работал только в этом жанре (Cogmind, Cogmind 7DRL, POLYBOT-7, REXPaint, X@COM), и в течение последних пяти эта работа была моей основной. К тому же, все эти годы я помогал превращению r/RoguelikeDev в крупнейшее сетевое сообщество разработчиков roguelike.

Банда хакеров-подростков добыла ключи от империи видеоигр Microsoft. Потом они зашли слишком далеко.

1. Бампер

Поездка в Делавэр планировалась всего на день. Дэвид Покора, старшекурсник-очкарик из университета Торонто с неряшливыми светлыми волосами до плеч, отправился на юг, чтобы выбрать бампер для своего тюнингованного Volkswagen Golf R.

Американский продавец отказался отправлять деталь в Канаду, поэтому Покора договорился со своим приятелем Джастином Мэем, который жил в Уилмингтоне. Оба парня ярые геймеры увлекались взломом Xbox. Хотя они чатились и сотрудничали много лет, но никогда не встречались лично. Покора планировал восьмичасовую поездку в пятницу, чтобы спокойно поужинать с Мэем, а затем привезти металлический синий бампер домой в Миссиссогу, штат Онтарио, той ночью или рано утром следующего дня. Отец предложил помощь, так что они могли по очереди вести семейную «Джетту».

Часть 1. Знакомство с Marching cubes

Как создать меш из любого хаоса
В Minecraft мы можем копать в любом направлении, убирая за раз по одному блоку с чётко заданными краями. Но в других играх разработчикам удаётся разрушать рельеф плавно, без кубичности Minecraft.

Вот пример из No Man’s Sky: видео.

Аналогичная техника применяется для отображения изображений с МРТ, metaball-ов и для вокселизации рельефа.

В этой части я расскажу о технике создания разрушаемого рельефа Marching Cubes, а в более общем применении — для создания плавного граничного меша твёрдого объекта. В этой статье мы начнём с рассмотрения двухмерной техники, затем трёхмерной, а в третьей части рассмотрим Dual Contouring. Dual Contouring — это более совершенная техника, создающая тот же эффект.

3 года назад художник спросил меня:
— Слушай, а можно в нашу мобильную игру добавить красивые облачка?
— Нет, это абсолютно невозможно, у нас постоянно вращается камера, так что билборды будут смотреться очень фальшиво даже если на них добавить карты нормалей, а другие способы…
*художник погружается в летаргический сон*

Для меня нет большего удовольствия, чем выяснять, что я был неправ.



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

В этой статье я хочу обсудить шаблон проектирования «сущность-компонент-система» (Entity-Component-System, ECS). По этой теме можно найти много информации в Интернете, поэтому я не буду глубоко вдаваться в объяснения, а больше расскажу о моей собственной реализации.

Часть 1: Реализация шаблона Entity-Component-System на C++

Начнём сначала. Полный исходный код моей реализации ECS можно найти в репозитории на github.

Entity-Component-System, в основном используемый в играх — это шаблон проектирования, обеспечивающий огромную гибкость в проектировании общей архитектуры программного обеспечения^[1]. Такие большие компании, как Unity, Epic или Crytek используют этот шаблон в своих фреймворках, чтобы предоставить разработчикам очень богатый возможностями инструмент, с помощью которого они могут разрабатывать собственное ПО. Прочитать более широкое обсуждение по этой тематике можно в этих постах ^[2,3,4,5].

[Прим. пер.: оригинал статьи называется GPU Performance for Game Artists, но, как мне кажется, она будет полезной для всех, кто хочет иметь общее представление о работе видеопроцессора]

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

Мы надеемся, что художники создадут ресурсы, которые не только хорошо выглядят, но и будут эффективны при рендеринге. Если художники немного больше узнают о том, что происходит внутри видеопроцессора, это может оказать большое влияние на частоту кадров игры. Если вы художник и хотите понять, почему для производительности важны такие аспекты, как вызовы отрисовки (draw calls), уровни детализации (LOD) и MIP-текстуры, то прочитайте эту статью. Чтобы учитывать то влияние, которое имеют ваши графические ресурсы на производительность игры, вы должны знать, как полигональные сетки попадают из 3D-редактора на игровой экран. Это значит, что вам нужно понять работу видеопроцессора, микросхемы, управляющей графической картой и несущей ответственность за трёхмерный рендеринг в реальном времени. Вооружённые этим знанием, мы рассмотрим наиболее частые проблемы с производительностью, разберём, почему они являются проблемой, и объясним, как с ними справиться.

На что вы сейчас смотрите? Если вы не из параллельной вселенной, где все сидят за векторными мониторами, то перед вами растровое изображение. Поглядите на эту полоску: /. Если придвинуться поближе к монитору, то можно увидеть пиксельные ступеньки, которые пытаются притвориться векторной линией. Для этой цели существует целая куча всевозможных алгоритмов растеризации, но я бы хотел рассказать об алгоритме Брезенхема и алгоритме У, которые находят приближение векторного отрезка в растровых координатах.

С проблемой растеризации мне довелось столкнуться во время работы над процедурным генератором планов зданий. Мне нужно было представить стены помещения в виде ячеек двумерного массива. Похожие задачи могут встретиться в физических расчётах, алгоритмах поиска пути или расчёте освещения, если используется разбиение пространства. Кто бы мог подумать, что знакомство с алгоритмами растеризации однажды может пригодиться?

Андрей Аксенов делится трудностями в подготовке слайдов для доклада. Это — расшифровка выступления Highload++.



Если видите этот слайд – я не очень успел картинки. Пришел Бунин, убедился, что у него докладчик не пропал и задал подлый вопрос. Мы заранее готовим конференцию, 1 сентября приём докладов. Я тоже хотел заранее подготовиться. Вчера в 6 вечера начал рисовать слайды для другого доклада, а для этого в 11, поэтому вот так.

Придется делать чистый стендап – а слушать ухом, но это, наверное, к лучшему, потому что можно спокойно тупить в телефон.

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

Возможно это федеральное преступление и меня ФСБ заметёт сразу после того как я со сцены выйду. Рискнем, заодно познакомлюсь, поехали.

Про что доклад?

В 1998 году Looking Glass Studios выпустила стелс-игру Thief: The Dark Project. В то время аппаратное 3D-ускорение только зарождалось, поэтому в процессе разработки оно не использовалось, игра рендерилась только программно.

Я был основным автором базовой технологии рендеринга Thief (хотя я и не писал рендереры объектов и персонажей), а также связанных с ней элементов. Тот же движок рендеринга, модифицированный другими людьми для использования аппаратного 3D-ускорения, также использовался для рендеринга System Shock 2 и Thief 2.

Движок был написан примерно в одно время с Quake (хотя игра вышла намного позже), и общий внешний вид сильно напоминает Quake. Многие технологии были скопированы из Quake или вдохновлялись им, но часто их работа немного или значительно отличалась.

От переводчика. Искал в интернете простой и легко применимый гайдлайн по написанию программ на C++. Мне понравился один из вариантов, и я решил его перевести и опубликовать. Если хабрапользователи хорошо встретят этот топик, могу перевести и другие связанные документы, а также гайдлайны по написанию кода от других компаний.

1 Введение

Настоящий документ содержит рекомендации по написанию программ на языке C++.

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

Но для появления ещё одного списка рекомендаций, помимо указанных источников, есть несколько причин. Основная причина — их излишняя обобщённость, поскольку зачастую требуется задать частные правила (в особенности правила именования). Данный документ содержит комментарии, что делает его более удобным в использовании при проведении ревизий кода, чем другие уже существующие документы. К тому же, рекомендации по программированию обычно вперемешку содержат описания проблем стиля и технических проблем, что не совсем удобно. Этот документ не содержит каких-либо технических рекомендаций по C++, делая упор на вопросах стиля.