Немного про 3д форматы файлов

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

1. OBJ - простые, текстовые, легко читаются, легко парсятся. Есть дополнительные файлы материалов MTL, которые описывают простые свойства вроде текстурок. Из проблем - не поддерживают кучу нужных в современном 3д свойств, вроде анимаций, сцен, света, иерархий объектов и тд. Много весят из-за текстового формата. В целом это простой как палка, но очень ограниченный способ передать геометрию и простые свойства одного конкретного объекта

2. STL - в прошлом очень популярный формат для 3д печати, все еще часто встречается. Из плюсов - простой, поддерживается тоже почти везде. Из минусов - содержит только геометрию, много весит, не содержит информацию о единицах измерения. В целом информации в нем даже меньше, чем в OBJ, где хотя бы uv и нормали есть. По сути подходит только для передачи геометрии

3. FBX - довольно популярный формат, можно сказать что основной для обмена данными между разными редакторами и движками. Из плюсов - содержит много информации, включая и геометрию, и сцены, и анимации/свет/трансформации, и прочее. Из минусов - могут возникать артефакты при конвертации, может много весить. Но главное - формат проприетарный, принадлежит Autodesk, что побуждает людей искать ему замену

4. glTF и GLB - создан специально для передачи и загрузки 3д сцен в приложения вроде игр и веб-сайтов. Открытый, современный стандарт, поддерживающий и сцены, и все возможные свойства вроде анимаций, камер, освещения, трансформаций и прочего. Очень хорошо сжимается, как раз glTF - текстовый вариант с данными в виде отдельных файлов, а GLB - бинарный формат, где все данные уже встроены внутри. Множество языков, движков и библиотек используют его как де-факто формат передачи сцен и моделей. Тем не менее, благодаря своей оптимизации для конечного использования, меньше подходит для передачи между 3д редакторами в процессе арт пайплайна (т.е. лучше использовать как финальный экспортный формат, а не в процессе работы). Создан Khronos Group, которые отвечают за OpenGL и Vulkan

5. USD и USDZ - новый формат сцен от Pixar. По аналогии с glTF и GLB, USD - несжатая версия, а USDZ - запакованная в один файл. Обладает мощными средствами композиции сцен, предназначен для работы с огромными сценами. Становится стандартом в мире 3д редакторов и VFX, то есть используется крупными студиями. Больше подходит именно для процесса работы над 3д сценами в различных редакторах, чем для конечных программ, которые эти сцены будут уже использовать. Из минусов - сжимает данные хуже glTF, содержит множество ненужных для конечного применения данных, в целом ужасно переусложнен для этой задачи. Полноценная поддержка есть только в официальной реализации для C++ и Python, в других языках в лучшем случае малая часть спецификации реализована. Даже Apple поддерживают отнюдь не полный функционал USD. По словам контрибьютора Three.js, парсер USD весит больше, чем вся их графическая библиотека, и его написание и поддержание требует намного больше усилий, чем оправдано. Учитывая, что USD для конечного использования все равно подходит хуже glTF, многие преобразуют glTF в USD вместо создания его с нуля даже там, где он нужен

6. 3MF - специально созданный формат для 3д печати. В отличие от STL, поддерживает и несколько объектов в сцене, и материалы, и встраивание параметров печати в сам файл, как и единицы измерения. За пределами 3д печати почти не используется

7. STEP - стандарт ISO для обмена 3д моделями между CAD программами. В отличие от других форматов, представляет модели не как меши, то есть набор полигонов, а с помощью NURBS, то есть математических формул. Если проводить аналогию с 2д графикой, то другие форматы растровые, а этот - векторный. Он позволяет сохранить абсолютную точность модели в любом масштабе, благодаря чему используется и в CAD системах, и при отправке на производство. Последнее время стал использоваться в сфере 3д печати для передачи точных моделей в слайсеры

8. IGES - устаревший предшественник STEP для CAD программ. Менее надежен, но еще встречается

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

1. 3д печать - 3MF
2. Простая геометрия - OBJ
3. Работа с арт конвейером, обмен между 3д и видео редакторами - USD
4. Игры, веб, AR/VR, другие приложения, которые рендерят сцены в реальном времени - glTF
5. CAD-программы - STEP

Судя по всему, Телеграм не даст мне уместить всю необходимую информацию в одно сообщение (обзор 3д форматов выше буквально в паре символов от лимита).

Придется разбивать на несколько самостоятельно, чтобы избежать обрывков информации в отдельных сообщениях

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

Сперва, наверно, классический дедушка - OpenGL. Появился еще в 80-х, когда видеокарты были намного слабее процессоров, что сказалось на его дизайне. Сильно изменился в 2010 году с выходом версии 3.3, была сделана попытка хоть как-то адаптировать его под современные реалии. Старый дизайн стал называться Compatibility Profile, а новый - Core Profile

По сути, весь OpenGL построен на идее глобального неявного контекста, от состояния которого зависит, что и как сейчас произойдет при исполнении команд на видеокарте. В Compatibility Profile на этом основано вообще всё, тогда как в Core Profile сделали несколько более явных сущностей, чтобы минимизировать использование этого глобального контекста

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

В целом, OpenGL уже просто морально устарел: последняя версия вышла в 2017 году, новых версий не будет, а на всех платформах вообще поддерживается максимум версия 4.1, выпущенная в 2010. Всё дальнейшее развитие мира графики идет в API нового поколения, заменивших его

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

Кроме того, при использовании OpenGL происходит много ситуаций, когда процессор просто блокируется в ожидании видеокарты, что негативно сказывается на общей производительности. Особенно сильно этому подвержен Compatibility Profile. С одной стороны, это упрощает API, но с другой - замедляет работу программы по сравнению с более современными аналогами, где такой проблемы нет

Тем не менее, несмотря на такое обилие минусов, OpenGL все равно пользуется популярностью у инди-разработчиков. Тому есть несколько причин:

1. Огромное обилие информации, накопленное за десятки лет использования

2. Поддержка действительно старого компьютерного железа. Старше 20 лет. Тогда как новые API поддерживают только видеокарты, произведенные в 2010-2012 годах и новее

3. Относительная простота использования. Несмотря на то, что весь дизайн OpenGL побуждает делать ошибки, в целом он требует написания довольно малого количества относительно простого кода. Грубо говоря, если вывод треугольника на экран на OpenGL может занять 150 строк кода, то аналог на его замене, Vulkan, будет уже ближе к 800 строкам. А это довольно важно для инди разработчиков, у которых нет огромных ресурсов ААА студий

4. Какая-никакая, но поддержка на всех платформах, в отличие от более современных вариантов

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

Для отладки приложений на OpenGL можно использовать инструмент от коммьюнити под названием RenderDoc, который широко используется в том числе и крупными студиями

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

дальше переходим к современным API, которые были созданы примерно в 2010-е годы на замену OpenGL, и развиваются по сей день

и начинаем с самого спорного из них - Vulkan. Тут много противоречивых мнений, достаточно как его любителей, так и противников.

Это API было создано Khronos Group как замена OpenGL на базе наработок AMD по Mantle, и призвано решить проблемы предшественника, сделав всё гораздо более явным и дав новые возможности для оптимизации. К сожалению, по моему мнению, они с этими идеями сильно перестарались

На Vulkan в порядке вещей, когда аналог hello world занимает больше тысячи строк. Просто потому что авторы решили сделать ВСË явным и требующим отдельного кода. Частично это было сделано для облегчения драйверов, чтобы они были стабильнее (не слишком помогло, те же встроенные видеокарты Intel по-прежнему работают через раз). С другой стороны, это должно было облегчить написание многопоточного кода и уменьшить количество ошибок. Но в итоге получается просто когнитивный перегруз, когда простейшие действия требуют сотен и тысяч строк кода.

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

Так и Vulkan - потенциально он позволяет добиться х2 и более прироста производительности относительно OpenGL, и есть достаточно примеров подобных случаев. Но в то же время, достаточно примеров и обратного - когда сложность Vulkan мешала адекватно оптимизировать код на нем, и результат работал даже медленнее, чем старый OpenGL. К тому же, трудозатраты просто несоизмеримы

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

К слову, в отличие от старых API, Vulkan нативно доступен далеко не на всех платформах. Он в принципе не поддерживает браузерную среду, а также платформы компании Apple. В случае последних существует слой совместимости MoltenVK, реализующий поддержку Vulkan поверх другого современного API, Metal. Но он отстает по возможностям от обоих и имеет много проблем со стабильностью

Из плюсов же Vulkan активно поддерживается и обладает огромным количеством возможностей, которые недоступны OpenGL ни в каком виде. И в правильных руках позволяет действительно выжать из видеокарты максимум. Также это самое кроссплатформерное из всех новых графических API, работающее нативно на Windows, Linux, Android и Nintendo Switch, а через MoltenVK и на macOS и iOS. А также единственное открытое API из современных нативных.

Кроме того, Vulkan имеет слои валидации, которые могут проверять корректность работы с API, находясь между драйвером и вашим кодом. Однако это далеко не панацея, и многие вещи они пропускают

Для отладки можно использовать RenderDoc, как и с OpenGL. Он довольно популярен и многое умеет, но т.к. сделан коммьюнити, а не авторами Vulkan, то частенько отстает от изменений самого API

Последние годы Vulkan активно теряет аудиторию, которая в основном переходит на прямого конкурента, DX12. Одновременно со стороны разработчиков эти два API пошли на сближение, добавляя поддержку формата шейдеров друг друга. Но об этом подробнее в следующих постах

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

далее идет DX12, он же DirectX 12, он же D3D12, он же Direct3D 12.

Актуальное графическое API от компании Microsoft для платформ Windows и Xbox. Через сторонние слои совместимости возможен запуск большинства приложений на Linux, но официально он не поддерживается

Несмотря на название, имеет больше общего с Vulkan, чем с предшественником, DX11. Тоже довольно низкуровневое API, тоже имеет аналог слоев валидации, тоже перекладывает многое на разработчика

Однако в целом попроще и более продумано, чем Vulkan. Меньше шероховатостей в API при использовании, большее удобство и стабильность, больше гарантий для разработчика. А также является первым в очереди на адаптацию новых фич в мире графики - пока Vulkan только несколько лет планирует реализацию, в DX12 она уже давно доступна.

Кроме того, имеет Agility SDK от Microsoft, который позволяет использовать более новые фичи DX12 в своем приложении относительно тех, что доступны в системе пользователя

А также есть официальный инструмент для отладки, PIX. Который поддерживает данное API лучше, чем RenderDoc, и быстрее поспевает за обновлениями

Последние годы активно набирает популярность, в первую очередь переманивая разработчиков с Vulkan и старых версий DirectX

Из минусов можно назвать все же значительную переусложненность относительно OpenGL, официальную поддержку только платформ Microsoft, а также отсутствие поддержки версий Windows до 10

И пусть на Linux проекты vkd3d и dxvk, а также Proton позволяют запускать многие игры и приложения на DX12, все равно достаточно тех, с которыми имеются проблемы. А также огорчает абсолютное отсутствие поддержки мобильных устройств и платформ Apple

Последнее время DX12 идет на сближение с Vulkan, начиная поддерживать его формат шейдеров и позволяя собирать свои шейдеры под него

Можно сказать, что DX12 - это Vulkan, но сделанный по-человечески, однако лишь для пользователей Windows и Xbox. Так как это основные платформы ПК гейминга, большинство крупных студий в первую очередь используют именно данное API, и рекомендуют его даже при наличии поддержки Vulkan как более стабильное. Однако для малых коллективов и инди разработчиков оно все же может быть слишком трудозатратным, равно как и не подходящим при желании поддержки множества платформ

И последним из современных нативных API является Metal от компании Apple

Это очень интересный пример - отличное, чуть ли не эталонное API и лучший инструментарий к нему, но доступное лишь на платформах одной компании. Благодаря чему крайне нишевое

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

И при этом, при всех своих удобстве и простоте, Metal поддерживает 90% возможностей своих конкурентов, требуя ради них в несколько раз меньших объемов кода

Множество знакомых, плотно работавших с ним, считают его лучшим графическим API, и я склонен согласиться

Разработчик движка Unity, добавлявший поддержку всех трех современных API в него, вообще по итогу сказал, что считает Metal лучшим выбором для новичка, даже лучше OpenGL, несмотря на его закрытость

Собственно, Metal настолько доступен к пониманию, что на нем коллеги на одном из прошлых мест работы делали виджет 3д навигатора в мобильном приложении на iOS. Обычные мобильные разработчики, пишущие на Swift, вообще без какого-то значительного низкоуровневого кода, который просто необходим на других API

вдобавок к такому API идут инструменты отладки Xcode. Да, сам по себе Xcode отвратителен как IDE для написания кода, но именно инструменты отладки Metal там эталонные. Там больше удобства и возможностей, чем и в RenderDoc от коммьюнити, и в PIX от Microsoft. И он позволяет отлаживать произвольные программы, в том числе собранные вне Xcode. К тому же синхронные обновления с самим Metal

Собственно, даже люди, пользующиеся обертками над нативными графическими API, нередко предпочитают использовать именно инструменты Metal для отладки, даже при наличии поддержки в PIX и RenderDoc

Но все эти чудесные плюсы перечеркиваются одним жирным минусом - Metal работает только на платформах Apple, и больше нигде. Если у вас есть устройство на macOS - вы очень счастливый человек, потому что можете использовать именно его. Но если вас интересует разработка под другие операционные системы, то из уютного Metal придется выйти в мир жестокой реальности Vulkan и DX12, где надо в 5 раз больше кода, чтобы сделать то же самое

А учитывая, что львиную долю десктопных операционных систем составляет Windows - выйти за пределы macOS и Metal всё же придется. Кто-то решает это изначальным использованием Vulkan на всех платформах, кто-то делает отдельные рендер бэкенды на DX12 и Metal, чтобы наоборот, не связываться с Vulkan. Но такова жестокая реальность - пользоваться только одним удобным нативным API скорее всего не получится

Особняком стоят графические API в виде библиотек - оберток

Это API, реализуемые не драйвером в системе напрямую, а поверх вышеперечисленных нативных API в виде некой обертки с собственным интерфейсом

Их довольно много, для разных задач и поверх разных API. Как пример можно привести IGL от Meta и SDL GPU

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

Я считаю, что есть выбор получше, о котором и расскажу дальше

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

Собственно, это и было призвано исправить появление WebGPU в 2021 году. Рабочая группа W3C из Google, Mozilla, Apple и Khronos опубликовали первый черновик нового стандарта графического API для браузеров

Это был не порт какого-то существующего решения, а полностью новое API, созданное как общий знаменатель между тремя актуальными нативными вариантами - Vulkan, DX12, Metal. Оно сравнимо по сложности с OpenGL и Metal, намного проще DX12 и Vulkan. И приносит в браузерную среду долгожданные возможности вроде вычислительных шейдеров, которые на нативных платформах доступны аж с 2012 года

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

Так появились dawn, реализация на C/C++ под нужды Chromium, и wgpu - реализация на Rust под нужды Mozilla с привязками к другим языкам.

Rust версия не только весит почти в 10 раз меньше в виде библиотеки, но и давно вышла за пределы стандарта WebGPU, предлагая разработчикам возможности нативных API вне браузеров, вроде трассировки лучей и пуш констант

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

Таким образом, wgpu стала де-факто решением для графики в экосистеме Rust. Его используют и онлайн-игры, и игровые движки, и системы рендера, и рантаймы нейросетей, и GUI-библиотеки, и многие другие

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

wgpu позволяет использовать условные 80% возможностей современных нативных API, оставаясь при этом полностью кроссплатформерным и сохраняя сложность на уровне OpenGL. Что делает его идеальным выбором для большинства проектов, что и заметно по экосистеме и его использованию

Вдобавок, это реализация W3C стандарта, использующаяся в одном из главных браузеров, что говорит о поддержке и переносимости решений. Например, сейчас довольно легко перенести примеры для браузерного WebGPU с JS на Rust или C++ почти 1 к 1, именно благодаря данным фактам

К тому же, это единственное современное API, поддерживающее одновременно как все нативные платформы, так и браузеры. А такая широкая поддержка платформ позволяет отлаживать его любым инструментом для нативных API - и RenderDoc, и PIX, и Xcode

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

Собственно, это и есть то API, которым пользуюсь я везде, где мне в принципе нужна графика. OpenGL слишком отсталый, Vulkan и DX12 слишком трудозатратные для 99% задач, а Metal недоступен на большинстве платформ. В таких условиях WebGPU, а конкретно его реализация wgpu, является самым удобным и оптимальным решением, даже на нативных платформах

Отдельно стоит пройтись по шейдерам, которые нужны для любого графического API

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

Есть несколько вариантов языков для их написания:

1. GLSL - похож на C, используется в OpenGL и Vulkan

2. HLSL - похож на C++ относительно новых стандартов (около 14), используется в DX12, с недавних пор есть поддержка Vulkan

3. MSL - тоже похож на C++ (примерно 11 стандарт), используется исключительно в Metal

4. WGSL - похож на Rust, используется в WebGPU и библиотеках-реализациях

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

- Vulkan потребляет SPIR-V, полученный из GLSL или HLSL после сборки (забавный факт - изначально SPIR-V рассматривался как формат шейдеров для WebGPU, но из-за его непродуманности и нестабильности был отвергнут)

- DX12 потребляет DXBC, DXIL или (с недавних пор) SPIR-V, полученные из HLSL. DXBC - старый, менее оптимизированный, но более простой в получении формат, тогда как DXIL - более современный, более производительный, но более сложный. SPIR-V же изначально является форматом Vulkan, недавно он был добавлен в рамках расширения совместимости

- Metal потребляет AIR файлы, полученные после сборки из MSL

- WebGPU принимает WGSL файлы, после чего с помощью компилятора шейдеров превращает его в один из перечисленных выше форматов байткода для использования в нижележащем нативном API. У dawn компилятором служит tint, у wgpu - naga. При этом Naga отличается очень высокой производительностью, преобразуя один шейдер за примерно 150 микросекунд

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

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

Здесь снова виден возраст OpenGL, который не имеет возможности заранее оптимизировать или провалидировать код шейдеров, и драйвер должен делать это самостоятельно во время работы программы. И хотя в версии 4.6 добавили опциональную поддержку SPIR-V, данная версия доступна исключительно на Windows и Linux, и фичу используют крайне редко

Тем временем, Apple анонсировали выпуск полной поддержки WebGPU в Safari 26, которая уже в бете

Все Chromium-based браузеры (то есть всё, что не Сафари или Огнелис) уже давно поддерживают на Windows и macOS

Это значит, что ждем только Firefox (работает только в Nightly и не везде) и Chromium на Linux для полной поддержки везде

Новость на самом деле очень важная, потому что Apple тянули с поддержкой WebGL 2 много лет. При этом их браузер второй в мире по популярности после Chrome, то есть они могут легко затормозить развитие технологии, просто не поддерживая ее.

Но тут видимо даже им уже надоел WebGL, раз они так оперативно катят поддержку

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

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

https://webkit.org/blog/16993/news-from-wwdc25-web-technology-coming-this-fall-in-safari-26-beta/

Как же так получилось, кто бы знал...

А мне вот адепты крестов говорили, что никому он не нужен и никто не использует (отдельный мем)

Сорри, но тут я не удержался уж, слишком сочно

Итак, Apple выложили информацию про новый Metal 4, который придет этой осенью с обновлением их операционных систем

Этим релизом они решили почти полностью сломать совместимость с нынешним Metal 3 и прошлыми версиями, ради большей совместимости с концепциями Vulkan и DX12

Теперь из старого API по сути остался только MTLDevice, все остальное изменено. Например, вместо MTLCommandQueue, теперь MTL4CommandQueue

Сделали аллокаторы, таблицы аргументов и прочие сущности, которые раньше только в более сложных API встречались

Главное изменение - теперь все ресурсы требуют ручной синхронизации, никакого автоматического отслеживания, которое было в Metal 3, OpenGL и WebGPU, и спасало от кучи ошибок

Из плюсов - добавили свой аналог DLSS 4, с генерацией кадров, денойзером, апскейлером и тд

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

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

Причем Metal 3 уже поддерживал ручное управление ресурсами и прочие оптимизации, но они не были обязательными и не мешали просто использовать API для своих проектов без лишней сложности. А теперь оно становится и более трудным, и обязательным

Понятно, зачем Apple это сделали - они уже давно очень хотят на игровой рынок, и это упростит миграцию игр от крупных студий с Windows, которые и так используют DX12 или, реже, Vulkan

Но для обычных разработчиков, особенно и так пишущих под платформы Apple на Metal, это огромное усложнение и раздувание кода, как мне кажется, будет скорее жирным минусом

С такими новостями WebGPU остается единственным выбором на нативе для одиночек и малых коллективов, когда теперь уже все три нативных API стали слишком переусложнены

По сути, сейчас из простых, но мощных вариантов - только wgpu, dawn, sdl-gpu и blade.

Но у wgpu преимущество, благодаря широкой распространенности и популяризации стандарта, на котором оно основано

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

Как говорится, пост по просьбам трудящихся

Известные мне способы процедурной генерации игровых миров:

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

2. Простой ландшафт в 3д, полностью процедурный, делают через марширующие кубы или тетраэдры. Кубы были открыты первыми и запатентованы, и патент протух только недавно, поэтому долго использовали свободный вариант на тетраэдрах. Например в Deep Rock Galactic изначальная генерация карты делается именно марширующими тетраэдрами

3. Если хочется гибко изменять 3д ландшафт - CSG, Constructive Solid Geometry. Это много про что, но в данном случае про воксельные миры с плавным редактированием ландшафта. Например в том же Deep Rock Galactic копание и прочие изменения пещер и стен уже во время матча сделаны именно так

4. Если хочется наделать самому какие-то ассеты, из которых потом процедурно строить мир - это WFC, Wave Function Collapse. В 3д или 2д, тут не важно. Звучит страшно, но на самом деле довольно простая штука для понимания, можно видео погуглить. По сути руками делаешь ассеты, потом задаешь правила их размещения ("тайлы с лесом только рядом с тайлами лугов" и тд), а дальше оно генерит тебе мир какого хочешь размера. Townscaper как пример игры на этом. Очень мощная вещь, но в продвинутых 3д вариантах бывает сложно реализовать нормально. Возможность генерировать мир из готовых ассетов тут и минус (нужно их иметь), и плюс - можно гибко подстроить арт дизайн и прочие детали, которые процедурно делать замучаешься

5. Бывают всякие кастомные алгоритмы, например как в Shadows of Doubt. Там процедурное вообще всё - здания, этажи, интерьер помещений, содержимое записок и компьютеров, жители, их работы, предыстории, отношения и так далее. На самом деле это несколько отдельных алгоритмов для разных этапов подобной генерации, например стены, окна и комнаты сами по себе генерируются тайлами 15х15. Тут уже только в девлоги конкретной игры погружаться, чтобы раскопать, как всё сделано

6. Cellular Automata, оно же клеточный автомат. Самым известным примером является игра "Жизнь". Однако применим и в процедурной генерации игр, а точнее для генерации карты пещер или данжей, островов и так далее. Обычно генерируется 2д картинка, которая потом уже используется для следующего этапа 3д генерации

7. Довольно эффективным способом генерации случайных закрытых пространств является использование теории графов. Мы не пытаемся сгенерировать сразу же 3д модель мира, вместо этого мы делаем граф, где вершины - комнаты, пещеры, помещения и прочее, а ребра - коридоры и проходы между ними. Тогда мы можем использовать стандартные алгоритмы на графах для оптимизации путей прохождения, обеспечения ограничений (чтобы комната с боссом была не слишком далеко от точки входа, например), и так далее. А дальше, по уже готовому графу, можно переходить к более подробной генерации деталей, визуальных частей и так далее, как и в клеточных автоматах. Такой способ использует Enter the Gungeon, также отдаленно похож аналог на массивах из Diablo 1

8. Для расположения камней в мире, деревьев в лесу и других подобных объектов, которые должны быть случайно раскиданы, но не ближе заданной дистанции друг к другу, можно использовать Poisson-disc Sampling. Результат выглядит гораздо более естественно, чем при использовании простой карты шума

9. Еще один, на этот раз очень простой для реализации алгоритм - Random Walk. Быстро работает, дает гарантированно соединенные между собой области, банально проще клеточных автоматов, шумов Перлина и Вороного, и так далее. Конечно, результат часто не впечатляет, но для простых пещер вполне подойдет

В большинстве игр используются сразу несколько алгоритмов. Например в Lost Flame используют и шум Перлина, и клеточные автоматы, и обычной выбор типа тайла по псевдослучайному генератору. А в Nuclear Throne используют клеточные автоматы, Poisson-disc Sampling и Random Walk

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

Разбавлю поток информации про графику и геймдев немного

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

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

Это позволяет математически доказать, что алгоритм валиден, не может находиться в некорректном состоянии ни при каких условиях, и так далее

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

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

1. Rocq, он же раньше назывался Coq. Более старый и широкомасштабный. Построен больше на описании теорем и их доказательстве

2. TLA+, создан Лэмпортом и больше похож на бред математика, однако обладает собственной IDE на базе Eclipse под названием TLA Toolbox, а также отдельным набором инструментов проверки спецификаций. Больше используется для описания систем и процессов, чем теорем, хотя оно тоже возможно

3. Pluscal. По сути то же самое для TLA+, чем Typescript является для Javascript. То есть надстройка, которая превращается в своего более урезанного и проблемного собрата после сборки. В отличие от остальных, уже отдаленно напоминает языки программирования. Так как превращается в TLA+, то использует все те же инструменты и ту же IDE

Я больше знаком с TLA+/Pluscal, поскольку их используют для верификации распределенных алгоритмов, планировщиков задач и так далее

Например, Amazon в своих AWS с помощью TLA+ нашли баг, затрагивающий их сервисы S3 и DynamoDB, который требовал 35 шагов для воспроизведения и не был обнаружен ни тестами, ни двумя код ревью

По сути, процесс верификации на TLA+/Pluscal выглядит так:

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

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

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

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

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

Тем временем, Mozilla готовится к включению WebGPU в релизе FIrefox 141 на Windows

Остальные платформы подъедут позже, но для Windows пулл реквест с включением уже на ревью и ожидается в следующем выпуске браузера

С такими темпами адаптации, можно сказать, что через пару-тройку лет должно быть доступно уже повсеместно

Накидаю небольшую памятку по вероятностным структурам данных

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

Самый наверно известный представитель - Фильтр Блума (Bloom Filter). Позволяет очень быстро проверить принадлежность элемента ко множеству, при этом может давать ложноположительные срабатывания, но никогда не ложноотрицательные. Используется много где, например в базах данных для быстрой проверки, входит ли первичный ключ в сегмент или файл данных на диске без поиска по нему. Если фильтр сказал, что ключа там нет - его там гарантированно нет, что позволяет существенно оптимизировать время поиска (например в СУБД на базе LSM, где каждая SSTable хранится в отдельном файле). Также полезно для реализации кешей, блеклистов и прочих случаев, когда нам нужно быстро исключить возможность принадлежности элемента ко множеству. Ключевым свойством является полная независимость сложности поиска элемента от количества элементов в фильтре. Вдобавок, всего 10 бит на одно хранимое значение снижают вероятность ложноположительного обращения до 1%

Также есть развитие идей фильтра Блума в виде Cuckoo Filter и Quotient Filter, которые уже поддерживают удаление элементов, но более сложны в реализации и потребляют больше памяти.

Из другого есть Count-Min Sketch, который позволяет очень эффективно подсчитать частоту элементов в потоке данных, но с небольшой вероятностью ее завышения. Больше подходит для анализа трафика, рекомендаций и подобного

Далее идет HyperLogLog, занятная штука, позволяющая найти количество уникальных элементов во множестве, но имеющая незначительную вероятность ошибки (около 1% в типичных применениях). Всего 1.5 кбайт памяти достаточно для анализа более чем 10^9 элементов. Используется для подсчета уникальных посетителей систем, аналитики и работы с большими данными

Также есть T-Digest, который может быстро найти распределение элементов по перцентилям, однако тоже имеет некую погрешность. Часто используется в A/B тестах, иногда в машинном обучении и других сферах

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

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

Например, Google Chrome использует фильтры Блума для быстрого распознавания вредоносных URL, а Medium для своей рекомендательной системы, отсеивая уже просмотренные посты. В то время как HyperLogLog напрямую доступен в Redis через команды pfadd и pfcount для подсчета количества уникальных событий

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

Последнее время стараюсь если и прокрастинировать, то все равно делать что-то полезное

Например, вместо диссертации пишу многострадальный гайд по графике на wgpu

Все равно ощущение, что займет это годы, но так хоть какой-то прогресс будет

А если летом защищусь и решу вопрос с призывом, то еще больше времени появится

Дописал вторую главу туториала, вроде бы

Постоянно нахожу, что еще можно дописать или отредактировать, но пока вроде всё устраивает

Вышло 3954 слова без учета блоков кода или 4627 с ними (диаграммы тоже считаются за блоки кода, поскольку они в формате Mermaid)

Надеюсь, что следующие главы будут поменьше, но как будто ощущение, что нет)

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