Ivan Bogachev

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

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

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

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

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

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

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

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

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


Тут немного отличается характер движений от примера на том сайте, но расположение надписей равномерно на сфере и суть поворотов плюс-минус такие же. И большой вопрос, что будет более производительным. Скорее всего на большом количестве надписей WebGL все же выйдет вперед, но пока их мало - сложно сказать, что лучше.

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

scene.add(gltf.scene);

Этого должно быть достаточно. Так что то, что там дальше:

const model = new THREE.Mesh( loader, material );
scene.add(model);

Уже не нужно. Не говоря уже о том, что этот код - полная бессмыслица. Mesh создается из геометрии и материала, а вы туда вместо геометрии что-то другое передаете. Отсюда должна быть ошибка.

Стандартной функции rand в glsl в нашем распоряжении нет. Есть популярная реализация:

float rand(vec2 seed) {
    return fract(sin(dot(seed, vec2(12.9898,78.233))) * 43758.5453123);
}

Ее копипастят годами из проекта в проект, и используют, когда нужно что-то нарандомить.

Но глобальные константы должны быть именно константами, известными на этапе компиляции. На попытку присвоить им значение, вычисленное в какой-то функции - получим ошибки компиляции. Исключения по этой части в glsl делаются только для специальных переменных, в частности для uniform. Они могут быть определены уже в реальном времени. Можно было бы нарандомить все в main, и потом передавать все значения в остальные функции в качестве параметров, но может быть быстрее и удобнее добавить больше uniform-переменных, вроде:

var tuniform = {
	SEA_SPEED: {
		type: 'f',
		value: Math.random() * 10.0
	},
	time: {
// ...

в JS, и в шейдере:

// Вместо
// const float SEA_SPEED = 0.8;
// используем
uniform float SEA_SPEED;

В сети есть множество примеров. Есть официальный пример из документации самой Three.js. Или вот, например, другой вариант, с дополнением в виде статьи.