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

Вопросы делятся по темам: С++, математика, оптимизация и компьютерная графика. Очевидно, это главные темы в повседневной работе. C++ часто используется в реальных задачах, поэтому естественно, что на собеседовании задают много вопросов по нему. Кроме того, в программировании графики требуется лучшее знание математики, чем в большинстве других видов программирования, поэтому математические навыки имеют первостепенное значение. Наконец, для достижения 60 FPS и рендеринга с высокой графической точностью обязательными являются сильные навыки оптимизации. Давайте рассмотрим популярные вопросы в каждой категории.

Blueprints — очень популярный способ создания геймплея в Unreal Engine 4. Однако если вы уже давно программируете и предпочитаете код, то вам идеально подойдёт C++. С помощью C++ можно даже вносить изменения в движок и создавать собственные плагины.

В этом туториале вы научитесь следующему:

• Создавать классы C++
• Добавлять компоненты и делать их видимыми для Blueprints
• Создавать класс Blueprint на основе класса C++
• Добавлять переменные и делать их изменяемыми из Blueprints
• Связывать привязки осей и действий с функциями
• Переопределять функции C++ в Blueprints
• Связывать событие коллизии с функцией

1. Части I, II (синглплеер с авторитарным сервером)
2. Часть III (Появление врага)
3. Часть IV (Хэдшот!)

Предлагаю вашему вниманию перевод статьи Fast-Paced Multiplayer (Part I): Introduction.

Разработка игры — само по себе непростое занятие. Но мультиплеерные игры создают совершенно новые проблемы, требующие разрешения. Забавно, что у наших проблем всего две причины: человеческая натура и законы физики. Законы физики привнесут проблемы из области теории относительности, а человеческая натура не даст нам доверять сообщениям с клиента.

Те, кто мог видеть мою прошлую статью (а она довольно related к данной теме), знают, что вот уже больше полутора лет я разрабатываю собственную реализацию сервера Minecraft, рассчитанную, в первую очередь, на высокие нагрузки. Тем не менее, в своей работе мы используем так же и стандартный сервер (Bukkit) для нескольких мини-серверов, просто чтобы было разнообразие. И вот, столкнувшись с очередной версией сервера, которая стала раз в 5 хуже предыдущих, я уже не выдержала, и решила написать эту статью.

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

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

Unreal Engine 4 — это набор инструментов для разработки игр, имеющий широкие возможности: от создания двухмерных игр на мобильные до AAA-проектов для консолей. Этот движок использовался при разработке таких игр, как ARK: Survival Evolved, Tekken 7 и Kingdom Hearts III.

Разработка в Unreal Engine 4 очень проста для начинающих. С помощью системы визуального создания скриптов Blueprints Visual Scripting можно создавать готовые игры, не написав ни строчки кода! В сочетании с удобным интерфейсом это позволяет быстро изготавливать рабочие прототипы.

В этой части туториала по Unreal Engine 4 мы ознакомимся с основными возможностями программы. Вот основные темы, которые будут в нём рассмотрены:

• Установка движка
• Импорт ассетов
• Создание материалов
• Использование Blueprints для создания объектов с простейшими функциями

Однажды, в 2009 году, вышла Windows 7. В то время я сидел на Висте, которая притормаживала на моем стареньком компьютере, и я решил пересесть на семерку сразу после ее выхода.

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



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



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

Под катом:

• Подробная демонстрация того, как можно самостоятельно подправить принцип работы такого системного процесса, как explorer, под себя, используя отладчик OllyDbg.
• Готовое решение описанной выше проблемы.

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

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

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

Здравствуйте. Несколько недель назад я начинал серию переводов статей по изучению OpenGL. Но на 4 статье один хабровчанин заметил, что мои переводы могут нарушать лицензию, по которой распространяются учебные материалы, предоставленные в исходной статье. И действительно, мои переводы нарушали лицензию. Для разрешения этой проблемы я обратился к авторам того набора уроков, но так и не смог добиться нормального ответа. По этой причине я связался с автором другого, не менее (а возможно даже и более) крутого, набора уроков по OpenGL: Joey de Vries. И он дал полное разрешение на перевод его набора уроков. Его уроки гораздо более обширные, чем прошлый набор, поэтому эти переводы растянутся на долго. И я обещаю, будет интересно. Заинтересовавшихся прошу под кат.

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

На счет уроков по Vulkan: к сожалению мне тяжело сейчас написать уроки по данному API по причине скудной видеокарты на данный момент, которая просто не поддерживает Vulkan API, поэтому уроки по данному API будут только после обновления видеокарты.

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

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

Себастьян ван Элвердинге рассказывает о своём подходе к созданию потрясающих трёхмерных камней и скал с помощью множества фотографий. Более подробно о нём можно узнать в туториале на gumroad.com/sebvhe.

Введение

Привет, меня зовут Себастьян, я живу в Брюсселе, на родине лучшего картофеля фри, пива и шоколада! Сейчас я работаю художником по окружениям в Starbreeze Studios (Стокгольм). раньше я работал в Playground Games над игрой Forza Horizon 3, которая стала для меня отличной возможностью применения фотограмметрии в игре AAA-класса.



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

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

Основные задачи художников визуальных эффектов

Если говорить только о визуальных эффектах, то их можно разделить на два основных типа задач: геймплейные эффекты и природные эффекты (или эффекты окружений). Принцип их разделения зависит от конкретного проекта. Например в такой игре, как Castlevania (жанра hack'n'slash), 90% визуальных эффектов состояло в умениях персонажа и магии, сильно влиявших на геймплей. Такие задачи требуют серьёзного понимания механик игры и постоянного общения с командой дизайнеров, с которой нужно постоянно договариваться. Для примера давайте возьмём огнемёт. Дизайнеры геймплея подбирают область урона атаки, а затем вам необходимо создать эффект поверх отладочного цилиндра. Постепенно уменьшающийся огонь не полностью соответствует области урона, и дизайнеры начинают на это жаловаться. Вот один из примеров «конфликтов» между двумя дисциплинами, потому что если придерживаться строгих правил, огонь не будет похож на огонь. Поэтому приходится искать альтернативы и убеждать дизайнеров, что игрок не заметит, что небольшой исчезающий огонь не нанёс никакого урона.

Среди прочих жанров, геймплейные эффекты более «важны» в файтингах и RPG.

Существуют и другие игровые жанры, например, шутеры (в особенности это касается реалистичных), в которых природные эффекты так же важны, как и геймплейные. В этом случае художник, ответственный за природные эффекты, становится практически художником по окружениям и в основном сотрудничает с этой командой. Примерами природных эффектов являются водопады, туман, дождь и т.д. Больше всего природных эффектов я создал в Gears of War 4, где мы работали над многопользовательскими картами и должны были заботиться о влиянии эффектов на производительность, потому что от игры требовалось работать в 1080p при 60 fps.

Хей, привет. 2017 год на дворе. Даже простенькие мобильные и браузерные приложения начинают потихоньку рисовать физически корректное освещение. Интернет пестрит кучей статей и готовых шейдеров. И кажется, что это должно быть так просто тоже обмазаться PBR… Или нет?

В действительности же честный PBR сделать достаточно сложно, потому что легко достичь похожего результата, но сложно правильного. И в интернете полно статей, которые делают именно похожий результат, вместо правильного. Отделить мух от котлет в этом хаосе становится сложно.
Поэтому цель статьи не только разобраться, что же такое PBR и как он работает, но и научиться писать его. Как отлаживать, куда смотреть, и какие ошибки типично можно допустить.
Статья рассчитана на людей, которые в достаточной мере уже знают hlsl и неплохо знакомы с линейной алгеброй, и можете написать свой простейший неPBR Phong свет. В общем я постараюсь как можно проще объяснить, но рассчитываю на то, что некоторый опыт работы с шейдерами вы уже имеете.

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

→ Часть 0
→ Часть 1, общие оптимизации

В прошлый раз мы получили ускорение в среднем в 2,5 раза без изменения подхода. В этот раз я покажу, как применять SIMD-подход и получить ускорение еще в 3,5 раза. Конечно, применение SIMD для обработки графики не является ноу-хау, можно даже сказать, что SIMD был придуман для этого. Но на практике очень мало разработчиков используют его даже в задачах обработки изображений. Например, довольно известные и распространенные библиотеки ImageMagick и LibGD написаны без использования SIMD. Отчасти так происходит потому, что SIMD-подход объективно сложнее и не кроссплатформенный, а отчасти потому, что по нему мало информации. Довольно просто найти азы, но мало детальных материалов и разбора реальных задач. От этого на Stack Overflow очень много вопросов буквально о каждой мелочи: как загрузить данные, как распаковать, запаковать. Видно, что всем приходится набивать шишки самостоятельно.

Что: трассировка каскадов воксельных конусов

Для The Tomorrow Children мы реализовали инновационную систему освещения, основанную на трассировке воксельных конусов. Вместо использования традиционных систем прямого или отложенного освещения мы создали систему, освещавшую всё в мире трассировкой конусов через воксели.

Таким способом обрабатывается и прямое, и отражённое освещение. Он позволяет нам рассчитывать на PlayStation 4 три отражения глобального освещения в полудинамических сценах. Мы трассируем конусы в 16 фиксированных направлениях через шесть каскадов 3D-текстур и выполняем поглощение света с помощью направленного затенения в экранном пространстве (Screen Space Directional Occlusion) и сферическими окклюдерами динамических объектов для получения конечного результата. Движок также поддерживает модель сферического освещения на основе гармоник, что позволяет рассчитывать освещение частиц и реализовать спецэффекты, например аппроксимированное подповерхностное рассеяние (approximating subsurface scattering) и преломляющие материалы.

Всем привет. Несколько месяцев назад мы вместе с victorzs решили сделать простой и удобный профилировщик c++ кода (подразумевается профилирование времени исполнения участков кода, функций).


Скриншот профилирования примера из SDK CryEngine

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

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

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

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

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

[Все картинки кликабельны, потому что Хабр сжимает изображения разрешением больше 1920]

Введение

Меня зовут Ана Родригес (Ana M. Rodriguez), я занимаюсь компьютерной графикой и специализируюсь на текстурах и шейдерах, В настоящее время я работаю фрилансером компании Blind Squirrel Games, последним моим проектом был сборник игр Bioshock: The Collection. До него я работала над Castlevania: Lords of Shadows 1 и 2. Также мне удалось поучаствовать в проекте Castlevania: Mirror of Fate для Nintendo 3DS.

На тему векторизации написано немало интересного. Вот скажем, отличный пост, который много полезного объясняет по работе автовекторизации, очень рекомендовал бы его к прочтению. Мне интересен другой вопрос. Сейчас в руках у разработчиков большое количество способов, чтобы создать «векторный» код – от чистого ассемблера до того же автовекторизатора. На каком же способе остановиться? Как найти баланс между необходимым и достаточным? Об этом и поговорим.

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

Введение

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

Думаю, что наш провал с CppCat был предопределён. Мир диктует свои законы, и, например, тот же Coverity ориентирован на корпоративные лицензии. Однако, это не значит, что нужно исключать другие варианты взаимодействия с миром.

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

Стоит пояснить нашу позицию. Впрочем, если вам не терпится, вы можете сразу перейти к разделу «Бесплатная лицензия PVS-Studio». Если же читателю интересно узнать подробности, то предлагаю продолжить чтение.

(Прим. пер.: 1. Spine — это проприетарный кроссплатформенный пакет для создания двухмерных скелетных анимаций с поддержкой различных игровых тулкитов.
2. Осторожно, в посте есть около 38 МБ gif'ок, все они спрятаны под кат.)

Как создать плавное переключение или поворот спрайтов?

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

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