Показываем объект до того, как он построен

3D-визуализация — это картинка, нарисованная художником по проекту. Она показывает замысел, но не даёт почувствовать геометрию: высоту потолков, ширину коридора, вид из окна на соседний корпус. Панорама 360° снимается на реальном объекте и передаёт то, что покупатель увидит при осмотре, включая неидеальные ракурсы.

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

Шахматка — это не картинка, а выгрузка состояния лотов: корпус, секция, этаж, номер, комнатность, площадь, статус (свободно, бронь, продано) и цена. Мы забираем её из учётной системы застройщика — 1С, собственная CRM или система продаж — и обновляем не реже раза в час, а при наличии API — по событию.

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

Основная причина медленного тура — попытка отдать панораму целиком. Мы используем пирамиду тайлов: браузер сначала получает маленькое изображение на 512 пикселей в ширину, показывает его сразу, а детали догружает по мере вращения. Пользователь видит интерфейс за 1–2 секунды, а не за полминуты.

Дополнительно мы сжимаем панорамы в WebP или AVIF, отдаём их через CDN, ограничиваем разрешение по типу устройства и предзагружаем только соседние точки перехода. На мобильном интернете одна сцена обычно занимает 300–700 КБ вместо 20–40 МБ. Это же решение снимает нагрузку с сервера: статика не проходит через приложение, а раздаётся с CDN.