Ivan Bogachev

Весь затык у нас тут в том, что CSS не позволяет в рамках path жонглировать единицами измерения. Почему? Люди задавались этим вопросом с самого момента появления path в CSS. Но этот функционал всегда был в SVG. Так что можно добавить маску в SVG (тут у нас размер элемента, условные 100% на 100%, считается за 1 на 1):

<svg width='0' height='0'>
    <defs>
        <clipPath id='example' clipPathUnits='objectBoundingBox'>
            <path d="M 0 0 a 1 1 0 0 0 1 1 h -1 v -1z"/>
        </clipPath>
    </defs>
</svg>

И тогда в CSS уже будет все просто:

.example {
    clip-path: url(#example);
}

Это не идеальный вариант, хотелось бы на чистом CSS, но имеем, что имеем.

Где-то в светлом будущем у нас будет CSS Painting API, с помощью которого можно будет рисовать какие угодно бордеры. А пока можно его сымитировать обычным канвасом (правда придется отступы подгонять под особенности шрифта, но это уже детали, один раз можно сделать):



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

порядок действий

1. Сделать 12 элементов.
   
2. Расположить элементы по кругу. Тут абсолютное позиционирование В текущих реалиях вечнозеленых браузеров мы можем использовать нативные функции sin() и cos(), чтобы рассчитать, где какие из них должны быть расположены на окружности не покидая мир CSS. Тут никакой магии, геометрия за 7 класс школы.
   
3. Естественным образом в расчетах координат появится угол, который можно менять, тем самым поворачивая всю эту карусель. Его можно уже из скриптов менять по той логике, которая нужна для взаимодействия с пользователем.
   
4. Обрезать все штатным clip-path.
   

Это если говорить про HTML+CSS подход. Он легко делается, но он не идеальный внутри. Есть две проблемы, которые не решатся заменой свойств на другие. Первая - это дергающиеся элементы. В каких-то браузерах это будет проявляться меньше, в каких-то больше. Как ни крути положения элементов округляются до целого количества пикселей по неведомой для нас логике и в движении будут заметны сдвиги в 1px туда-сюда. И производительность - это вторая потенциальная проблема. Двигать много элементов одновременно, особенно если они большие - не всегда хорошо. Не факт, что это будет проблемой в вашем случае, но в теории может стать с учетом всего остального, что будет на странице. Более производительным в теории вариантом будет нарисовать все это на канвасе. Там же можно будет взять под контроль все округления. По крайней мере до какой-то степени. Это следующий шаг, куда можно все это развивать. Логика будет той же самой, но уже на других технологиях. Вероятно вам будет проще начать с варианта на CSS.

Я думал через clip-path но там нет такой плавности... даже чат джипити не понимает...

Если уж говорить про clip-path, то там есть clip-source, с помощью которого мы можем поиспользовать clipPath из мира SVG, а в рамках SVG уже можно нарисовать себе любую форму. В разделе синтаксиса и на MDN, и в стандарте, это буквально первый предлагаемый вариант использования clip-path. Не доверяйте вашей чатгопоте. Читайте документацию самостоятельно. Там много интересного.

Для начала можно посмотреть в их исходники. Беглый просмотр кода показывает основной план действий:

• Создать плоскость с кастомным материалом. Вершинный шейдер стандартный нейтральный, который ничего необычного не делает, только сохраняет координаты UV, чтобы их во фрагментном использовать. Фрагментный будет содержать в себе всю логику. Это частенько так делается в 2D-эффектах.
  
• Во фрагментный шейдер передать две текстуры. Одна обычная, для фона. Вторая - карта смещений для пикселей. Displacement map по-нашему. Берем пиксели из фона, смещаем по данным из карты смещений - получаем результат.
  
• Нарисовать текстуру для фона. В их случае она делается из кадров видео, т.е. вот этот бултыхающийся градиент на фоне в их случае заранее заготовлен. И, к слову, видно, что он шакалится. Но с точки зрения производительности видео тут - это хорошая идея. Генерирование клякс-градиентов - требовательная в вычислительном плане задача.
  
• Нарисовать displacement map по какой-то логике, завязанной на положение мыши. Тут большой простор для экспериментов. В их случае они используют отдельную сцену с кучей объектов, у которых меняются расположение и прозрачность в зависимости от положения мыши и просто со временем. Там много магических чисел. Вероятно все подбиралось наугад. Как это обычно и происходит. И потом они рендерят эту сцену в текстуру, которая передается в уже упомянутый шейдер. Можно было бы на 2D канвасе ее рисовать. Но с трехмерной сценой в таких задачах проще работать, хотя это поначалу кажется контринтуитивным.
  

Все остальное в коде - обвязка, чтобы это организовать в рамках Three.js. В этом конкретном сценарии этот инструмент выглядит слегка избыточными. Можно было бы взять какую-нибудь альтернативную легковесную библиотеку, но по сути делать пришлось бы то же самое.

От этого вполне можно оттолкнуться и сделать что-то подобное в рамках своих инструментов/требований/дизайнов.

Формально можно взять фильтр blur с большим радиусом и размыть абсолютно расположенные на фоне элементы. В SVG есть аналогичный фильтр. Но лучше так не делать. Для таких размытий используется вычислительно сложный алгоритм и можно существенно увеличить нагрузку на устройства пользователей на ровном месте. Это просто сложно рендерить в реальном времени.

Производительнее будет это размытое нечто картинкой вставить. Тоже не идеально, грузиться будет дольше, но выбирая между тормозами всего или слегка более долгой загрузкой ни на что не влияющей кляксы на фоне - в 99% случаев стоит выбрать второе.

Есть, конечно, еще более развитый вариант - взять canvas, отрендерить эту штуку на нем один раз в фоновом режиме, а потом использовать результат как картинку. Так оно не будет требовать загрузки картинки по сети, и мы не будем грузить устройства пользователей постоянно. Но это уже другой вопрос, про другие инструменты.

P.S.: Добавлю еще такой момент, что при использовании картинки может возникнуть такая мысль, что в CSS есть еще градиенты - и это ведь тоже как картинки, может быть их использовать? Но собрать такое из градиентов гораздо сложнее, чем кажется. Сложение полупрозрачных градиентов - это не тот же алгоритм, что размытие. При взаимном наложении клякс друг на друга результат будет отличаться. Чтобы иметь такое же красивое размытие - придется иметь много градиентов, что сведет на нет саму идею снижения нагрузки на железо через них.

Я максимально далек от программирования контроллеров, но поделюсь идеей, что у нас в javascript можно делать вот так (вероятно и в других языках, более близких к вашим задачам, есть похожая возможность):

const frames = [
    [
        0b0000001100000000,
        0b0000001100100000,
        0b0001111111100000,
        0b0001001100000000,
        0b0000010010000000,
        0b0000100001000000,
    ],
    [
        0b0000001100000000,
        0b0001001100000000,
        0b0001111111100000,
        0b0000001100100000,
        0b0000010010000000,
        0b0000100001000000,
    ],
];

console.log(frames);
// -->
// [
//     [ 768, 800, 8160, 4864, 1152, 2112 ],
//     [ 768, 4864, 8160, 800, 1152, 2112 ]
// ]

Мне кажется, что имея моноширинный шрифт натыкать единичек в виде каких-нибудь картинок вполне можно. Запустить этот скрипт можно в любом интерпретаторе js. Если нужно действительно что-то простое, на один раз, то как вариант. А можно и детям показать, как числа выглядят по-разному.

Точно такая же сцена требуется в другом месте, и не хотелось бы дублировать код и создавать ту же сцену для другого канвас

Сцену дублировать не обязательно. WebGLRenderer не умеет рендерить в несколько мест одновременно, но можно иметь одну сцену и много рендереров, каждый из которых будет рендерить ее в свой канвас. Это работает.

Если посмотреть с другой стороны, то возможно, что вам не нужны два канваса. Это может звучать странно, но тем не менее. Пользователь же все равно видит только один экран информации. Можно иметь один канвас на весь экран, и в нем рендерить сцены в какие-то его участки. Там есть такой функционал у рендерера, называется "ножницы" (scissor). Его можно использовать как раз для таких задач. Есть хороший пример в документации.

Но если делать именно 100% дублирование, то оба этих варианта будут не самыми толковыми с точки зрения производительности. В лоб скопировать уже готовое содержимое канваса в другой через drawImage должно быть проще, чем рендерить всю сцену еще раз. Поэтому решение, которое пришло вам в голову - очень даже ничего в текущем контексте. Хотя и выглядит топорно.