Dagon 0.40.0

Этот релиз ознаменовался серьезным рефакторингом постпроцессинга в движке: внесено множество оптимизаций и новых возможностей, а также появилась поддержка пользовательских фильтров (PostProcRenderer.addFilterPass). Возвращена поддержка автоэкспозиции, которая когда-то уже была реализована, но впоследствии удалена из-за архитектурных изменений в движке. Управляется параметрами hdr.autoexposure, hdr.keyValue, hdr.exposureAdaptationSpeed в render.conf. Добавлены эффекты виньетирования (vignette.enabled, vignette.strength, vignette.size, vignette.roundness, vignette.feathering) и film grain (filmGrain.enabled, filmGrain.colored). Реализован высококачественный фильтр повышения резкости с алгоритмом на основе FidelityFX CAS (sharpening.enabled, sharpening.strength). Добавлены новый тонмаппер Lottes (hdr.tonemapper: "Lottes"), новые параметры фильтра Depth of Field (dof.circleOfConfusion, dof.pentagonBokeh, dof.pentagonBokehFeather), улучшен фильтр шумоподавления SSAO — добавлена поддержка взвешивания на основе глубины, что устраняет гало-артефакты на близких расстояниях. Фильтр цветокоррекции теперь поддерживает изменение яркости, контраста и насыщенности (cc.brightness, cc.contrast, cc.saturation). Также можно напрямую задать 4×4 матрицу цветокоррекции (cc.colorMatrix). Если используется LUT, эти параметры игнорируются.

Улучшен воркфлоу таблиц цветокоррекции (LUT). Добавлено новое свойство TextureAsset.lutFormat, посредством которого загрузчик текстур понимает, что нужно конвертировать двумерную таблицу в 3D-текстуру. Поддерживаются два формата — LUTFormat.Hald и LUTFormat.GPUImage. Свойство TextureAsset.loadAs3D удалено, вместо него теперь надо задавать TextureAsset.lutFormat = LUTFormat.Hald;. Дефолтная таблица формата GPUImage (загружаемая опцией lut.file) теперь автоматически конвертируется в 3D-текстуру. Если вы загружаете GPUImage LUT вручную, то можно ее не конвертировать, но отныне рекомендуется делать это для более эффективного сэмплинга в шейдере.

Добавлен опциональный вывод в честный sRGB вместо обычного Gamma 2.2. Теперь можно задать цветовой профиль вывода при помощи опции gl.outputColorProfile в settings.conf. Возможные значения (строковые): "Gamma22", "sRGB".

Реализована поддержка глобальных определений макропроцессора GLSL (функция globalShaderDefine в dagon.graphics.shader). Чтобы их использовать в шейдерах, нужно добавить виртуальный инклюд #include <dagon>.

Добавлена поддержка сохранения в DDS кубических карт, 3D-текстур и RGTC-текстур. Появилась новая функция downloadTexture для выгрузки текстур любого формата из видеопамяти.

Появился новый тип событий EventType.KeyboardLayoutChange и соответствующий метод-обработчик onKeyboardLayoutChange. Это событие возникает, когда пользователь переключает раскладку клавиатуры.

Dagon 0.39.0

Новая версия движка. Добавил возможность загружать кастомные курсоры и заменять ими системные курсоры в приложении (методы Application.loadCursor, Application.replaceCursor). Появилась поддержка многомониторных конфигураций — теперь можно задать индекс монитора для создания игрового окна (опция window.display в settings.conf). Добавлены новые свойства класса Application: displayCount, displayIndex, displayWidth, displayHeight, desktopWidth, desktopHeight, refreshRate, framebufferFormat.

В модуль dagon.graphics.shape добавлены новые геометрические тела: ShapeCapsule (капсула), ShapeTorus (тор).

Появилась Поддержка uniform-массивов — шаблонный класс ShaderParameterArray и метод Shader.createParameterArray. Методы Shader.setParameter, Shader.setParameterRef, Shader.setParameterCallback, Shader.setParameterSubroutine, Shader.getParameterValue помечены как deprecated. Рекомендуется работать с объектами параметров напрямую.

Добавлена поддержка несжатых текстур RGB8 и RGBA8 в экспортер DDS, а также несжатых RGB8 в загрузчик DDS. Реализована перегрузка функции loadImageViaSDLImage, которая возвращает SDL_Surface*.

Dagon 0.32.0

Очередной релиз Dagon содержит значительное изменение — переход на OpenGL 4.3. Это не должно сильно ударить по поддержке видеокарт (движок работает на всех десктопных видеокартах, выпущенных за последние лет 10), но дает много новых возможностей, в особенности — доступ к вычислительным шейдерам. Соответственно, появился новый класс ComputeShader, о работе с которым я писал ранее. Добавлен один встроенный вычислительный шейдер — dagon.compute.resample, реализация ресэмплинга текстур. Еще одна фича OpenGL 4.3 — кэширование шейдерных бинарников. В теории это должно ускорять их загрузку, хотя в Dagon встроенных шейдеров не так уж и много, и кэширование пока большого значения не имеет. По умолчанию оно отключено — можно включить свойством Application.shaderCache.enabled, либо опцией enableShaderCache в settings.conf. Бинарники сохраняются в папку data/__internal/shader_cache.

Добавлен арена-аллокатор (dagon.core.arena) — я о нем тоже писал отдельный пост. Пока он, впрочем, не используется встроенными классами движка, но пригодится в будущем для интеграции GScript.

Новый модуль dagon.core.dialogs — минимальное кроссплатформенное решение для открытия системного диалога открытия/сохранения файла. Поддерживает Windows и Linux, зависимости при линковке не тянет. Под GNOME работает на основе Zenity, под KDE — на основе kdialog.

Добавлена поддержка так называемого «оконного полноэкранного режима»: если в конфиге заданы нулевые windowWidth и windowHeight, то движок создает безрамочное окно размером с весь экран. Этот режим удобен для мультимониторных конфигураций.

Наконец, добавлено новое расширение dagon:audio для воспроизведения звука через библиотеку SoLoud. Сама библиотека, как обычно, предоставляется в готовом виде при компиляции под 64-битные Windows и Linux. Под Windows также предоставляется libopenmpt для поддержки трекерной музыки.

Вычислительные шейдеры в Dagon

С переходом на OpenGL 4.3 в движке появляется возможность использовать вычислительные шейдеры. Они довольно удобно легли поверх уже существующией шейдерной системы — добавились всего два новых класса, ComputeProgram (аналог ShaderProgram) и ComputeShader, наследующий от Shader. Механизм привязки параметров целиком остается тот же самый, никаких изменений, за исключением способа привязки текстур — для этого есть метод ComputeShader.bindImageTexture. Привязываются обычные текстуры Dagon, как-то специально их готовить не нужно. Чтобы создать свой шейдер, нужно наследовать от ComputeShader, создать программу и параметры, а в bindParameters, как обычно, задать им значения:

class TestComputeShader: ComputeShader
{
   protected:
    String cs;
    ShaderParameter!Color4f _fillColor;

   public:
    Texture outputTexture;
    Color4f fillColor = Color4f(1.0f, 1.0f, 1.0f, 1.0f);

    this(Owner owner)
    {
        cs = Shader.load("data/test.comp.glsl");
        ComputeProgram p = New!ComputeProgram(cs, this);
        super(p, owner);

        _fillColor = createParameter!Color4f("fillColor");
    }

    ~this()
    {
        cs.free();
    }

    override void bindParameters(GraphicsState* state)
    {
        _fillColor = fillColor;

        if (outputTexture)
            bindImageTexture(0, outputTexture, TextureAccessMode.Write);

        super.bindParameters(state);
    }

    void run()
    {
        if (outputTexture)
            super.run(outputTexture.width, outputTexture.height);
    }
}

TestComputeShader cs = New!TestComputeShader(assetManager);
cs.outputTexture = myTexture;
cs.fillColor = Color4f(0.0f, 0.5f, 1.0f, 1.0f);
cs.run();

Пример шейдера, который заполняет текстуру «синусной плазмой» заданного цвета:

#version 430
layout(local_size_x = 16, local_size_y = 16, local_size_z = 1) in;

layout(rgba8, binding = 0) writeonly uniform image2D outputTexture;

uniform vec4 fillColor;

void main()
{
    ivec2 coord = ivec2(gl_GlobalInvocationID.xy);
    const float scale = 0.25;
    float value = 0.5f + 
        0.25f * cos(coord.x * scale) + 
        0.25f * cos(coord.y * scale);
    vec3 color = fillColor.rgb * value;
    imageStore(outputTexture, coord, vec4(color, 1.0));
}

ComputeShader.run уже ставит барьер памяти, в приложении это делать не нужно. Есть методы dispatch и barrier для запуска вручную.

Dagon 0.23.0

Обновил Dagon. Релиз не содержит нововведений и, в основном, оптимизирующий: теперь объекты Shader хранят прямые ссылки на параметры и обращаются по ним вместо строковых имен, когда записывают данные в методе bind. Индексы субрутин GLSL также извлекаются один раз при инициализации шейдера. Эта оптимизация дала весьма ощутимый прирост производительности на стороне CPU.

Удалено расширение dagon:stbi, так как стандартный загрузчик текстур Dagon полностью его заменяет. bindbc-sdl обновлен до версии 1.5.2.

К движку наконец-то появилась онлайн-документация — она доступна здесь. Документация генерируется из исходников. Полностью задокументированы пакеты dagon.core, dagon.graphics, dagon.resource, dagon.game и dagon.ui.

LDC поддерживает SPIR-V!

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

module main;

import ldc.attributes;

@callingConvention("spir_kernel")
@llvmAttr("hlsl.shader", "compute")
extern(C) void compute_main() nothrow @nogc
{
    //
}
ldc2 -betterC -vgc -c --output-o -of=main.spv --mtriple=spirv-unknown-vulkan -mattr=+spirv1.0 source/main.d

Если вывести ассемблерный листинг, получается следующее:

OpCapability Shader
OpMemoryModel Logical GLSL450
OpEntryPoint GLCompute %3 "compute_main"
OpSource Unknown 0
OpName %3 "compute_main"
%1 = OpTypeVoid
%2 = OpTypeFunction %1
%3 = OpFunction %1 None %2
%4 = OpLabel
OpReturn
OpFunctionEnd

Как видно, можно использовать этот SPIR-V модуль как вычислительный шейдер в Vulkan и OpenGL 4.6. Поддержки других видов шейдеров пока нет, но кто знает — может быть в один прекрасный день получится использовать D в качестве полноценного шейдерного языка! Я лично в это верю.

std140: статическая валидация структур

std140 — самый платформонезависимый лейаут uniform-блоков. Если вы передаете параметры в шейдер структурами, а не по одному, то лучше использовать именно его. Конечно, у переносимости есть своя цена: стандарт предусматривает несколько ограничений, самое известное из которых — выравнивание по 16 байтам. То есть, все поля структуры должны быть по смещению кратны 16 байтам. Использование невыровненных данных приводит к тому, что в шейдере считываются неправильные значения, и это вызывает недоумение у начинающих.

Благодаря CTFE и статической интроспекции в D можно проверять структуры на соответствие этому правилу на этапе компиляции — все необходимое есть в std.traits:

bool isFieldsOffsetAligned(T, alias numBytes)()
{
    static if (is(T == struct))
    {
        static foreach(f; T.tupleof)
        {
            static if (f.offsetof % numBytes != 0)
                return false;
        }
        
        return true;
    }
    else return false;
}

alias isStd140Compliant(T) = isFieldsOffsetAligned!(T, 16);

Теперь можно делать так:

import dlib.math.vector;
import dlib.math.matrix;

struct Uniforms
{
    float someParameter;
    Matrix4x4f modelViewMatrix;
    Matrix4x4f normalMatrix;
    Vector4f worldPosition;
}

static assert(isStd140Compliant!Uniforms,
    Uniforms.stringof ~ " does not conform to std140 layout");

Возникает вопрос, почему бы просто не делать align(16)? Можно!

struct AlignedUniforms
{
  align(16):
    float a;
    Vector3f b;
    Matrix4x4f c;
}

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

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

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

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, как я, слегка непривычно, но жить можно 🙂

Репозиторий

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

Первое знакомство с WGSL

У тех, кто работает с низкоуровневой графикой, сегодня на слуху WebGPU — новый кроссплатформенный API для доступа к возможностям современных видеокарт. WebGPU призван объединить Vulkan, Metal и D3D12 под унифицированным набором функций и станет не просто веб-стандартом, но и, в перспективе, неплохой заменой OpenGL: реализации этого API уже существуют в виде рабочих прототипов wgpu-native от Mozilla и Dawn от Google — любой может использовать их в своих собственных приложениях.

WebGPU имеет сравнительно простую архитектуру, доступную для понимания «простыми смертными» практически с первого прочтения заголовочного файла. Единственной проблемой до недавнего времени было отсутствие консенсуса по шейдерному языку — существующие реализации WebGPU использовали двоичное промежуточное представление SPIR-V от Khronos, а Apple настаивала на текстовом языке на основе WSL. Компромиссом стал WGSL (WebGPU Shading Language), высокоуровневый язык со строго определенной семантикой и буквальной трансляцией в/из SPIR-V. Многие разработчики оказались недовольны, так как SPIR-V уже успел стать привычным решением и оброс инструментами — сегодня можно компилировать в SPIR-V код на всех языках предыдущих поколений. Однако я вижу больше преимуществ, чем недостатков — перечислю некоторые из них.

  • Использование SPIR-V усложняет жизнь при создании игрового движка, требует внедрения дополнительной стадии компиляции шейдеров на стороне разработчика. Референсным компилятором шейдеров считатеся GLSLang от Khronos, но его довольно трудно встроить в приложение как библиотеку, особенно если вы не пишете на C++ — приходится использовать GLSLang как приложение, и это усложняет тулчейн разработки, если нужна кроссплатформенность. Встроенный в API высокоуровневый язык решает эту проблему.
  • WGSL разрабатывается как текстовый аналог SPIR-V — они имеют общий набор возможностей. Это значит, что не будет повторения ситуации с GLSL, когда язык по-разному обрабатывается в компиляторах от различных поставщиков. Сохраняется главное преимущество SPIR-V при высоком удобстве использования.
  • Vulkan-диалект GLSL 4.60, являющийся де-факто стандартным языком под SPIR-V, имеет множество костылей и архаизмов — у WGSL более продуманный синтаксис, лишенный неявности и многозначности.

Синтаксис WGSL имеет много общего с Rust, особенно заголовки функций:

fn someFunc(x: i32) -> i32 {
    //...
}

Типы объявляются через двоеточие после идентификатора, переменные — при помощи ключевого слова let, константность подразумевается по умолчанию. Для изменяемых переменных есть ключевое слово var. Система типов также пришла из вселенной Rust. Векторные типы имеют форму vec4<f32> (вместо простого vec4), что позволяет явным образом указать битовость используемых чисел. При этом можно объявить type vec4f = vec4<f32>; и писать коротко, если вам так привычнее.

Кстати, очень порадовало, что есть вывод типов — можно не указывать тип переменной, если она тут же инициализируется:

let a = vec4<f32>(0.0, 0.0, 0.0, 1.0);

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

[[location(0)]] position: vec4<f32>;

Встроенные переменные конвейера обозначаются атрибутом builtin, что весьма удобно при объявлении структур для хранения промежуточных результатов:

struct VertexOutput
{
    [[builtin(position)]] position: vec4<f32>;
    [[location(0)]] color: vec4<f32>;
};

Сравните это с GLSL, где для встроенных переменных используется зарезервированный префикс gl_.

Структуры, являющиеся uniform-блоками, помечаются атрибутом block:

[[block]] struct Uniforms {
    //...
};

Прямым аналогом вулкановских set и binding являются атрибуты group и binding.

Vulkan/GLSL:

layout(set=0, binding=0) uniform Uniforms uniforms;

WGSL:

[[group(0), binding(0)]] var uniforms: Uniforms;

Программы на WGSL можно не разделять на два текста — вершинный и фрагментный шейдеры можно хранить в одном файле и, таким образом, использовать общие объявления. Для этого используется атрибут stage. Названия самих входных точек могут быть произвольными, но чаще всего в примерах используют vs_main и fs_main.

[[stage(vertex)]]
fn vs_main() -> VertexOutput
{
    //...
}

[[stage(fragment)]]
fn fs_main(input: FragmentInput) -> [[location(0)]] vec4<f32>
{
    //...
}

Очень непривычно в WGSL записываются циклы:

var i = i32(0);
loop {
    break if (i == 5);
    //...
    continuing {
        i = i + 1;
    }
}

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

Подведу итог: с первого взгляда WGSL кажется хорошим решением давней проблемы с языками шейдеров. Высокоуровневое представление SPIR-V — это отличная идея. Непривычный синтаксис и конструкции со спорным юзабилити могут усложнить портирование на WGSL готовых шейдеров, но в целом впечатление от языка весьма позитивное.

Шейдер ландшафта и декали

Наконец-то добавил в Dagon специализированный материал для объекта Terrain — 4-канальный шейдер ландшафта, поддерживающий карты нормалей.

До этого также появилась поддержка отложенного рендеринга декалей (deferred decals) — текстур, проецируемых на статические объекты. При помощи декалей можно сделать на поверхностях различные следы, пятна, надписи, граффити, мелкий мусор и т.д. Для декалей поддерживаются карты нормалей, PBR и излучения света, так что они позволяют разнообразить сцену с высокой степенью реалистичности. Реализованы они путем блиттинга текстур в G-буфер — таким образом, декали могут быть отрисованы поверх уже отрендеренной геометрии с возможность смешивания цвета, нормалей и других атрибутов поверхности по альфа-маске. В демо-приложении Dagon декали используются для рендеринга следов игрока на земле: