Главный приём — Kuwahara-фильтр как единственный пасс постпроцессинга. Всё остальное (отражения, частицы, реакция на скролл, физика появления хлеба по клику) встроено вокруг него и подгоняется под его эстетику.

Концепция. Забытая мельница на воде, рендерится как акварель, но полноценно 3D и интерактивна. Вода, ветер, сцена — единое атмосферное пространство. Под мирным фасадом скрыт сюрреалистический намёк: подводная мельница бесконечно производит хлеб, хотя зерно давно ушло.

Стек. React, React Three Fiber, Drei, React Three Rapier, Howler.js, TypeScript, WebGL, HTML/SCSS.

Главный приём — Kuwahara-шейдер. Несмотря на сильно обработанный вид, это единственный пасс постпроцессинга. Сцена строится вокруг него, в том числе на этапе моделей в Blender — чтобы видеть итоговый эффект сразу.

Отражающая вода — три шага. MeshReflectorMaterial в низком разрешении (для производительности), кастомный шейдер сверху для деталей и анимации воды, тюнинг освещения.

Reveal Effect. ScrollControls контролирует параметр uProgress, шейдер применён к ScreenQuad. Это компактный способ реализовать разворачивающуюся при скролле интро-сцену.

Концепция: уют, которого не бывает

Wei работает в свободном режиме: не использует Figma и подобные инструменты на личных проектах, идёт от концепта в голове. Susurrus родился как «эхо в сознании»: дом, плавающий на отражающей воде, с Kuwahara-шейдером, наложенным как пост-процессинг — чтобы получить «3D-веб-впечатление как картина».

Интерфейс при этом намеренно прост — фокус на 3D-контенте. В сцене присутствуют два поэта, но смысловое ядро — атмосфера и эмоция, переданные через визуал и звук. Само слово «susurrus» (шёпот, шорох) задаёт тон: слова намеренно невнятны, важнее — настроение.

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

Kuwahara-шейдер: ядро всего проекта

Весь визуальный стиль Susurrus построен на Kuwahara-фильтре. Это единственный пасс постпроцессинга — всё остальное собрано вокруг него. Wei поставил его на этап раньше, чем закончил 3D-модели в Blender: так можно видеть итоговый эффект и подгонять модели под шейдер, а не получить сюрприз в финале.

При исследовании автор нашёл несколько подходов, опираясь в основном на разбор Maxime Heckel о Kuwahara-фильтре и painterly-шейдинге. На основе этих референсов Wei сделал упрощённую реализацию:

• Не использовал TensorPass, чтобы пасс остался простым (хотя он усиливает детализацию).
• Использовал отличающийся подход на vertex-стадии, по сравнению со стандартными реализациями.

Стандартный vertex для Kuwahara обычно выглядит так:

Версия Wei проще:

Wei не применяет полную модель-вью-проекционную матрицу (MVP), чтобы немного ускорить вычисления. Цена компромисса — эффект слабее, когда камера подходит близко, но в Susurrus камера не приближается к моделям анимацией, поэтому это ОК.

Отражающая вода в три шага

Авторская «грязная» реализация воды:

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

Reveal Effect для интро-сцены

Wei использовал ScrollControls для контроля параметра uProgress, который подаётся в reveal-шейдер. Шейдер применён к ScreenQuad — это удобный способ реализовать эффект «открытия» сцены при скролле.

Звук, физика и адаптивность

Звуковые эффекты. Через react-howler: разные звуковые взаимодействия по hover/click. Эффекты интегрированы с фоновой музыкой, чтобы получился lo-fi-стиль — «картина, которая может петь».

Физика. Главный интерактивный элемент Susurrus — Spawning Bread on Click: щелчок порождает физический объект (хлеб), который падает в сцену. На реализации стоит React Three Rapier.

Адаптивность. Стандартная для автора цель — мобильная совместимость и плавная производительность на mobile и более старых устройствах.

Выводы

Susurrus — пример того, как один точно выбранный шейдер может задать стиль всему проекту: от моделей в Blender до анимации воды и интерактивности. Идея Wei — начать с Kuwahara-фильтра ещё до финальных моделей — практичная: видишь итоговый эффект сразу и не тратишь время на проработку деталей, которые шейдер всё равно сгладит.

Для тех, кто работает с Three.js / React Three Fiber, в случае Susurrus есть три прямых заимствования: компактный паттерн ScrollControls + ScreenQuad для reveal-сцен, дешёвая реализация отражающей воды через MeshReflectorMaterial низкого разрешения + кастомный шейдер сверху, и выбор пасса постпроцессинга на старте проекта, а не в финале.

Источник: Susurrus: Crafting a Cozy Watercolor World with Three.js and Shaders — Codrops.

В этой части мы сделаем несколько ключевых шагов:

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

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

Добавление игрока и роя пришельцев

Прежде чем добавить игрока и рой пришельцев, создадим два агрегата данных — то есть структуры (struct):

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

В классических аркадных играх Space Invaders существует три типа пришельцев, которые отличаются только своими спрайтами. Этот параметр мы кодируем в поле type.

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

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

Как и ранее, мы добавляем спрайт для игрока, закодированный в виде растрового изображения (bitmap).

Затем мы создаём и инициализируем структуру Game.

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

Наконец, в основном игровом цикле мы отрисовываем игрока и всех пришельцев.

Получаем вот такой результат:

Это уже начинает напоминать Space Invaders, но пока всё довольно статично!

Анимация спрайтов

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

Структура SpriteAnimation по сути представляет собой массив Sprite. Здесь мы используем тип «указатель на указатель» для хранения спрайтов, чтобы их можно было шарить (совместно использовать). Если хочется повысить эффективность, спрайты можно упаковать в атласы (spritesheets). Кроме того, мы добавляем флаг, указывающий, нужно ли зацикливать анимацию или воспроизводить её лишь один раз, интервал между последовательными кадрами и время, проведённое в текущем экземпляре анимации. Зная число кадров и желаемую длительность анимации, интервал между кадрами легко вычислить. Ниже мы вводим дополнительный спрайт для нашего инопланетянина…

…и создаём двухкадровую анимацию, используя два спрайта пришельца.

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

Большинство современных мониторов имеют частоту обновления 60 Гц, что означает обновление экрана 60 раз в секунду. Включив V-sync, мы получим частоту кадров 60 FPS или кратное значение, синхронизированное с частотой дисплея.

Однако есть и недостаток: на мониторах с более высокой частотой обновления, например, 120 Гц или 240 Гц, игра будет работать быстрее. Чтобы включить V-sync, вызывается функция GLFW:

В конце каждого кадра мы обновляем все анимации, увеличивая значение времени.

Если анимация дошла до конца, мы либо удаляем её, либо сбрасываем время обратно в 0, если это зацикленная анимация.

Обратите внимание, что на данный момент у нас есть только одна анимация, которую нужно обновлять.

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

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

Чтобы сделать процесс более интересным, мы также добавляем простое движение игрока, введя переменную, которая управляет направлением его движения…

…и обновляем положение игрока в конце каждого кадра в зависимости от значения этой переменной.

Условия if выполняют простую проверку столкновений спрайта игрока с границами игрового поля, гарантируя, что игрок остаётся внутри этих границ.

Выше вы можете видеть анимированный GIF с результатом.

Заключение

В этом посте мы создали несколько структур (struct), чтобы логически сгруппировать данные для игры, игрока и пришельцев. Ещё важнее то, что мы заложили основу для анимации спрайтов. Для этой простой версии Space Invaders мы используем фиксированные игровые циклы, задав постоянную частоту кадров с помощью включения вертикальной синхронизации (V-sync). Это позволяет нам выполнять анимацию спрайтов в игровых циклах, а не в реальном времени.

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

Рендеринг на стороне CPU

GPU отлично справляется с обработкой больших объёмов данных, но программировать графический процессор сложнее, чем CPU. Для простого клона Space Invaders, который я создаю здесь, проще выполнять всю отрисовку на центральном процессоре (CPU), используя буфер — участок памяти, представляющий собой пиксели игрового экрана. Затем этот буфер можно передать на GPU в виде текстуры и вывести на экран компьютера.

Буфер имеет определённую ширину и высоту. Мы представляем каждый пиксель в виде значения типа uint32_t, что позволяет хранить четыре 8-битных компонента цвета для каждого пикселя. В нашем случае мы будем использовать только 24 бита — по 8 бит для красного (red), зелёного (green) и синего (blue) каналов. Можно возразить, что логичнее было бы использовать uint8_t, но я применяю 32-битное значение, потому что так проще работать с индексами при обращении к элементам массива. Чтобы использовать эти типы целых чисел с фиксированной разрядностью, необходимо подключить стандартный заголовочный файл:

Чтобы упростить определение цветов в виде значений типа uint32_t, мы создадим следующую функцию:

Эта функция устанавливает три старших байта (24 бита) в значения r, g и b соответственно.

Оставшиеся 8 младших битов заполняются значением 255 — хотя, как упоминалось ранее, альфа-канал (прозрачность) в нашем случае не используется. Далее мы создаём функцию, которая очищает буфер, заполняя его указанным цветом.

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

Теперь, в главной функции (main), мы инициализируем буфер — то есть создаём область памяти, где будут храниться все пиксели экрана:

Этот код создаст буфер с шириной buffer_width и высотой buffer_height, а также заполнит его цветом clear_color, то есть зелёным.

Шейдеры OpenGL

После того как мы создали буфер, нам нужно настроить OpenGL, чтобы иметь возможность вывести его содержимое на экран. В современном OpenGL большая часть обязанностей, которые раньше выполнял драйвер, теперь ложится на разработчика. Он должен сам писать небольшие программы, которые выполняются на видеокарте (GPU) — такие программы называются шейдерами (shaders).

OpenGL определяет конвейер рендеринга — последовательность этапов, через которые проходит изображение перед выводом на экран. Шейдеры могут выполняться на разных стадиях этого конвейера.

Старый OpenGL иногда называют fixed pipeline — «фиксированный конвейер», поскольку его этапы были заранее определены и не могли быть изменены программистом.

В современном OpenGL почти все этапы программируемы, и основные среди них два:

• Vertex Shader (вершинный шейдер) — обрабатывает данные вершин, обычно выполняет трансформацию объектов в координаты экрана.
• Fragment Shader (фрагментный шейдер) — работает с пикселями, полученными после растеризации. Он определяет их цвет, глубину и, при необходимости, трафаретные значения (stencil).

Эти два шейдера — минимально необходимые для работы любого рендеринга в OpenGL.

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

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

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

Обратите внимание, что выходное значение вершинного шейдера TexCoord теперь используется как вход для фрагментного шейдера. Хотя вершинному шейдеру не требуется передавать какие-либо данные о вершинах, мы всё же должны указать, что будем рисовать три вершины. Для этого создаётся объект вершинного массива (VAO).

Если упростить, VAO (Vertex Array Object) — это структура в OpenGL, которая хранит формат вершинных данных вместе с самими данными вершин. Наконец, оба шейдера нужно скомпилировать в код, понятный GPU, а затем связать их в единый шейдерный программный объект.

В приведённом выше фрагменте кода шейдерная программа сначала создаётся с помощью функции glCreateProgram. Отдельные шейдеры создаются функцией glCreateShader и компилируются с помощью glCompileShader. После этого они присоединяются к программе через glAttachShader, после чего сами объекты шейдеров можно удалить.

Программа связывается вызовом glLinkProgram. Во время компиляции OpenGL выводит различную информацию — аналогично тому, как это делает компилятор C++. Однако, чтобы получить эти сообщения, их нужно перехватывать вручную. Для этого созданы две простые функции: validate_shader и validate_program.

Текстура буфера

Для передачи данных изображения на GPU используется текстура OpenGL. Как и в случае с VAO, текстура также объект, который вместе с данными изображения содержит информацию о формате этих данных. Сначала текстура создаётся с помощью функции glGenTextures.

Затем задаём формат изображения, а также некоторые стандартные параметры, определяющие поведение выборки текстуры.

Здесь мы указываем, что изображение должно использовать 8-битный RGB-формат для внутреннего представления текстуры. Последние три параметра вызова glTexImage2D определяют формат пикселей данных, которые мы передаём в текстуру: каждый пиксель находится в формате RGBA и представлен четырьмя беззнаковыми 8-битными целыми числами.

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

Теперь нам нужно привязать текстуру к uniform-переменной sampler2D во фрагментном шейдере. В OpenGL существует несколько текстурных единиц, к которым может быть привязан uniform. Мы получаем расположение uniform-переменной в шейдере (его можно рассматривать как своего рода «указатель») с помощью glGetUniformLocation и устанавливаем её на текстурную единицу 0 с помощью вызова glUniform1i.

Отображение буфера

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

Если теперь вызвать:

То содержимое созданного окна должно отобразиться зелёным цветом.

Отрисовка спрайта

В предыдущем посте мы уже создали окно и вывели на экран цвет. Заканчивать эту часть на том же этапе было бы скучно — так что теперь давайте что-нибудь нарисуем.

Сначала я определяю простой спрайт:

Это просто участок данных, размещённых в куче, вместе с указанием ширины и высоты спрайта. Сам спрайт представлен в виде битовой карты (bitmap) — то есть каждый пиксель кодируется одним битом, где значение 1 означает, что пиксель спрайта включён (“on”).

Далее мы создаём функцию, которая отрисовывает спрайт в буфере с заданным цветом.

Функция просто проходит по пикселям спрайта и рисует активные (“on”) пиксели по указанным координатам, если они находятся в пределах границ буфера.

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

В главной функции (main) мы создаём спрайт пришельца (alien sprite).

Чтобы нарисовать красный спрайт в позиции (112, 128), вызываем:

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

Если скомпилировать и запустить финальный код из этого поста, то вы увидите красную текстуру в центре зелёного фона.

В этом посте мы подготовили всё необходимое, чтобы отрисовывать спрайты на CPU и выводить их в окно, созданное ранее. В современном OpenGL это требует определённого объёма работы — мы затронули такие темы, как объекты вершинных буферов, шейдеры и текстуры.

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

Автор написал клон классической аркады Space Invaders на C++, опираясь всего на пару зависимостей. В этой части мы подготовим окно и контекст OpenGL 3.3, используя GLFW и GLEW — это единственные внешние библиотеки, которые понадобятся на старте.

Что такое Space Invaders

Space Invaders — аркадная игра 1978 года. Это 2D-шутер с горизонтальным управлением: игрок двигает пушку вдоль нижней границы экрана и стреляет по строю инопланетян. За каждого сбитого врага начисляются очки. Периодически по верхней части экрана пролетает НЛО — если сбить, получите бонусные очки. По мере уничтожения инопланетян игра ускоряется. Враги тоже стреляют случайно, приближаясь к низу экрана; попадание по игроку отнимает жизнь. Пушку частично прикрывают бункеры, но они постепенно разрушаются как под выстрелами врагов, так и самим игроком. После зачистки волны появляется новая, а бункеры восстанавливаются. Игра заканчивается, если бункеры полностью разрушены, инопланетяне достигли низа экрана или у игрока закончились жизни.

Постановка целей

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

В прототипе нужны:

• управляемая игроком пушка;
• волны инопланетян, которые постепенно движутся к пушке;
• стрельба у обеих сторон.

НЛО и бункеры на первом этапе опустим (их несложно добавить потом).

Почти любую игру можно разложить на базовые элементы (очень советую доклад Raph Koster). В Space Invaders это движение и стрельба (а значит — детекция столкновений). Даже простой клон поможет прокачать понимание геймлупа, коллизий и правил игры.

Поехали!

Hello Window

Окно можно создать по-разному: нативные API (Cocoa/X11/WinAPI) или кроссплатформенные библиотеки (Qt, GLFW). Нативный путь даёт полный контроль, но ради простоты и кроссплатформенности возьмём GLFW: лёгкая, простая C-API.

Подключим заголовки (стандартный ввод/вывод и GLFW):

Это откроет окно 640×480 с заголовком Space Invaders и контекстом OpenGL. Два последних параметра glfwCreateWindow — монитор для фуллскрина и «шаринг» контекста между окнами. При неудаче вызываем glfwTerminate(). Важно: нужно «привязать» контекст текущему потоку (glfwMakeContextCurrent), чтобы последующие вызовы OpenGL применялись к нему.

По умолчанию версия контекста не гарантируется — попросим минимум 3.3 Core (задать до создания окна):

Почему нужен загрузчик функций OpenGL. OpenGL — это спецификация; реализация зависит от GPU/драйвера/ОС. Множество функций нужно загружать в рантайме. Делать это вручную неудобно, поэтому используют лоадеры. Здесь — GLEW (можно и GLAD, но в статье выбран GLEW).

Важно: подключаем GLEW до glfw3.h:

Игровой цикл (Game loop)

Если запустить код сейчас, окно мигнёт и программа завершится. Нужен бесконечный game loop, где мы обрабатываем ввод, обновляем состояние и рисуем кадр:

• Буферы. Современный OpenGL рисует в «задний» буфер, а «передний» отображается на экране. glfwSwapBuffers() меняет их местами.
• События. glfwPollEvents() вынимает накопившиеся события (клавиатура, мышь, закрытие окна).
• Выход. glfwWindowShouldClose() станет true, если пользователь нажал «крестик».

В конце корректно освобождаем ресурсы:

Компиляция

Ниже — команды из оригинала (C++11), плюс современные примечания.

Обратите внимание, что позже мы будем использовать некоторые функции C++11, поэтому компилируем с помощью -std=c++11. В обоих случаях убедитесь, что у вас установлен GLFW 3. В Linux, в зависимости от вашего дистрибутива, вы можете использовать менеджер пакетов. Например, в Ubuntu GLFW можно установить с помощью следующей команды:

На Mac OS X автор предпочитает использовать Homebrew:

Возможно, эта статья поможет вам настроить проект GLFW в Visual Studio.

Если всё собрано успешно, вы увидите красное окно с заголовком Space Invaders.

Итоги

Даже просто «поднять окно» с контекстом OpenGL на C++ — задача не из быстрых, несмотря на помощь GLFW. Мы пока ничего не рисуем; настройка простейшего рендера в современном OpenGL тоже требует подготовки. Хорошая новость — делать это придётся один раз, а дальше вы переиспользуете базу в следующих частях (шейдеры, VBO/VAO, спрайты, коллизии и т. д.).

Вторая часть статьи — здесь

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

От треугольника к OpenGL 4.6

Работа началась в декабре 2020 года — всего через несколько недель после релиза M1. Разработчик Кристиан Шалонски, ранее работавший над драйвером Panfrost (для GPU Mali), увлекся идеей и начал реверс-инжиниринг графической части Apple Silicon.

Сначала я просто нарисовал треугольник. В 3D-графике, если ты можешь нарисовать треугольник — ты можешь все.

Потом появился полноценный компилятор шейдеров, поддержка OpenGL. Еще позже — сложнейшая эмуляция геометрии и тесселяции шейдеров.

В январе 2024 года стек получил официальную сертификацию OpenGL 4.6.

Vulkan, Direct3D и Proton

Следом Шалонски собрал Vulkan-драйвер и уже через несколько недель получил Vulkan 1.3, а позже — Vulkan 1.4 с поддержкой делимых текстур. Это стало финальной точкой: через Proton теперь запускаются Windows-игры с поддержкой Direct3D 11/12.

Да, вы не ослышались: на Mac с M1 можно запускать игры для Windows через Proton от Valve. И они работают.

Также команда обеспечила поддержку OpenCL 3.0 (благодаря Karol Herbst) и OpenGL ES 3.2, обеспечив совместимость с мобильными и встраиваемыми приложениями.

Полноценный десктоп на Linux

Сегодня на Asahi Linux для Mac M1/M2 работают:

• Wi-Fi, Bluetooth, аудио;
• видеоускорение;
• полнодоступный терминал и графическая среда;
• поддержка Wayland и X11;
• графические API: OpenGL, Vulkan, OpenCL;
• игры через Proton и Wine.

Все это — с открытым кодом и в мейнлайне Mesa.

Почему это важно

Apple по-прежнему не дает официального доступа к документации GPU. Это делает реализацию открытого драйвера большим инженерным достижением, сопоставимым с реверсом графики NVIDIA до появления Nouveau.

Кроме того, это еще один шаг к альтернативной экосистеме на базе Linux даже на закрытом железе Apple. Проект может вдохновить:

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

Apple без OpenGL

macOS по-прежнему будет запускать приложения с устаревшими фреймворками, но не гарантирует стабильность их работы. Apple порекомендовала разработчикам перейти на собственный API и использовать шейдеры Metal и Metal Performance. Инструкция по переносу кода в Metal представлена в документации.

Компания поддерживала OpenGL с 90-х годов. Инструмент стал популярен среди разработчиков благодаря открытому исходному коду и кроссплатформенности. Его преемник Vulkan API был представлен в 2015 году, но macOS его не поддерживает. В свою очередь, Metal API не является кроссплатформенным.

Несмотря на отсутствие поддержки Vulkan API, разработчики могут использовать часть его преимуществ. Для этого была создана библиотека MoltenVK, представленная в феврале 2018 года.

• 15 минут свободного времени;
• Настроенная рабочая среда, т.е. JDK и IDE (например Eclipse);
• Библиотека LWJGL (версии 2.x.x) для работы с Open GL. Обратите внимание, что для LWJGL версий выше 3 потребуется написать код, отличающийся от того, что приведён в статье;
• Иконки для клеток, т.е. цифры, флаг, неверно поставленный флаг, мина, взорвавшаяся мина и закрытое поле. Можно чисто символически нарисовать самому, или скачать использовавшиеся при написании статьи.

Работа с графикой

Для работы с графикой создадим отдельный класс — GUI. От него нам потребуется хранение всех графических элементов управления (т.е. полей клеток), определение элемента, по которому пришёлся клик и передача ему управления, вывод графических элементов на экран и управление основными функциями OpenGL.

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

• Внешний вид (текстура);
• Координаты;
• Размеры (ширина и высота);
• Метод, который по переданным координатам клика определит, попал ли клик по элементу;
• Метод, который обработает нажатие на элемент.

Таким образом, пишем:

В GUI должны храниться ячейки поля. Создадим для этих целей двумерный массив:

GUI должен передавать клики элементам, которые он содержит. Вычислить адрес клетки, по которой кликнули, нетрудно:

Теперь разберёмся с основными функциями OpenGL. Во-первых, нам нужна инициализация.

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

И, наконец, нам нужно это изображение вообще рисовать. Для этого пора закончить enum Sprite. Его элементы будут представлять из себя обёртку для текстуры с удобочитаемыми именами.

Теперь мы можем написать метод для GUI, который будет рисовать элементы:

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

Ячейки

Создадим класс Cell, реализующий интерфейс GUIElement. В методах getWidth() и getHeight() вернём константу, для координат придётся создать поля, которые будут инициализироваться конструктором. Так же конструктором будем передавать состояние клетки: “-1”, если это мина, “-2”, если это взорванная мина, число мин поблизости в остальных случаях. Для этой цели можно было бы использовать enum, но число мин удобнее передавать как integer, имхо. Итак, конструктор:

Ещё два поля — boolean isMarked и boolean isHidden будут отвечать за то, отметили ли клетку флажком, и открыли ли её. По умолчанию оба флага выставлены на false.

Разберёмся с методом getSprite().

В случае, если на кнопку нажали, нам снова необходимо рассмотреть несколько простейших случаев:

Чтобы при поражении клетки можно было вскрыть, добавим метод:

Для более удобной реализации генератора добавьте ещё и этот метод:

Обработка ответов от клеток

Вернёмся к методу GUI.receiveClick(). Теперь мы не можем просто вернуть результат назад, т.к. если результат выполнения — единица, то нам нужно открыть соседние ячейки, а в главный управляющий класс вернуть уже ноль, в знак того, что всё прошло корректно.

Пишем генератор

Задачка эта не сложнее, чем создать массив случайных boolean-величин. Идея следующая — для каждой ячейки матрицы мы генерируем случайное число от 0 до 100. Если это число  меньше 15, то в этом месте записываем в матрицу мину (таким образом, шанс встретить мину — 15%). Записав мину, мы вызываем у всех клеток вокруг метод incNearMines(), а для тех ячеек, где клетка ещё не создана храним значение в специальном массиве.

Главный управляющий класс и ввод

Создадим класс Main, в нём входной метод — public static void main(String[] args). Этот метод должен будет делать всего две вещи: вызывать инициализацию GUI и циклически вызывать рабочие методы (input(), GUI.draw() и GUI.update()), пока не получит сигнал закрытия.

Здесь нам не хватает метода input(), займёмся им.

Метод GUI.gameover() будет просто вызывать метод show() у каждой клетки, показывая таким образом всё поле:

Запускаем:

Готово!

UPD: исходники выложены на GitHub

Многие разработчики ошибочно полагают, что создание даже простейшего 3D-приложения с нуля требует нечеловеческих знаний и усилий. К счастью, это не совсем так. Более того, при наличии компьютера и свободного времени, можно создать нечто подобное самостоятельно. Давайте взглянем на процесс разработки нашего собственного движка для 3D-рендеринга.

Итак, для чего же это всё нужно? Во-первых, создание движка для 3D-рендеринга поможет понять, как же работают современные движки изнутри. Во-вторых, сам движок при желании можно использовать и в своём собственном приложении, не прибегая к вызову внешних зависимостей. В случае с Java это значит, что вы можете создать своё собственное приложение для просмотра 3D-изображений без зависимостей (далёких от API Java), которое будет работать практически везде и уместится в 50 КБ!

Само собой, если вы хотите создать какое-нибудь большое 3D-приложение с плавной анимацией, вам лучше использовать OpenGL/WebGL. Однако, имея базовое представление о том, как устроены подобные движки, работа с более сложными движками будет казаться в разы проще.

В этой статье я постараюсь объяснить базовый 3D-рендеринг с ортографической проекцией, простую треугольную растеризацию (процесс, обратный векторизации), Z-буферизацию и плоское затенение. Я не буду заострять своё внимание на таких вещах, как оптимизация, текстуры и разные настройки освещения — если вам это нужно,  попробуйте использовать более подходящие для этого инструменты, вроде OpenGL (существует множество библиотек, позволяющих вам работать с OpenGL, даже используя Java).

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

Довольно болтать — давайте приступим к делу!

GUI

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

Результат должен выглядеть вот так:

Теперь давайте добавим некоторые модели — вершины и треугольники. Вершина — это просто структура для хранения наших трёх координат (X, Y и Z), а треугольник соединяет вместе три вершины и содержит их цвет.

Здесь я буду считать, что X означает перемещение влево-вправо, Y — вверх-вниз, а Z будет глубиной (так, что ось Z перпендикулярна вашему экрану). Положительная Z будет означать «ближе к пользователю».

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

Код также будет достаточно простым — мы просто создаём 4 треугольника и добавляем их в ArrayList:

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

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

Заметьте, что сейчас я совершил все преобразования до отрисовки треугольников. Это сделано, чтобы для того, что бы поместить наш центр (0, 0, 0) в центр экрана — по умолчанию начало координат находится в левом верхнем углу экрана. После компиляции вы должны получить:

Вы можете не поверить, но это наш тетраэдр в ортогональной проекции, честно!

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

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

Возьмём наш входной вектор A:

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

Например, вот как будет выглядеть трансформация, если мы умножим на 2:

Вы не можете описать любую возможную трансформацию, используя матрицы размера 3×3 — например, если переход происходит за пределы пространства. Вы можете использовать матрицы размера 4×4, делая перекос в 4D-пространство, но об этом не в этой статье.

Трансформации, которые нам пригодятся здесь — масштабирование и вращение.

Любое вращение в 3D-пространстве может быть выражено в 3 примитивных вращениях: вращение в плоскости XY, вращение в плоскости YZ и вращение в плоскости XZ. Мы можем записать матрицы трансформации для каждого из данных вращений следующим путём:

• Матрица вращения XY:

• Матрица вращения YZ:

• Матрица вращения XZ:

И вот здесь начинается магия: если вам нужно сначала совершить вращение точки в плоскости XY, используя матрицу трансформации T1, и затем совершить вращение этой точки в плоскости YZ, используя матрицу трансформации T2, то вы можете просто умножить T1 на T2  и получить одну матрицу, которая опишет всё вращение:

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

Что ж, довольно страшной математики, давайте вернёмся к коду. Создадим служебный класс Matrix3, который будет обрабатывать перемножения  типа “матрица-матрица” и “вектор-матрица”:

Теперь можно и оживить наши скроллеры вращения. Горизонтальный скроллер будет контролировать вращение влево-вправо (XZ), а вертикальный скроллер будет контролировать вращение вверх-вниз (YZ).

Давайте создадим нашу матрицу вращения:

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

Как вы, наверное, уже заметили, вращение вверх-вниз ещё не работает. Добавим эти строки в код:

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

Я буду использовать очень простой, но крайне неэффективный метод — растеризация через барицентрические координаты. Настоящие 3D-движки используют растеризацию, задействуя железо компьютера, что очень быстро и эффективно, но мы не можем использовать нашу видеокарту, так что будем делать всё вручную, через код.

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

Довольно много кода, но теперь у нас есть цветной тетраэдр на экране.

Если вы поиграетесь с демкой, то вы заметите, что не всё сделано идеально — например, синий треугольник всегда выше других. Так происходит потому, что мы отрисовываем наши треугольники один за другим. Синий здесь — последний, поэтому он отрисовывается поверх других.

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

Теперь видно, что у нашего тетраэдра есть одна белая сторона:

Вот мы и получили работающий движок для 3D-рендеринга!

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

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

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

Для начала нам нужно посчитать вектор нормали для нашего треугольника. Если у нас есть треугольник ABC, мы можем посчитать его вектор нормали, рассчитав векторное произведение векторов AB и AC и поделив получившийся вектор на его длину.

Векторное произведение — это бинарная операция на двух векторах, которые определены в 3D пространстве вот так:

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

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

Косинус угла между векторами можно посчитать по формуле:

Где ||A|| — длина вектора, а числитель — скалярное произведение векторов A и B:

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

Заметьте, что только Z компонент направления света не равен нулю, так что мы можем просто всё упростить:

В коде это всё выглядит тривиально:

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

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

Код будет давать нам некоторые эффекты затенения, но спадать они будут куда быстрее, чем нам нужно. Так происходит, потому что в Java используется спектр цветов sRGB.

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

И теперь мы видим, как наш тетраэдр оживляется. У нас есть работающий движок для 3D рендеринга с цветами, освещением, затенением, и заняло это около 200 строк кода — неплохо!

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

Вот что должно у вас получиться:

Я бы закончил эту статью, порекомендовав одну занимательную книгу: “Основы 3D-математики для графики и разработки игр”. В ней вы можете найти детальное объяснение процесса рендеринга и математики в этом процессе. Её стоит прочитать, если вам интересны движки для рендеринга.