Ежемесячные архивы: Декабрь 2024

Бокс-проекция

Добавил в Dagon поддержку бокс-проекции для световых зондов окружения (EnvironmentProbe). Техника старая, но никем не отмененная — а главное, хорошо сочетается с deferred-рендером!

Стандартный environment mapping предполагает, что стенки виртуальной среды, с которой считывается освещение, бесконечно удалены от объектов сцены. Это допущение работает для открытого пространства, но не годится для интерьера. Бокс-проекция корректирует сэмплинг из карты окружения так, что результат выровнен по сторонам бокса заданного размера, благодаря чему минимумом ресурсов достигается сносного качества непрямое освещение в интерьере (если, конечно, карта окружения 1 в 1 совпадает с моделью комнаты). Это эффективный способ аппроксимировать локальный GI в ограниченном пространстве: окружение интерьера, с которого рендерилась карта, статичное, но любые другие объекты могут быть динамическими. При трансформации камеры или объекта внутри комнаты, отражения соответствующим образом меняются, причем как зеркальные, так и диффузные.

Получается даже имитировать объемные источники света! На скриншотах ниже нет ничего, кроме параллельного источника света для солнца и двух статичных карт окружения — для улицы и для интерьера. Отражения окон и светящегося блока на полу получаются автоматически:

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

Сжатие текстур, часть IV. Мобильные форматы: ETC и PVRTC

  • Дата публикации: 24 декабря, 2024
  • /Метки: image processing
  • /Комментарии: 0

Продолжение серии постов о сжатых текстурных форматах. Предыдущие части: часть I, часть II, часть III.

Ситуация со сжатием текстур на мобильных платформах довольно запутанная, так как 3D-ускорители там существенно отличаются от десктопных. К сожалению, ни iOS, ни Android не поддерживают S3TC (и, тем более, BPTC). В мобильных системах используются свои специализированные форматы сжатия — ETC на Android и PVRTC на iOS.

ETC1 и ETC2

Ericsson Texture Compression / iPACKMAN

Формат сжатия от Ericsson. Поддерживается как в мобильных устройствах, так и в современных браузерах (кроме Firefox).

ETC1 поддерживается практически на всех android-устройствах и является стандартным форматом сжатия в OpenGL ES 2.0. Не поддерживает прозрачность. Блок 4×4 преобразуется в 64-битное представление. Блок разбивается на два субблока (4×2 или 2×4), им присваиваются базовые цвета — либо каждому RGB 4:4:4, либо одному 5:5:5, а второму смещение 3:3:3 относительно первого. Пиксели в субблоке представляются в виде суммы базового цвета и одного из четырех смещений — так называемых модификаторов: pixelColor = baseColor + RGB(modifier, modifier, modifier). Модификаторы, определяемые спецификацией, представляют собой 4×8 таблицу констант — целочисленных значений со знаком. Индексы ряда в таблице [0, 7] хранятся как два 3-битных значения (по одному на субблок), индексы столбца [0, 3] — как 16 2-битных значений (по одному на каждый пиксель). Оставшиеся два бита определяют ориентацию субблоков (flip-бит) и тип хранения базовых цветов (diff-бит). Результат суммирования нормализуется в 8 бит на канал.

ETC2 является стандартным форматом сжатия в OpenGL ES 3.0. Поддерживает прозрачность. ETC2 — это обратно-совместимое надмножество ETC1. Альфа-канал кодируется по такому же принципу, что и цвет: значение прозрачности для пикселя — это сумма базовой альфы и модификатора из таблицы констант 8×16. Блоку 4×4 присваиваются дополнительные 64 бита: 8-битное базовое значение альфа, 4-битный индекс ряда в таблице модификаторов, 4-битный множитель и 16 3-битных индексов столбцов.

Также в ETC2 есть отдельный режим punch-through (GL_COMPRESSED_RGB8_PUNCHTHROUGH_ALPHA1_ETC2), аналогичный ETC1, но в котором diff-бит заменяется битом прозрачности — таким образом, блок интерпретируется либо как полностью прозрачный, либо как полностью непрозрачный.

PVRTC1 и PVRTC2

PowerVR Texture Compression

Используется в видеоускорителях PowerVR (iPhone и другие устройства Apple). Основной целью разработчики формата поставили устранение разрывов цвета вдоль границ блоков, которая присуща S3TC. PVRTC поддерживает альфа-канал.

Имеет две разновидности — 4bpp и 2bpp. На блок всегда выделяется 64 бита информации, поэтому в режиме 4bpp блок имеет размер 4×4 пикселя, в режиме 2bpp — 8×4. В некоторых аппаратных реализациях блоки расположены в памяти не в порядке сканирования (снизу вверх, слева направо), а в Z-последовательности для увеличения пространственной локальности и, как следствие, более эффективного кэширования.

В каждом блоке хранится шесть переменных: для PVRTC1 — данные модуляции (32 бит), флаг punch-through alpha (1 бит), цвет A (15 бит), флаг прозрачности цвета A (1 бит), цвет B (14 бит) и флаг прозрачности цвета B (1 бит). Для PVRTC2 — данные модуляции (32 бит), флаг модуляции (1 бит), цвет B (15 бит), флаг hard transition (1 бит), цвет A (15 бит) и флаг прозрачности (1 бит). Битовая глубина значений A и B задается по-разному в зависимости от того, есть ли альфа-канал: либо RGB 5:5:4(5), либо RGBA 3:4:4:3(4), в скобках указан вариант для 15-битного цвета. Дополнительный бит прозрачности определяет наличие у цвета альфа-канала. В PVRTC его можно задавать независимо для A и B, когда как в PVRTC2 бит прозрачности только один, и оба цвета должны быть в одинаковом формате — либо RGB, либо RGBA. Цвет пикселя вычисляется билинейной интерполяцией цветов A и B. Каждому пикселю блока сопоставляется, в зависимости от разновидности формата, 2-битное или 1-битное значение модуляции, кодирующее вес интерполяции между A и B.

PVRTC2 расширяет алгоритм поддержкой четырех разных режимов блока, задаваемых флагами hard transition в сочетании с флагом модуляции: стандартная билинейная, punch-through alpha, резкий переход, локальная палитра.

Тригонометрия в бенчмарках

  • Дата публикации: 15 декабря, 2024
  • /Метки: benchmark, d, ldc, math
  • /Комментарии: 0

«Неважно, что ты любишь больше:
косинус ли, синус ли…»

Тригонометрия — основа многих приложений, от компьютерной графики до научных симуляций. Все мы привыкли вызывать sin и cos, не задумываясь, как они реализованы. А реализации могут быть разные! Работая над математической библиотекой для dlib2, я провел интересное исследование — какая тригонометрия лучше? Конечно, есть функции из std.math, и в большинстве случаев подойдут именно они. Но не все так просто — все зависит от того, что именно вы разрабатываете.

Если вы собираете обычное приложение, то кажется, что беспокоиться не о чем. Но если вам, по тем или иным причинам, нельзя обращаться к Phobos? Тогда есть два основных пути — sin и cos из стандартной библиотеки C, либо кастомная реализация, если код собирается под голое железо (например, при создании ядра ОС или программировании встраиваемой электроники). Но если вы используете LDC, то ничто не мешает использовать интринсики LLVM — они, оказывается, работают быстрее, чем std.math!

Я провел ряд тестов для всех вариантов тригонометрии:

  • Тест на точность — вычисление синуса и косинуса для 200 аргументов от -π до +π. Замерялась максимальная погрешность — расхождение результата с std.math.sin и std.math.cos;
  • Тест на производительность — время вычисления синуса и косинуса 1000000 раз.

Во всех кейсах я использовал LDC 1.39.0 под Windows 10. Получилось следующее:

  • std.math.sin, std.math.cos:
    • Время выполнения: 4 мс
  • LLVM интринсики llvm_sin, llvm_cos:
    • Время выполнения: 2 мс
    • Точность: абсолютная (макс. погрешность для sin: 0, для cos: 0)
  • Функции sin, cos из стандартной библиотеки C:
    • Время выполнения: 21 мс
    • Точность: абсолютная (макс. погрешность для sin: 0, для cos: 0)
  • Моя кастомная реализация на таблицах:
    • Время выполнения: 33 мс
    • Точность: порядка 10-7 (макс. погрешность для sin: 2.97038e-07, для cos: 1.78188e-07)

Также я пробовал версию с ассемблерными вставками, но она получилась почему-то медленнее кастомной — видимо, при использовании инлайнового ассемблера компилятор не задействует какие-то оптимизации (а еще есть мнение, что x87 fsin, fcos на современных процессорах медленные сами по себе). Смысла в таком варианте реализации особо нет, так что я его не стал рассматривать для включения в библиотеку.

В итоге в dlib2 войдут четыре реализации с таким приоритетом:

  • Если используется LDC, то синус и косинус — это интринсики (то есть, кодогенератор сам выбирает оптимальную реализацию под нужную архитектуру);
  • Если используются другие компиляторы (DMD, GDC):
    • Если код компилируется с поддержкой Phobos, то используются функции из std.math;
    • Если код собирается в режиме version(NoPhobos), но не version(FreeStanding) (то есть, под Windows или Unix-подобную ОС), то используются функции рантайма C;
    • Если же идет компиляция в bare metal, то используется кастомная реализация на таблицах.

Итоги 2024 года

Декабрь — время традиционного подведения итогов за прошедший год:

  • Выпустил три версии Dagon — 0.16, 0.17 и 0.18. В движке появились подповерхностное рассеивание, зонды локального освещения среды, тональная компрессия AgX, улучшен встроенный контроллер персонажа. Добавлена поддержка Wayland под Linux и поддержка экранов с высокой частотой обновления. Наконец-то появились меш-группы в загрузчике OBJ, что позволяет рендерить загруженную модель по частям с различными материалами и настройками. Появился новый встроенный шейдер звездного неба для ночных сцен и игр с космической тематикой. Доступны новые примеры: веревка на основе интегрирования Верле и механика игры от третьего лица.
  • Dagon, в числе других примечательных проектов на языке D, был упомянут на конференции FOSDEM 2024 в Брюсселе, а позже на эту тему вышло интервью со мной в онлайн-издании «Вечерняя Казань».
  • Выпустил dlib 1.3.0, где был проделан ряд улучшений в математическом пакете и добавлен новый модуль dlib.math.random. Спасибо Александру Перфильеву aka aperfilev за багфиксы и поддержку GNU D Compiler в dlib.math.sse. В марте этого года библиотека побила все рекорды по скачиваниям за все время существования проекта — 14000 в месяц!

Ну и, конечно, небольшой список интересных событий в мире D и графического СПО:

  • Функция тональной компрессии AgX стала новым де-факто стандартом индустрии;
  • В языке Slang добавлена поддержка WGSL, что позволяет с большим удобством писать шейдеры для WebGPU-приложений;
  • На FOSDEM ’24 был представлен ознакомительный доклад о языке D и его преимуществах для разработки приложений компьютерной графики.
  • Upd: у GitHub Copilot появился бесплатный ограниченный доступ!

Dagon 0.18

  • Дата публикации: 11 декабря, 2024
  • /Метки: d, dagon, iqm, newton
  • /Комментарии: 0

Выпустил новую версию Dagon. В загрузчике OBJ наконец-то появилась поддержка групп — если в файле присутствуют группы, они будут доступны через свойство OBJAsset.groupMesh, так что вы можете использовать их в качестве отдельных мешей вместо единого OBJAsset.mesh. Также загрузчик теперь не падает на моделях с N-гонами, а выводит предупреждение, что они не поддерживаются.

Добавлен новый экстра-шейдер dagon.extra.starfieldsky — ночное небо со звездами. Он представляет собой улучшенную версию шейдера звездного неба из демки с планетой. Основное нововведение — поддержка мерцания звезд.

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

В dagon:iqm появились новые свойства для анимированных моделей: Actor.looping (зацикленность), Actor.state.finished (индикатор завершения текущей анимации). Исправлен баг с фейсгруппами при загрузке некоторых IQM.

Slang — универсальный шейдерный язык

  • Дата публикации: 2 декабря, 2024
  • /Метки: glsl, shader, slang, wgpu, wgsl
  • /Комментарии: 0

Что выглядит читабельнее? Это:

struct VertexOutput
{
    @builtin(position) position: vec4<f32>,
    @location(0) fragmentPosition: vec4<f32>
};

@vertex
fn vs_main(@builtin(vertex_index) vertexIndex: u32) -> VertexOutput
{
    let x = f32(i32(vertexIndex) - 1);
    let y = f32(i32(vertexIndex & 1u) * 2 - 1);
    var output: VertexOutput;
    output.position = vec4<f32>(x * 0.5, y * 0.5, 0.0, 1.0);
    output.fragmentPosition = 0.5 * (vec4<f32>(x, y, 0.0, 1.0) + 1.0);
    return output;
}

…или это:

struct VertexOutput
{
    float4 position: SV_Position;
    float4 fragmentPosition;
};

[shader("vertex")]
VertexOutput vertexMain(uint vertexIndex: SV_VertexID)
{
    let x = float(int(vertexIndex) - 1);
    let y = float(int(vertexIndex & 1u) * 2 - 1);
    VertexOutput output;
    output.position = float4(x * 0.5, y * 0.5, 0.0, 1.0);
    output.fragmentPosition = 0.5 * (float4(x, y, 0.0, 1.0) + 1.0);
    return output;
}

Второй листинг, на мой взгляд, выигрывает сравнение. Это код на Slang, HLSL-подобном языке, который позиционируется в качестве платформонезависимой основы для написания одних и тех же шейдеров под любые графические API, включая D3D12, Vulkan, Metal, OpenGL, а с недавних пор и WebGPU. Идея, конечно, не новая — если вы писали шейдеры в нулевые, то, наверное, помните Cg от NVIDIA — но с со времен попыток написать универсальный компилятор в низкоуровневые шейдерные языки утекло немало воды и сменилось несколько поколений графического железа. Сейчас, в эпоху Vulkan и SPIR-V, кросс-компиляция шейдеров актуальна как никогда: старичок GLSL уже сдает позиции, для новых стандартов создаются новые языки — индустрия переживает очередной этап фрагментации.

Я уже писал о своих впечатлениях от WGSL, встроенного шейдерного языка WebGPU, и многие его конструкции мне до сих кажутся спорными и неудобными. Особенно бесят типы вида vec4<f32>. Не так давно поддержка WGSL была добавлена в компилятор Slang, в связи с чем я теперь всерьез рассматриваю этот язык как основной для создания графического движка на WebGPU.

Главная киллер-фича Slang — это, конечно, модули. Причем, что интересно, есть и препроцессор а ля C с директивами #include, #ifdef и др. От HLSL и GLSL язык выгодно отличается большим набором фич, присущих современным высокоуровневым языкам: поддержкой вывода типов, пространств имен, функций-членов структур (с неизменяемым по умолчанию неявным this — по-моему, отличная идея!), а также конструкторов, геттеров/сеттеров и даже перегрузки операторов. Есть дженерики, интерфейсы, кортежи. Интересен тип Optional, который дополняет любой другой тип поддержкой значения none — чтобы можно было указать отсутствие какого-либо значения. Для SPIR-V и CUDA в языке есть ограниченная поддержка указателей. Очень полезный инструмент — декоратор ForceInline, который заменяет вызов функции подстановкой ее кода. Наконец, в языке есть автоматическое дифференцирование, которое используется в задачах машинного обучения.

Старую как мир проблему некоммутативности умножения матриц и векторов в Slang решили следующим образом: оператор * всегда означает произведение двух матриц, как принято в математике. Чтобы трансформировать вектор матрицей, нужно вместо m * v писать mul(v, m). Для такого старого ветерана OpenGL, как я, слегка непривычно, но жить можно 🙂

Репозиторий

Документация по языку