GPT 6.1 Soul, Sonnet 5.5 и Opus 5.5 в создании 3D-сцен: качество, время и расход лимитов

Сравнение GPT 6.1 Soul, Sonnet 5.5 и Opus 5.5 показывает, как разные ИИ-агенты справляются со сборкой окружения, импортом моделей, анимацией и проверкой результата. Это не лабораторный бенчмарк и не универсальный рейтинг моделей, а разбор трёх практических запусков автора с разными типами задач.

Все эксперименты проходили по длинным промптам. В них были описаны проект, последовательность этапов, требуемая логика и итоговый чек-лист. Агент получал не только просьбу «создать сцену», но и критерии, по которым должен был проверить собственную работу.

Методика сравнения 3D-сцен

Содержание сцен различалось, поэтому сводить качество моделей к одному числу нельзя. GPT 6.1 Soul собирал магическую сцену с персонажем, посохом и эффектами. Sonnet 5.5 работал с орком, топором и боевыми анимациями. Opus 5.5 получил более простой набор моделей, зато должен был настроить движение рыб, аэратор, частицы и водные искажения.

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

GPT 6.1 Soul: маг, посох и эффекты заклинаний

GPT 6.1 Soul запускался в режиме XHigh. Агент получил AMD-файл с инструкциями для создания проекта и импортированными моделями. По наблюдению автора, задача заняла 19 минут 36 секунд и израсходовала 30% пятичасового лимита.

В итоговом проекте были фон со звёздами, камень под магом, аудиофайлы и три варианта магии. Маг держал посох и переходил из Т-позы в другое положение, а сцена использовала эффекты молнии и огня. Здесь требовалось согласовать несколько независимых компонентов: скелетную анимацию, положение оружия, свет, звук и визуальные эффекты.

Автор назвал результат лучшим из виденных им ранее вариантов нейросетевой генерации 3D-сцены. Это личная оценка, а не подтверждённый сравнительный показатель. Артефакты в сцене остались, хотя, по мнению автора, часть дефектов можно исправить повторной генерацией отдельных элементов.

На результат влияла и подготовка персонажа. Для мага использовались референс в Т-позе и мультивью со всех сторон. Посох обрабатывался отдельно, чтобы им можно было независимо управлять при подъёме и добавлении эффектов. Сам персонаж получился в low-poly-стиле. Среди недостатков автор отметил слабое освещение, четыре пальца вместо пяти и внешний вид, который сравнил с синим Дедом Морозом.

Sonnet 5.5: орк, топор и проверка боевых анимаций

Sonnet 5.5 работал в режиме XHigh над low-poly-орком в эстетике игр 2000-х. Сначала отдельно создавалась модель топора, затем модели орка и оружия сохранялись в формате GLB и импортировались в проект для сборки окружения и анимаций.

Сцена получила дыхательную анимацию, звуки, траву, камни и low-poly-деревья. По наблюдению автора, орк адекватно держал топор, но оружие оказалось слишком маленьким относительно персонажа. Автоматическая сборка правильно связала объект с рукой, однако не соблюла художественные пропорции.

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

Sonnet работал около полутора часов. Автор остановил задачу после достижения 60% пятичасового лимита, поскольку агент продолжал проверять топоры через Playwright, хотя основная работа, по наблюдению автора, уже была завершена. За запуск израсходовано 8% недельного лимита.

Opus 5.5: аквариум и простая логика движения

Opus 5.5 запускался в режиме medium reasoning для сцены аквариума. Автор выбрал этот режим, поскольку модели не требовалось создавать сложные объекты с нуля. Набор включал замок, гальку, камни, рыб, улиток, краба и растения. Основная задача состояла в настройке движения и визуальных эффектов.

Работа заняла 33 минуты. В конкретном запуске было израсходовано 32% пятичасового лимита и 5% недельного лимита. На эти значения влияют длина промпта, число вызовов инструментов, повторные проверки и настройки среды, поэтому переносить их на любой проект с Opus 5.5 нельзя.

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

Недостатки сохранились. Частицы были заметны сверху, но почти не проявлялись сбоку. Растения слегка двигались, однако стояли корнями на песке, а не были немного погружены в него. Улитка и краб перемещались; автор также предположил, что улитка двигает глазами. Последнее наблюдение остаётся предположением, а не установленным свойством сцены.

Что означают время и расход лимитов

Самый быстрый запуск в этом сравнении принадлежал GPT 6.1 Soul: он завершил работу за 19 минут 36 секунд. Opus 5.5 выполнил задачу за 33 минуты. Sonnet 5.5 работал значительно дольше, но его запуск включал больше итераций проверки и был остановлен пользователем, а не завершился в естественной точке.

Проценты тоже требуют осторожной интерпретации. GPT 6.1 Soul израсходовал 30% пятичасового лимита за короткую сессию, Opus 5.5 потратил 32% за 33 минуты, а Sonnet достиг 60% к моменту остановки. Процент отражает не только длительность, но и интенсивность агентного цикла, объём вывода, работу инструментов, снимки экрана и повторные проверки.

Почему агент продолжает работу после готового результата

Агент ориентируется на заданные критерии и доступные инструменты, а не на человеческое ощущение «уже достаточно». Когда промпт требует проверять объект через Playwright, модель может продолжать цикл, пока не найдёт формальный повод завершить проверку или пока пользователь не остановит процесс.

В случае Sonnet 5.5 автор заметил именно такой сценарий: основная сцена была собрана, но агент продолжал проверять топоры. Причиной могло быть слишком широкое требование к валидации, повторная проверка после каждого изменения или отсутствие жёсткого условия остановки. Установить точную внутреннюю причину по одному запуску нельзя.

Для контроля времени в промпт стоит включить отдельный блок завершения:

• сначала собрать обязательные объекты и логику;
• затем выполнить один проход проверки по чек-листу;
• исправить только ошибки, влияющие на результат;
• не повторять проверку уже подтверждённых элементов;
• завершить работу после формирования итогового отчёта.

Роль подробного промпта и чек-листа

Все три эксперимента использовали длинные промпты с описанием проекта, этапами и требованиями к проверке. Такой формат особенно полезен для 3D-сцен, где итог зависит от порядка действий. Сначала агенту нужно импортировать модели, затем расставить объекты, настроить связи, добавить анимации и только после этого проверять сцену в запущенном окружении.

Короткая просьба вроде «создай аквариум с рыбами» не фиксирует критерии качества. Подробная инструкция может отдельно описать скорость плавания, работу аэратора, видимость пузырьков с разных ракурсов, движение растений и поведение второстепенных объектов. Чем больше требований, тем важнее разделить их на обязательные и желательные, иначе агент потратит лимит на второстепенные детали.

Официальная документация Anthropic описывает уровни effort как способ балансировать глубину работы, время и расход токенов. Она также подчёркивает, что effort не является строгим бюджетом, а жёсткое ограничение задаётся отдельными параметрами среды. В этом сравнении такой подход помогает объяснить, почему режим medium reasoning у Opus оказался достаточным для логики аквариума, а XHigh применялся в более длинных задачах с персонажами и анимацией.

Какую модель выбрать для 3D-задачи

По оценке автора, GPT 6.1 Soul лучше всего проявил себя в задаче, где требовалась цельная демонстрационная сцена с персонажем, оружием, звуком и эффектами. Такой вариант подходит для быстрого прототипа игровой способности или презентационной сцены, если разработчик готов вручную исправить артефакты.

Sonnet 5.5 оказался полезен для насыщенного агентного процесса с импортом нескольких моделей, окружением и проверками через браузерный инструмент. Его запуск показал, что модель может долго работать над одной сценой, но требует контроля границ задачи. Без явного условия завершения лишние проверки способны заметно увеличить расход лимита.

Opus 5.5 в этом эксперименте использовался для сцены, где сложность находилась не в моделировании, а в поведении объектов и эффектах. Аквариум показал, что убедительная сцена складывается из небольших компонентов: медленного движения рыб, пузырьков, водного искажения, микрочастиц и второстепенных анимаций.

• GPT 6.1 Soul целесообразно рассматривать для цельных сцен с персонажем и визуальными эффектами.
• Sonnet 5.5 подходит для длинных агентных задач, где нужно импортировать ассеты, собрать окружение и провести инструментальную проверку.
• Opus 5.5 разумно применять к сложной логике поведения и атмосфере сцены, когда базовые модели уже подготовлены.

Что доработать вручную после генерации

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

Для сцены мага отдельного внимания требуют пальцы, свет и артефакты персонажа. В сцене орка нужно увеличить топор и переработать удар по камню, чтобы рука двигалась по естественной траектории. В аквариуме стоит проверить посадку растений, видимость частиц сбоку и соответствие движения рыб выбранному стилю игры.

Главный вывод сравнения связан не с отдельной моделью, а с сочетанием ассетов, подробного промпта, этапности и ручной приёмки. ИИ-агент уже способен собрать выразительную 3D-сцену и связать её с анимацией, но качество финального результата по-прежнему определяется точностью описания задачи и внимательностью проверки после завершения работы.