СРАВНИТЕЛЬНЫЙ АНАЛИЗ МЕТОДОВ СЖАТИЯ ПРЕДСТАВЛЕНИЙ 3D GAUSSIAN SPLATTING ДЛЯ ИНТЕРАКТИВНОЙ ВИЗУАЛИЗАЦИИ

1. Введение

3D Gaussian Splatting (3DGS) описывает сцену набором трёхмерных гауссовых примитивов и формирует изображение их проекцией и дифференцируемой растеризацией [6]. В отличие от нейронных полей излучения, явное представление обеспечивает интерактивный синтез новых ракурсов при высокой детализации.

Такая явность одновременно создаёт ресурсное ограничение: сцена содержит миллионы примитивов с координатами, формой, ориентацией, прозрачностью и цветом. В исходной конфигурации 48 из 59 параметров приходятся на коэффициенты сферических гармоник [7, 9], поэтому модели занимают сотни мегабайт, а крупные сцены — несколько гигабайт [4, 10]. Это осложняет передачу по сети и повышает требования к оперативной и видеопамяти.

Поскольку публикации используют разные реализации, сцены, GPU и контейнеры, их размеры и FPS нельзя напрямую ранжировать [1, 9]. Цель работы — сопоставить репрезентативные методы сжатия 3DGS и оценить их применимость для интерактивной визуализации. Использованы анализ первичных публикаций, классификация и обобщение экспериментальных результатов.

2. Основы 3D Gaussian Splatting и причины ресурсоёмкости

Сцена 3DGS представляется множеством анизотропных гауссиан. Для i-го примитива задаются центр μᵢ, ковариация Σᵢ = RᵢSᵢSᵢᵀRᵢᵀ, непрозрачность αᵢ и коэффициенты сферических гармоник, определяющие зависящий от направления цвет cᵢ [6, 10]. При рендеринге примитивы проецируются, сортируются по глубине и смешиваются.

Gᵢ(x) = exp[-1/2 (x - μᵢ)ᵀΣᵢ⁻¹(x - μᵢ)],    C(x) = Σᵢcᵢα̃ᵢ(x)Πⱼ<ᵢ(1 - α̃ⱼ(x)),

Здесь α̃ᵢ(x) объединяет непрозрачность и значение проекции гауссианы в пикселе. Ошибка координат, масштаба или прозрачности влияет не только на локальный вклад, но и на видимость последующих примитивов, поэтому геометрические параметры чувствительны к грубому квантованию [6, 9, 10].

Ресурсная стоимость определяется числом гауссиан, крупным блоком сферических гармоник и операциями проекции, сортировки и смешивания на каждом кадре. Прореживание уменьшает и файл, и нагрузку на растеризатор; квантование прежде всего сокращает хранение и трафик памяти. Методы оценивают по размеру, PSNR, SSIM, LPIPS и FPS, а для интерактивных систем также важны декодирование, пиковая память и время первого кадра.

3. Классификация методов сжатия

В 3DGS.zip различаются компактизация, сокращающая число примитивов, и сжатие, уменьшающее число битов представления [1]. Практические методы сочетают: 1) прореживание и маскирование; 2) скалярное или векторное квантование; 3) сокращение сферических гармоник либо компактное нейронное представление цвета; 4) пространственное и энтропийное кодирование. Наибольшие коэффициенты дают гибридные схемы.

Сравниваются LightGaussian [5], Compact-3DGS [7], C3DGS [10], CompGS [9] и HAC++ как развитие HAC на основе Scaffold-GS [3, 4, 8]. Все работы содержат результаты на Mip-NeRF 360 и описывают декодирование, охватывая основные классы сжатия. LapisGS [11] отдельно рассматривается как прогрессивное представление для сети.

4. Анализ выбранных методов

4.1. LightGaussian

LightGaussian постобрабатывает обученную сцену: удаляет примитивы по глобальной значимости, снижает порядок сферических гармоник и применяет VQ к 60 % наименее значимых SH-векторов; остальные атрибуты хранятся в FP16 [5]. После 5000 шагов адаптации на Mip-NeRF 360 размер уменьшается с 782 до 45 МБ, FPS растёт со 144 до 237, а PSNR меняется с 27,40 до 27,13 дБ. Путь рендеринга остаётся близким к исходному, но требуется многостадийное дообучение.

4.2. Compact-3DGS

Compact-3DGS встраивает сжатие в обучение: маска удаляет избыточные гауссианы, масштаб и вращение кодируются остаточным VQ, а видозависимый цвет вычисляется MLP по многомасштабной хеш-решётке [7]. Постобработка включает 8-битное квантование, Morton-сортировку и энтропийное кодирование. На Mip-NeRF 360 итоговый размер равен 29,1 МБ против 746 МБ; версия без постобработки занимает 48,8 МБ и даёт 128 FPS против 120 FPS, поэтому максимальную компактность нельзя напрямую связывать с измеренным ускорением.

4.3. C3DGS

C3DGS сочетает прореживание, sensitivity-aware VQ формы и направленного цвета, quantization-aware fine-tuning и хранение координат в FP16 [10]. Гауссианы сортируются по Z-кривой, а индексы и атрибуты сжимаются DEFLATE; предусмотрен растеризатор на Rust и WebGPU. На Mip-NeRF 360 размер снижается с 795,26 до 28,80 МБ, PSNR — с 27,21 до 26,981 дБ. Ускорение до 4 раз относится к сравнению разных конвейеров, а не только к квантованию.

4.4. CompGS

CompGS применяет K-means VQ цвета, масштаба и вращения, оставляя координаты и непрозрачность индивидуальными. L1-регуляризация создаёт невидимые примитивы, которые удаляются, а индексы сортируются и сжимаются аналогом RLE [9]. Вариант 16K на Mip-NeRF 360 сокращает размер с 778 до 18 МБ, повышает FPS со 149 до 346 и изменяет PSNR с 27,42 до 27,03 дБ; число гауссиан снижается с 3,30 млн до 845 тыс. Версия 32K обучается примерно в 1,4–1,7 раза дольше базы.

4.5. HAC и HAC++

HAC использует якорную структуру Scaffold-GS, хеш-решётку пространственного контекста, адаптивное квантование, маски и арифметическое кодирование [3, 8]. После декодирования решётка удаляется. HAC++ добавляет внутрякорный контекст, смесь гауссовых распределений для оценки вероятностей и GPCC-кодирование координат [4].

На Mip-NeRF 360 HAC++ low rate занимает 8,34 МБ против 750,9 МБ и показывает 151 против 99 FPS; PSNR меняется с 27,46 до 27,60 дБ, LPIPS — с 0,222 до 0,253. High rate занимает 18,48 МБ и лучше сохраняет SSIM и LPIPS. Декодирование длится 15,77–30,86 с, поэтому минимальный трафик сопровождается заметной задержкой первого показа.

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

5. Сопоставление опубликованных результатов

Для численного среза выбран Mip-NeRF 360 [2], использованный во всех пяти работах. Прямой рейтинг некорректен из-за различий в базовых моделях, коде, GPU и рендерерах, поэтому размер и FPS сопоставляются только с базой внутри каждой публикации.

LightGaussian и C3DGS преобразуют готовую сцену с дообучением, тогда как Compact-3DGS, CompGS и HAC++ теснее встроены в обучение. Кодовые книги упрощают распаковку; контекстное арифметическое декодирование обычно эффективнее по размеру, но усложняет запуск.

Даже на одном наборе данных базовый размер меняется от 750,9 до 795,26 МБ, а PSNR — от 27,21 до 27,46 дБ. Поэтому коэффициенты в таблице рассчитаны относительно базы той же работы, а FPS не используется для межстатейного рейтинга.

Таблица 1.

Данные авторов методов на Mip-NeRF 360

Метод	Размер, МБ; сжатие (база → метод)	PSNR, дБ	SSIM	LPIPS	FPS (база → метод)
LightGaussian [5]	782 → 45; 17,4×; среднее 15×	27,40 → 27,13	0,813 → 0,806	0,217 → 0,237	144 → 237
Compact 3DGS + PP [7]	746 → 29,1; 25,6×	27,46 → 27,03	0,812 → 0,797	0,222 → 0,247	120 → не указано¹
C3DGS [10]	795,26 → 28,80; 26,23ײ	27,21 → 26,981	0,815 → 0,801	0,214 → 0,238	не сводится³
CompGS 16K [9]	778 → 18; 43,2×	27,42 → 27,03	0,813 → 0,804	0,217 → 0,243	149 → 346
HAC++ low rate [4]	750,9 → 8,34; 90,0×; среднее >100×	27,46 → 27,60	0,812 → 0,803	0,222 → 0,253	99 → 151
HAC++ high rate [4]	750,9 → 18,48; 40,6×	27,46 → 27,82	0,812 → 0,811	0,222 → 0,231	99 → 130

¹ Без постобработки: 48,8 МБ и 128 FPS. ² Для C3DGS приведён авторский средний коэффициент по сценам. ³ Ускорение до 4× относится к иному конвейеру. Данные из [3–5, 7, 9, 10].

По размеру лидирует HAC++ low rate, но его LPIPS хуже исходного и запуск требует контекстного декодирования. CompGS 16K сочетает 43-кратное уменьшение с более чем двукратным ростом FPS. LightGaussian удобен для готовой сцены, Compact-3DGS комплексно перестраивает атрибуты, а C3DGS выделяется браузерным форматом.

Высокие коэффициенты достигаются совместным удалением примитивов, кодированием повторяющихся атрибутов и использованием статистической зависимости индексов. Рост PSNR у HAC++ связан с иной структурой и обучением, а не с потерей данных как таковой.

6. Применимость для интерактивной визуализации

Для локального приложения рациональны CompGS и LightGaussian: первый даёт меньший файл, второй удобен как оптимизация готовой сцены. Для браузера лучше всего документирован C3DGS с WebGPU-рендерером [10]. HAC++ сильнее сокращает трафик, но десятки секунд декодирования могут перекрыть выигрыш при коротком сеансе.

В XR критичны частота обновления, видеопамять и предсказуемая задержка: C3DGS привлекателен аппаратной растеризацией, а HAC++ — для заранее загруженного контента. При переменной пропускной способности LapisGS передаёт сцену базовым и улучшающими слоями, позволяя начать рендеринг до полной загрузки [11]. Поскольку реальные флуктуации сети не оценивались, это прогрессивная архитектура, а не готовая система адаптивного стриминга.

7. Ограничения сравнительного анализа

Работа не воспроизводит обучение и рендеринг и потому сохраняет различия экспериментальных протоколов. FPS зависит от GPU, разрешения и растеризатора, а PSNR, SSIM и LPIPS не отражают время первого кадра, пиковую память, мерцание и субъективное качество в шлеме. Рекомендации раздела 6 выведены из архитектуры методов и не подтверждены испытаниями на целевых веб-, мобильных и XR-устройствах.

Заключение

Сжатие 3DGS требует сочетания механизмов: прореживание снижает число примитивов и нагрузку на растеризатор, VQ устраняет повторяемость формы и цвета, сокращение сферических гармоник уменьшает крупнейший блок атрибутов, а контекстное и энтропийное кодирование снижают стоимость индексов. HAC++ даёт минимальный размер, CompGS сочетает сильное сжатие с ростом FPS, LightGaussian оптимизирует готовую сцену, Compact-3DGS меняет представление атрибутов, а C3DGS лучше всего документирует браузерную эксплуатацию.

Максимальный коэффициент сжатия не универсален: локальному приложению важны FPS и простота декодирования, вебу — размер и время первого кадра, XR — стабильная задержка, сети — прогрессивность. Для корректного сравнения нужен единый протокол, включающий полный размер потока, декодирование, пиковую память, энергорасход и качество при движении камеры на мобильных и XR-платформах.