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

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

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

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

Джои Ленц из Naughty Dog подробно рассказал нам об освещении в UE4: о значениях, источниках, световой температуре, освещении в PBR, ресурсах, по которым можно изучать освещение, а также обо многом другом. На официальном сайте Джои polyplant.co есть множество полезных советов о работе с освещением.

Про PBR

PBR (physically-based rendering, основанный на физике рендеринг) благодаря использованию замеренных данных реального мира предоставляет удобные средства для создания материалов/освещения с предсказуемыми, неизменными результатами при разных условиях освещения. Для студий разработки игр это означает, что их художники могут тратить меньше времени на итерации создания контента и его переработку для создания «корректного» внешнего вида в разных уровнях. В свою очередь, это экономит студиям деньги. На освоение PBR художникам, привыкшим к старым методологиям, потребуется какое-то время. Иногда сложнее всего им избавиться от привычки добавления в albedo-текстуры информации об освещении/затенении. Однако как только они освоятся с этим рабочим процессом, то быстро понимают, что им гораздо проще управлять, чем традиционными средствами рендеринга текстур.

В этом туториале по Unreal Engine 4 вы научитесь рисовать цветами по мешу любого типа.

Рисование по мешу позволяет игрокам раскрашивать внутриигровые объекты. Примеры рисования по мешу: граффити (goop) в Super Mario Sunshine, гели в Portal 2 и чернила в Splatoon. Рисование может использоваться как геймплейний элемент или быть просто графическим оформлением. Как бы то ни было, рисование по мешу открывает новые возможности для дизайнеров геймплея и художников.

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

В этом туториале вы узнаете, как рисовать на скелетном меше. Для этого мы сделаем следующе:

• Развернём меш в его UV-форму
• Используем точку пересечения трассировки линии для создания сферической маски меша
• Отрендерим развёрнутый меш и сферическую маску в render target с помощью захвата сцены (scene capture)
• Используем маску для смешивания текстур в материале персонажа

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

Здравствуйте меня зовут Дмитрий. Я занимаюсь созданием компьютерных игр на Unreal Engine в качестве хобби.

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

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

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

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

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

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

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

Введение

Сколько полигонов мне можно использовать? Это очень частый вопрос, который задают художники при создании моделей для рендеринга в реальном времени. На этот вопрос сложно ответить, потому что дело не только в цифрах.

Я начинал карьеру как 3D-художник ещё в эпоху первой PlayStation, а позже стал программистом графики. Хотел бы я прочитать эту статью перед тем, как впервые начал создавать 3D-модели для игр. Рассмотренные в ней фундаментальные основы пригодятся многим художникам. Хотя бОльшая часть информации из этой статьи не повлияет значительно на продуктивность вашей ежедневной работы, она даст вам базовое понимание того, как графическая карта (graphics processing unit, GPU) отрисовывает создаваемые вами меши.

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

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

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

1. Каковы критерии «кухни»? (вариации: вот этот брокер (имярек) кухня или нет? и пр.)
2. В чем отличия услуг ITinvest от услуг критикуемых вами кухонь?

Не желая вступать в полемику и спор с представителями форекс-сообщества (все-таки статья писалась не для них), я, тем не менее, счел себя обязанным продолжить объяснение, что такое «правильный» форекс, а также:

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

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

Всех приветствую. Это текст от первого лица. Пишет Дмитрий Козменко.

Прежде всего хочу подчеркнуть, что мы, сочинский провайдер «Бизнес-Связь», в течение пяти лет успешно используем технологию пассивной оптической сети в городе Сочи и прилегающих посёлках. На данный момент у нас работает более тридцати головных станций GPON, обслуживающих несколько тысяч абонентов. Мы знакомы с технологией не понаслышке, участвовали в закрытых тестированиях, дебажили прошивки вместе с разработчиками как самих устройств, так и чипсетов. То есть технологию GPON мы, разумеется, используем в работе. Однако там, где есть возможность, работаем с классической схемой по «витой паре». И нам почему-то никогда не приходило в голову брать месседж про GPON в каких бы то ни было маркетинговых завлекаловках абонентов или же в качестве какого-то нашего совершенно особенного конкурентного преимущества. Потому что, если разобраться внимательно и в деталях, абонентам технология GPON как шла, так и ехала. А тот факт, что многие провайдеры позиционируют использование GPON как сильное продуктовое преимущество для абонентов – это выглядит странно. Если не сказать, что выглядит очковтирательством немножк☺.

Чем больше узнаёшь в своей области знания, тем чётче понимаешь, что никто не может знать всего.

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

Как бы то ни было, я именно это и сделал, и ненавижу себя за это. На удивление, вышло замечательно. Никто из нас не знает всего.

Проблема №1: ресурсы

Первый вопрос, который у меня возник: как сказать клиенту, что для рендеринга объекта нужно использовать такой-то меш?

Сериализировать весь меш? Не стоит, у клиента он уже есть на диске.

Передавать имя файла? Не-а, малоэффективно и небезопасно.

Ну ладно, может быть, просто строковый идентификатор?

К счастью, прежде чем у меня появилось время на реализацию собственных бредовых идей, я посмотрел доклад Майка Эктона, в котором он говорил об опасностях «ленивого принятия решений». Смысл в следующем: строки позволяют разработчикам лениво игнорировать принятие решений до момента создания работающего приложения, когда исправлять ошибки уже поздно.

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

Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:

Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости

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

Цель статьи — рассказать о контексте, в котором инструменты в JavaScript развивались вплоть до 2017-го. Начнём с самого начала и будем делать сайт, как это делали бы динозавры — безо всяких инструментов, на чистом HTML и JavaScript. Постепенно станем вводить разные инструменты, поочерёдно рассматривая решаемые ими проблемы. Благодаря историческому контексту вы сможете адаптироваться к постоянно меняющемуся ландшафту JavaScript и понять его.

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

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



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

Уровень ядра

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

Думаю все крутили ручку радиоприемника, переключая между «УКВ», «ДВ», «СВ» и слышали шипение из динамиков.
Но кроме расшифровки сокращений, не все понимают, что скрывается за этими буквами.
Давайте ближе познакомимся с теорией радиоволн.

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

Что не так с обычными зеркалами?

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

Если вам случалось писать большие приложения, вы, вероятно, использовали такие виртуальные машины, как VMWare, Virtual PC или что-то иное. Но задавались ли вы вопросом: как они работают? Эти удивительные, можно сказать, магические технологии увлекали меня довольно долгое время. Чтобы развенчать «магию» и разобраться в деталях, я написал «с нуля» собственную систему виртуализации – «песочницу». Решение этой задачи было довольно сложным делом. Реализация подобного продукта ставит множество вопросов, ответы на которые вы не найдете в Google, поэтому я хочу поделиться своим опытом с сообществом.

Nuklear — это библиотека для создания immediate mode пользовательских интерфейсов. Библиотека не имеет никаких зависимостей (только C89! только хардкор!), но и не умеет создавать окна операционной системы или выполнять реальный рендеринг. Nuklear — встраиваемая библиотека, которая предоставляет удобные интерфейсы для отрисовки средствами реализованного приложения. Есть примеры на WinAPI, X11, SDL, Allegro, GLFW, OpenGL, DirectX. Родителем концепции была библиотека ImGUI.

Чем прекрасна именно Nuklear? Она имеет небольшой размер (порядка 15 тысяч строк кода), полностью содержится в одном заголовочном файле, создавалась с упором на портативность и простоту использования. Лицензия Public Domain.

В GCC7 реализован последний стандарт С++17 (будет принят в этом году). Хотелось бы обратить внимание, что изменились правила вывода типа auto при фигурной инициализации.