Бессерверная инфраструктура для искусственного интеллекта — не самая простая вещь для общения.
Вместо того, чтобы пытаться объяснить это с помощью диаграмм или длинных блоков текста, мы хотели, чтобы люди чувствовать как это работает. Каждое взаимодействие было спроектировано так, чтобы отражать сам продукт: быстрое, точное, модульное и масштабируемое. Это был один из тех проектов, где дизайн не просто поддерживал историю — он был история.
Технический стек
- Cinema 4D/Redshift/Блендер — Создание 3D-активов и конвейер анимации.
- Три.js r183.2 — WebGL-рендеринг
- ГСАП — Анимации и переходы
- Макио МешЛайн — Рендеринг анимированных 3D-путей.
Можем ли мы построить это с помощью WebGPU?
Матис Биабиани
Когда я начал проект, я построил весь слой рендеринга, используя новую версию Three.js. WebGPURenderer вместе с TSL (язык шейдеров Three.js). На тот момент Three.js r183.2 был последней доступной версией.
Честно говоря, с TSL было очень приятно работать. Вместо поддержки нескольких файлов GLSL, материалов, вычислений на графическом процессоре и эффектов постобработки все можно описать как составные графы узлов JavaScript. Затем Three.js сгенерирует соответствующие шейдеры в зависимости от механизма рендеринга.
Помимо более чистой архитектуры, это также была моя первая возможность реализовать настоящий клиентский проект с использованием WebGPU вместо WebGL, поэтому я хотел продвинуться как можно дальше.
К сожалению, по мере роста проекта реальность догнала его. Церебриум — это не отдельная изолированная 3D-сцена. Один холст содержит несколько сред, каждая со своими материалами, частицами, настройками освещения и конвейером постобработки. Мы также хотели, чтобы переходы между страницами были плавными, без отображения экрана загрузки каждый раз, когда пользователи перемещаются по ним.
Проблема заключалась не в производительности рендеринга, когда все работало. Узкое место возникло еще до начала опыта. Во время начальной загрузки Three.js пришлось пройти через каждый граф узлов TSL, сгенерировать соответствующие шейдеры и скомпилировать конвейеры графического процессора. На нашей эталонной машине эта фаза инициализации может занять около двадцати секунд.
Более поздние версии Three.js значительно улучшили этот процесс. Тесты, опубликованные в рамках проекта, показывают, что компиляция шейдеров становится примерно в три раза быстрее благодаря лучшему кэшированию узлового типа, во многом благодаря работе Рено Ролингер.
К сожалению, на момент выпуска этих улучшений просто не было. Мы не могли оправдать ожидание почти двадцати секунд перед рендерингом первого кадра. Поэтому я принял решение перенести весь слой рендеринга обратно в WebGLRenderer.
Перестройка всего в WebGL
Общая логика рендеринга осталась на удивление схожей. Что изменилось, так это то, насколько все стало явным.
Узловые материалы TSL были заменены традиционными материалами Three.js, расширенными за счет onBeforeCompile() для внедрения собственного кода GLSL. Вычислительные шейдеры, ответственные за симуляцию частиц, превратились в систему GPGPU для пинг-понга, построенную на текстурах с плавающей запятой. Граф постобработки на основе узлов был перестроен с использованием EffectComposer наряду с несколькими пользовательскими проходами GLSL.
Эта миграция научила меня одной вещи: два шейдера, реализующие одну и ту же идею, редко создают идентичные изображения.
- Различные функции шума.
- Разное отображение тонов.
- Различные уравнения смешивания.
- Различные модели освещения.
- Различная УФ-интерполяция.
- Различные конвейеры постобработки.
Все эти, казалось бы, небольшие различия сложились в заметно отличающийся визуальный результат. Интенсивность свечения, плотность тумана, градиенты и некоторые цвета материалов пришлось тщательно откалибровать, чтобы восстановить исходное художественное направление.
Возвращение к WebGL не было отказом от WebGPU. Это было просто производственное решение, основанное на зрелости доступного на тот момент инструмента. WebGPU и TSL предоставили мне гораздо более модульный способ создания визуальных эффектов. WebGL предоставил нам время запуска, которое было достаточно предсказуемым для выпуска.
Конвейер 3D и WebGL
Воссоздание освещения
Селия Лопес
Поскольку многие сцены содержали анимированные объекты, запекание освещения было невозможным. Каждый источник света пришлось воссоздавать непосредственно внутри Three.js. Чтобы помочь Матису точно все расположить, я экспортировал простые вспомогательные кубы из Cinema 4D. Эти кубы сохранили как положение, так и ориентацию каждого источника света, что значительно упростило воссоздание системы освещения внутри движка.
Иногда простейшие инструменты отладки экономят больше всего времени.
Анимация сети
Матис Биабиани
Один из моих любимых эффектов в проекте — анимированная сеть светящихся дорожек. Интересно, что на самом деле ничего не движется. Сами пути представляют собой полностью статичные сетки — иллюзия движения полностью создается шейдером. Каждый путь разворачивается с помощью UV-развертки, поэтому ось Y непрерывно проходит от одного конца линии к другому.
Шейдер просто перемещает узкую маску непрозрачности вдоль этой UV-оси, создавая видимость импульса, путешествующего по сети. Его ширина и спад определяют, будет ли импульс ощущаться как резкий сигнал или как более мягкий энергетический след.
Чтобы все анимации не были идеально синхронизированы, каждый путь получает немного разные параметры:
- Смещение анимации
- Скорость
- Интервал между импульсами
Эта небольшая доля случайности делает всю систему более органичной.
Мы также ограничили видимость каждого пути в зависимости от его расстояния от камеры, постепенно раскрывая сеть по мере перемещения камеры по сцене. Во время разработки инспектор выставлял почти каждый параметр:
- Светлый цвет
- Порог цветения
- Радиус цветения
- Интенсивность цветения
- Непрозрачность частиц
- Показать расстояние
- Скорость пульса
- Длина импульса
- Мягкость пульса
- Частота импульса
Задача заключалась в том, чтобы найти золотую середину, где линии выглядели бы достаточно яркими, чтобы излучать свет, не позволяя цветению полностью размыть детали.
Общая среда
Селия Лопес
Чтобы усилить фирменную фиолетовую атмосферу проекта, в качестве карты окружения мы использовали специальный фиолетовый HDRI от Poly Haven. Помимо добавления тонких отражений, это помогло унифицировать общую цветовую палитру в каждой сцене. Иногда постоянство освещения — это то, что заставляет совершенно разные помещения чувствовать себя принадлежащими одному и тому же продукту.
Оптимизация производительности
На первый взгляд сцены выглядели довольно легковесными. На самом деле это не так. Поддержание идеально плавных кривых по всей сети требовало тщательного разделения геометрии, особенно вокруг закругленных сегментов пути.
Всякий раз, когда я предоставляю разработчикам 3D-модель, я всегда провожу оптимизацию с помощью Draco. В зависимости от проекта я использую либо 3D-оптимизатор Дэвида Ронаи, либо инструмент оптимизации Babylon.js Sandbox.
Плохая топология
Проблема заключалась в том, что каждый раз, когда я экспортировал всю сцену, геометрия автоматически упрощалась за счет уменьшения количества полигонов. Хотя это сделало файл легче, но также привело к появлению видимых граней вдоль изогнутых контуров, что подорвало безупречную эстетику веб-сайта.
Вместо того, чтобы снижать качество геометрии, я понял, что могу разделить модель на две отдельные части и оптимизировать каждую сетку независимо, не ставя под угрозу плавность кривых.
Первая модель содержала вспомогательные объекты, световые пути и часть сети. Второй содержал оставшуюся геометрию пути. Разделение было тщательно размещено там, где оно было бы визуально незаметно, что позволило нам более эффективно передавать ресурсы и управлять ими, сохраняя при этом качество геометрии.
Запекание анимации камеры
Каждое движение камеры было запечено непосредственно из Cinema 4D. Это дало нам полный контроль над таймингом, кадрированием, замедлением и синхронизацией с остальными элементами, избегая при этом различий в интерполяции между приложениями.
Проектирование безопасности как взаимодействия
Матис Биабиани
Один раздел сайта посвящен безопасности. Вместо того, чтобы обозначать его значком замка, мы хотели, чтобы пользователи чувствовать что инфраструктура была защищена. Центральный объект окружен почти невидимым сферическим щитом. Большая часть его внешнего вида обусловлена классическим эффектом Френеля: поверхности, обращенные к камере, остаются тонкими, а те, что под углом, становятся намного ярче.
vec3 viewDir = normalize(cameraPosition - vWorldPos);
float NdotV = clamp(dot(vWorldNormal, viewDir), 0.0, 1.0);
float fresnel = pow(1.0 - NdotV, uFresnelPower);
fresnel *= uFresnelStrength;
float noise = valueNoise3D(
vPosition * uFresnelNoiseScale +
uTime * uFresnelNoiseSpeed
);
fresnel *= 1.0 + (noise * 2.0 - 1.0) * uFresnelNoiseAmount;Слой анимированного процедурного шума тонко модулирует интенсивность Френеля, не позволяя щиту казаться совершенно статичным. Кроме того, на сферу проецируется гексагональная сетка, которая аддитивно смешивается с эффектом Френеля. В сочетании с цветением создается впечатление, что щит генерирует собственную энергию.
Но на этом взаимодействие не заканчивается. Рейкастер постоянно отслеживает положение мыши на сфере и записывает его во временную текстуру. Затем шейдер использует эту текстуру в качестве динамической маски, локально освещая близлежащие шестиугольники, а затем постепенно затемняет их с течением времени.
Вместо того, чтобы мгновенно реагировать и немедленно исчезать, щит на короткое время запоминает каждое взаимодействие. Эта тонкая настойчивость помогает продать иллюзию о том, что силовое поле поглощает, рассеивает и рассеивает энергию по своей поверхности.
Кредиты
Агентство – КОКИ-КИКО
Стратегия и ПО – Ким Леван
Креативное руководство и дизайн – Луи Паке
3D – Селия Лопес
Разработка — Девен Кэрон, Пьер-Люк Коссетт
ВебГЛ – Матис Биабьяни