Предложение по улучшению ми придумал для вас идею

[azat_kabywev]

Уважаемая команда OpenAI,

В процессе активной работы с ChatGPT над визуальными проектами (в частности, 3D-планировкой Центра приёма граждан), я столкнулся с очевидным ограничением: невозможностью контролировать в реальном времени действия по размещению предметов на 3D-сцене.

С учётом потребностей архитекторов, дизайнеров, госучреждений и бизнеса, предлагаю рассмотреть инновационный функционал, который сочетает возможности ChatGPT и интерактивной визуальной среды.

⸻

Суть предложения:

Создать режим “живого взаимодействия” с ИИ в формате визуального 3D-редактора с голосовым и текстовым управлением.

⸻

Что это может включать:
• Встроенное окно визуального моделирования (3D-сцена);
• Возможность пользователю говорить голосом или писать:
«передвинь этот стол левее»,
«разверни кресло на 90°»,
«поставь 4 стула у окна»;
• Сохранение объектов, сетки координат, настроек освещения, материалов;
• Привязка к базовой библиотеке мебели и шаблонов;
• Экспорт визуализаций и планов в PDF/PNG.

⸻

Кому это будет полезно:
• Муниципальным структурам (проектировка ЦОН, ЦПГ, школ, больниц);
• Архитекторам и дизайнерам интерьера;
• Бизнесу (офисные планировки, выставки, стенды, кафе);
• Частным клиентам (дизайн квартир, домов);
• Учебным учреждениям.

⸻

Я, как активный пользователь GPT и специалист в госструктурах и бизнесе, уверен — такой инструмент станет настоящим прорывом.
Буду рад сотрудничать в пилотном проекте, тестировании и доработке интерфейса.

С уважением,
Азат,

[lucid.dev]

This sounds like a great project. I have an in-house system that could likely help rapidly produce the code for this.

However, what 3D software are you using? What kind of API interface do you have setup for your calls to OAS? Are you using the chat completions endpoint or the responses endpoint?

Overall the project would consist of:

1. 3D modeling software API that exposes interface at a textual/code level available for middleware calling
2. Middleware module that receives input such as user voice (TTS), and then calls the OAS model, critically the middleware module must be wired up to #1 so as to provide the “current state of 3D model context/objects/etc.” to the LLM in such a way as the LLM can understand it (so instructions must be provided as well both in terms of comprehension and LLM response formatting)
3. LLM returns response, and middleware module processes response and calls API exposed as in #1.
4. 3D modeling software must accept CLI or direct API calls/endpoints so as to be able to process the calls for modifications.

Thus, you must have 3D modeling software that exposes direct programmtic access.

It is my opinion that using any kind of screen-reader or “operator” (i.e. visual processing of on-screen information) would be extremely slow or cumerbsome and error prone in this use case, it will be much more efficient both in terms of token cost and time-to-act if as much as possible is handled directly through middleware running on the system and not relying on OAS or LLM activities except for actually providing the interpretation → action.