Зачем веб-сервису 3D-тамагочи: задача и контекст
Сервис для изучения английского Yet Another English добавил 3D-персонажа, которого пользователь выращивает из яйца за счёт занятий: учишь слова, получаешь награды, питомец растёт. «Тамагочи, только кормить его надо занятиями», — так описывает механику автор проекта в разборе на Habr.
Внешность придумывать заново не пришлось. У сервиса уже был персонаж на картинках: белый гусь в красном худи и жёлтой обуви. Нужно было оживить именно его, а не рисовать нового героя.
Требования к модели выходили далеко за рамки статичной картинки:
- показываться с разных сторон и анимироваться;
- одеваться: гусь поднимает крыло, рукав двигается вместе с ним; надевает шапку, она остаётся на голове при повороте;
- работать на странице сервиса, в том числе с телефона.
Питомец привязан к учебному прогрессу, поэтому 3D решает продуктовую задачу, а не только визуальную. Пользователь видит, как потраченные на слова усилия превращаются в изменение внешнего вида: яйцо, птенец, взрослая птица. Для сервиса это механика удержания, для пользователя — понятная награда за регулярные занятия.
Пайплайн: Claude Opus через MCP, затем GPT — как это работало
Работа началась с Claude Opus 5.0, подключённого к Blender через MCP, затем продолжилась через GPT. Затраты: около 14 часов (примерно неделя по два часа в день) и $100 за подписку Astra. Эти цифры дают ориентир для похожего проекта: одна модель, один 3D-редактор, один платный доступ к ассистенту.
Blender — программа, в которой создают и анимируют 3D-модели. Поверхность модели состоит из маленьких граней, которые при отрисовке разбиваются на треугольники. Чем их больше, тем сложнее может быть форма, но тем больше памяти занимает устройство. Для веб-страницы с мобильными пользователями этот компромисс стал главным ограничением.
MCP (Model Context Protocol) — открытый протокол, который обеспечивает интеграцию между LLM-приложениями и внешними источниками данных и инструментами. Здесь таким инструментом был Blender: ассистент работал с редактором напрямую, а не пересылал код в чат. Как именно передавались команды и что возвращал редактор, в разборе не раскрыто, поэтому схему стоит воспринимать как общий принцип: модель получает инструмент и результат его работы. Определение протокола и его назначение описаны в спецификации MCP и в документации GitHub.
Почему начали с Claude Opus и MCP
Связка дала быстрый старт: первая версия гуся появилась без моделирования с нуля. Цвета оказались правильными, шея и клюв на месте, но форма подвела. Худи превратилось в нагрудник, шея стала похожа на трубу. На пробах головы клюв получился объёмным, глаза выпученными, а брови выглядели как два бруска.
Эти артефакты полезны как ориентир: генерация через AI даёт заготовку, а не финальный ассет. MCP при этом не единственный способ подключить модель к 3D-редактору, это конкретный выбор автора.
Переход на GPT: зачем понадобилась смена инструмента
После первичной генерации работа продолжилась через GPT. Прямого объяснения причин в разборе нет, поэтому честнее обозначить границу: источник подтверждает сам факт двухэтапного пайплайна, но не мотивировку смены. Логика комбинирования моделей при этом понятна: разные ассистенты по-разному держат контекст и по-разному реагируют на визуальную обратную связь, и подбор пары под задачу — рабочая практика, а не каприз.
Похожие сценарии уже разбирались на AI-Manual: в кейсе с Qwen3.8-Flash-Next локальная модель за три часа собрала 3D-игру, и там результат во многом зависел от агентного цикла с самостоятельной проверкой, а не от одного удачного промта.
Практика итераций: ракурсы и правка формы
Точное число итераций по промтам в разборе не приводится, но объём работы известен: около 14 часов, примерно неделя по два часа в день. Причина такого количества правок в том, что AI-ассистент не видит 3D-объект: он работает с изображениями, которые ему присылают, и строит выводы по ним.
Почему одного ракурса недостаточно
Пока вы показываете один ракурс, часть ошибок формы остаётся незамеченной: со стороны камеры силуэт может выглядеть правильно, а с другой стороны геометрия разъезжается. Рекомендация из разбора звучит буквально так: смотреть на модель с четырёх сторон при одинаковом свете, делать бесконечные скрины и постоянно отправлять в чат со всех ракурсов.
Одинаковый свет здесь не деталь. Если менять освещение между кадрами, ассистент получает разный вход, и правки становятся менее предсказуемыми. Серый цвет на пробах головы использовали намеренно: «смотрим на форму без раскраски». Без текстуры проще оценивать объём и пропорции, и модель не тратит внимание на цвет.
Правка формы и привязка одежды: как не сломать анатомию
После каждой правки формы автор сравнивала одинаковые ракурсы и позы. Чувствительные части она сохраняла, остальные упрощала отдельно. Такой порядок помогает не потерять уже достигнутый результат: правки вносятся точечно, а не пересобирают модель целиком.
Требование из постановки задачи — гусь поднимает крыло, рукав двигается вместе с ним; надевает шапку, она остаётся на голове при повороте — выполняется через корректный скелет и веса, а не через пересоздание модели под каждый предмет. Если каждый комплект одежды делают от отдельной базы, персонаж в шапке и в худи получится разной формы. Детали того, как именно устроена привязка одежды в этом проекте, в разборе не раскрыты.
Оптимизация модели для веба: от 18,17 МиБ до 5,95 МиБ
Взрослый гусь занимает 18,17 МиБ на диске и 5,95 МиБ при передаче (Meshopt + gzip). Для страницы сервиса, которая открывается в том числе с телефона, это критичные параметры: количество треугольников прямо влияет на память устройства.
| Параметр | Значение |
|---|---|
| Размер на диске | 18,17 МиБ |
| Размер при передаче (Meshopt + gzip) | 5,95 МиБ |
| Время работы | около 14 часов |
| Подписка Astra | $100 |
В истории проекта размер взрослого гуся менялся: 24,80 МиБ с gzip, после одного этапа — 11,11 МиБ, после следующих правок и упаковки — 5,95 МиБ. На одном из проходов число треугольников сократили примерно с 1,78 млн до 682 тысяч. Точное число треугольников в финальной версии в разборе не приводится.
Сокращение размера шло по трём направлениям: геометрия, упаковка данных и передача файла по сети.
Упрощение геометрии и упаковка: что дало основной выигрыш
Упрощение геометрии означает сокращение числа треугольников без критичной потери силуэта: мелкие детали, которые не видно на экране, убирают первыми. Упаковка обычно означает объединение текстур в атлас, переиспользование материалов и удаление данных, которые не участвуют в рендере. Детали этого этапа в разборе не раскрыты, поэтому конкретные шаги и порядок операций придётся подбирать под свой ассет: сначала считают бюджет треугольников, потом решают, чем можно пожертвовать.
Meshopt + gzip: как работает сжатие при передаче
Meshopt позволяет компактнее хранить данные модели, а gzip уменьшает передачу файла. Разница между 18,17 МиБ на диске и 5,95 МиБ при передаче объясняется именно этим: браузер получает файл, сжатый дополнительно на транспортном уровне, а на диске он лежит в более тяжёлом виде.
Meshoptimizer — библиотека оптимизации мешей: она предоставляет алгоритмы для оптимизации мешей, уменьшения их сложности и накладных расходов на хранение. Распространяется как C/C++ заголовок (src/meshoptimizer.h) и набор C++ исходных файлов (src/*.cpp), включает алгоритм упрощения мешей. Исходники и описание доступны в репозитории meshoptimizer, а обзор релиза библиотеки публиковался на Habr.
Практический вывод: смотреть на размер файла на диске бессмысленно, если вы оцениваете скорость загрузки. Ориентироваться стоит на то, сколько реально уходит по сети.
Работа со сценой в Three.js: что ещё влияет на производительность
Three.js — библиотека для 3D в браузере, которая управляет сценой, камерой, светом и анимацией. Размер файла не равен нагрузке на устройство: на кадр влияют число источников света, тени, постобработка, количество draw call и стоимость скелетной анимации. Конкретные настройки сцены в разборе не приводятся, поэтому здесь стоит опираться на общий принцип: сначала убирают то, что не видно, потом то, что видно редко.
Честные ограничения: чего ещё не сделано
Замеры FPS, нагрева и памяти на реальных смартфонах не проводились. Автор говорит об этом прямо, и это меняет статус результата: перед нами промежуточная версия с понятными характеристиками файла, а не проверенное на устройствах решение.
Разница принципиальная. 5,95 МиБ при передаче описывает только вес ассета. Частота кадров зависит от класса устройства, фоновых процессов, разрешения экрана и настроек сцены. Нагрев и потребление памяти определяются не только геометрией, но и числом скелетных костей, частотой обновления анимации и поведением браузера при длительной работе вкладки. Пока этих замеров нет, утверждать, что гусь будет стабильно работать на любом смартфоне, преждевременно.
Часть деталей процесса, включая точные показатели размера и приёмы правки формы, известна из описания кейса, независимой проверки этих цифр нет. Как ориентир по порядку величин они сохраняют смысл, как гарантия результата на вашем устройстве — нет.
Что делать, если вы идёте тем же путём: прогонять сцену на реальных устройствах, а не только в десктопном браузере, измерять время кадра, а не средний FPS, и проверять поведение при долго открытой вкладке. Именно эти замеры отделяют демо от решения, которое можно показывать пользователям.
Что можно перенять: выводы для своих проектов
- AI-ассистенты ускоряют создание 3D, но не отменяют итераций. Около 14 часов работы и $100 за подписку Astra.
- MCP даёт ассистенту доступ к Blender, и это удобный старт, но первая генерация требует доработки: нагрудник вместо худи, труба вместо шеи, брови из двух брусков.
- Оценивайте модель с четырёх сторон при одинаковом свете и отправляйте ассистенту скрины со всех ракурсов. На пробах формы отключайте цвет, чтобы оценивать геометрию.
- После каждой правки сравнивайте одинаковые ракурсы и позы, чувствительные части сохраняйте, остальные упрощайте отдельно.
- Ориентируйтесь на вес при передаче, а не на размер файла на диске: 18,17 МиБ против 5,95 МиБ с Meshopt и gzip.
- Тестируйте на реальных смартфонах. Замеров FPS, нагрева и памяти в этом кейсе нет, и без них выводы о стабильности остаются предположением.
Тот же принцип работает и в других сценариях: локальная модель, собравшая 3D-игру за три часа, тоже потребовала агентного цикла с самопроверкой, а не одного промпта. Подход из этого кейса стоит адаптировать под свои задачи: пайплайн из двух ассистентов, дисциплина по ракурсам и честные замеры на устройствах дают больше, чем попытка получить готовый ассет одной командой. Полный разбор опыта автора доступен на Habr.