IDE с поддержкой шейдерных языков мечты

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

Какие инструменты есть прямо сейчас?

Существует ли адекватная IDE для шейдерных языков? С поддержкой навигации по коду, подсказками, проверкой типов, развёрткой макросов? Я не встречал, и опрос среди коллег такую IDE не выявил. 

Есть VSCode, есть Sublime, Notepad++ и другие редакторы с подсветкой синтаксиса, которые используют render-программисты в разных студиях, но полноценного инструмента нет.

Нет навигации по коду: банального Go to Declaraction, Type checking, Completion и я не говорю о множестве необходимых тултипов, которые могли бы существовать в такой IDE. Большое количество различных подсказок, наверняка, помогло бы убрать лишнее передвижение по файлам, чтобы посмотреть семантику переменных, преобразований, каналов в текстурах и т.д.

Нужна ли вообще такая IDE? Судите сами: в современной игре шейдерных код занимает немалую часть программного кода игры – модель освещения (глобальное освещение, локальные источники света), техники отражения, различные пост-эффекты: depth of field, motion blur, техники сглаживания без которых ААА игры сейчас немыслимы написаны на шейдерных языках без IDE, разработчики ААА движков делают свои функции макросов для поддержки различных пермутаций шейдеров : для поддержки instancing’a, для разных типов мешей: skinned/не skinned и так далее.

А представьте насколько усложнится поддержка кода, когда будут использоваться новые типы шейдеров: mesh-шейдеры от nVidia, рейтрейсинг шейдеры?

Художники тоже программируют шейдеры

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

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

Я думаю, что большая часть разработчиков игр, занимаются программированием, но не подозревают, что это оно “программирование”.

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

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

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

А ещё чаще в пределах одного шейдера копируется пачка блоков. К чему это приводит? Как и с копипастой в коде — к тому, что теперь этому разработчику: поддерживать, исправлять ошибки и вносить исправления придется в N шейдерах, N блоках (N x N блоках, если исправление нужно будет внести в блоке, а шейдер с таким блоком уже копипастился).

Мне кажется нужно взять хорошего UX-дизайнера и сделать более продвинутый нодовый редактор. Я бы сделал это таким образом: для популярных движков сделать такой редактор и генерацию в шейдерный язык этого движка: glsl/hlsl/ShaderLab в Unity, и hlsl/ushade в Unreal Engine.

Тем более, что Unity, например, испытывает проблемы с поддержкой шейдеров из shadergraph в разных пайплайнах, это можно было бы решить таким образом.

Нет общей стандартной библиотеки модулей

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