Я написал свой воксельный редактор. А стоило ли?

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

Я уже некоторое время занимаюсь разработкой игры с воксельной графикой. Она пока не анонсирована, так что подробностей не будет, но статья и не про игру, а про то, как я делал инструмент для создания ассетов для неё, а конкретно — всеми любимого маневрового локомотива ЧМЭ3.

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

Работа с вокселями — это как пиксель-арт, но в 3D. С одной стороны, примитивы простые и кажется, что рисовать очень легко; с другой — показать достаточные детали и (…). Так или иначе, это довольно занимательное занятие, и успех Minecraft тому подтверждение.

Я, не будучи художником, решил попробовать рисовать самостоятельно, и в качестве инструмента мой выбор пал на Goxel — бесплатный и опенсорсный воксельный редактор. Он показался мне более «технарским», чем MagicaVoxel и другие, хотя тут я не претендую на экспертизу и давать советы по выбору не стану.

Чего же меня в нём не устроило, что я решил написать свой редактор? По мелочи — невозможность загрузить полигональную модель и обводить её, неочевидная работа с материалами и слоями, проблемы со стабильностью и прочие мелочи. Но главная причина — он исповедовал другой подход. Goxel, как и MagicaVoxel, построен в философии «3D-фотошопа» с такими инструментами, как слои и группы. Я же, профдеформированный Unity, начинаю везде хотеть видеть иерархию, префабы, компоненты и прочие приколы от мира игровых движков.

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

Но ведь теперь у нас есть нейронки, а значит, каждый суслик — агроном. Зачем что-то учить и покупать (кроме подписки на Claude)? Почему бы не сделать редактор изначально под свои задачи и со своим пониманием его концепции.

Тут логично задаться вопросом: если есть нейронки, то зачем вообще редактор? И это, забегая вперёд, правильный вопрос. Но отмотаем время на год назад и проверим — можно ли вообще обойтись без воксельного редактора для создания ассетов, или нейронки сами всё сгенерят?

Дадим шанс нейронкам прошлого

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

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

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

Итак, у нас два участника: Opus 4.5 и Haiku 4.5, обе примерно годовой давности. Запускаем их без контекста проекта, но постепенно дорабатываем промт и входные данные — об этом далее.

Этап 1. Эскиз. Для начала я хочу просто представить, как этот локомотив выглядел бы в вокселе. Просьба ровно в одну фразу: «сделай воксельный локомотив ЧМЭ3».

Опус смог нарисовать капотный тепловоз, но это точно не наш. В целом похоже на модельку в масштабе N (1:160). Хайку сделал какой-то электрощит, лежащий на боку.

Этап 2. Уточняем масштаб. На Хайку надежды, похоже, нет, а вот Опус подаёт. Главная претензия к эскизу даже не непохожесть, а масштаб: это Lego Duplo, а мне нужно Lego City. Добавляю в просьбу ровно одну строчку: «Размер вокселя 45 мм».

Всё ещё фигня — игрушечный вагончик и Sci-Fi балка.

Этап 3. Даём референс. Извините за предыдущие два эксперимента — это время вам уже не вернут. Подойдём более серьёзно: дадим ему фотку, которую я прикладывал выше, и даже 3D-модель со Sketchfab, но уточним, что нам нужно не просто вокселизовать 3D-модель (с чем справился бы и детерминированный алгоритм), а всё же получить модель в воксельном стиле.

Опус 4.5 что-то понял, но это снова лишь отдалённо похоже на наш локомотив. А Хайку перешёл в жанр кубизма. Также замечу, что при попытке хотя бы просто вокселизовать 3D-модель они выдают кашу — я её даже не привожу.

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

VoxelCAD: Начало

Итак, перейдём к моему самодельному редактору. По сути я решил сделать Goxel, но сразу рассчитанный на геймдев, а не на статичную картинку. Движок взял Godot — он лёгкий, он на C#, который я знаю (спойлер: это не пригодилось).

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

И тут случилось то, что, я думаю, почувствовал почти каждый разработчик с приходом ИИ. Я писал задачи агенту и не смотрел код, потому что… в этом не было нужды. Фичи делались быстро. Настолько быстро, что я довольно скоро заметил неприятную вещь: я тормозил сам. Не агент упирался в сложность реализации — я упирался в то, что не знал, как должно быть устроено. Сколько режимов у трансформа и что делает режим «целые клетки», когда модель повёрнута на 37 градусов. Что происходит с вокселями, которые остались снаружи, когда уменьшаешь сцену. Должен ли клик по модели внутри префаба выделять модель или префаб.

Редактор получился настоящим. Там иерархия, префабы, три режима полей на каждый канал трансформа, симметрия, материалы, система рендеринга, импорт из MagicaVoxel и Qubicle, экспорт в OBJ, STL, FBX и обратно в vox. Интерфейс с прозрачностью и блюром и консольный режим. Подробно описывать не буду, скажу лишь, что это не прототип за выходные: 301 коммит, 839 файлов на C#, примерно 130 тысяч строк. Плюс рабочий журнал на 5886 строк, который агент вёл сам — туда писалось, что было сломано, почему и чем измерено, ну вы сами всё это знаете.

Осторожно, работает агент

Примерно в то же время я начал массово использовать MCP в Unity, и там меня быстро начало бесить одно: непонятно, кто сейчас рулит редактором. Агент что-то делает, и я что-то делаю, мы оба тыкаем в один редактор, мы друг другу мешаем. И если ничего не происходило, то было непонятно — агент закончил или завис. Разумеется, в моём редакторе MCP был задуман изначально, так что с этой проблемой я решил бороться на корню.

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

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

Успех?

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

Наложилось много факторов:

• Модели стали умнее. Они лучше рассуждают, лучше ищут информацию.

• Инструменты созрели. Claude Code, Codex, MCP в Unity. Теперь они могут сделать большинство рутинных операций самостоятельно.

• Я сам, много работая с агентами, научился давать промты лучше и точнее.

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

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

Вывод

Всё течёт, всё меняется. До эпохи ИИ самодельный воксельный редактор мог бы быть вполне уважаемым опенсорс-проектом, а теперь каждый разработчик может таких напилить десяток. Многие моменты разработки обесценились, и это касается не только VoxelCAD — тот же Goxel, который был для меня референсом, теперь легко повторить и даже превзойти. Но и это может быть лишним: при грамотном использовании сама нужда в таком классе инструмента может отпасть, а интеграция нейронок в пайплайн способна существенно ускорить разработку. Остаётся лишь держать нос по ветру, чтобы быть подхваченным волной изменений, а не погребённым под ней.