домашка %)
1) Поменять грид на 40х40 и размер на 2х2 - затем нужно поменять выделение в group1 (bounding box сделать размером 1.95 по каждому измерению), и в shuffle обоих изменить 20 на 40 в пункте кусками по сколько сэмплов резать. И вроде и все.
2) что делает каждая нода
grid1
Задает исходную сетку.
group1
Выбирает крайний ряд точек сетки со всех сторон (с помощью bounding box выбираются все точки кроме внешних рядов; во вкладке Combine это выделение инвертируется с помощью "НЕ group1", и новому выделению присвоено имя gr2)
transform2
"Отодвигает" по оси z все внутренние точки сетки (выделение group1)
noise1
Заставляет сетку шевелиться, причем нойз двигается по оси x (не вижу объективной причины этому, думаю, просто вопрос вкусовых предпочтений, с передвижением по оси z тоже все работает, но выглядит чуть иначе)
add1
Просто считает нормали. Предполагаю, что тут мог бы быть с тем же успехом AttributeCreate.
point1
Работает только с внешними точками сетки, gr2. Навязывает этим точкам свои нормали - они всегда направлены по диагонали внутрь поверхности нойза.
Здесь я не понимаю суть построения нормалей. Или суть отображения нормалей в таче?
Там nx и ny заданы через координаты точки (TX и TY) с минусом. То есть, для крайних точек, скажем, с правой стороны, икс будет 0.5, а вектор нормали будет иметь икс -0.5. Задание параметрами, а не циферками, всего лишь позволяет универсально все это сделать для всех нужных точек (можно и -0.5 поставить, но тогда это только для правого края сработает, а левый будет косячный).
И короче вроде бы тогда эта голубая шерсть должна концом доходить до нуля по икс (раз вектор у нормали по икс -0.5, точка "приложения" вектора 0.5), а она не доходит, из чего я делаю вывод, что чего-то я тут не догоняю.
И отдельно не догоняю, для чего все это сделано. Если даже полностью удалить этот пойнт, сфера продолжает делать примерно то же самое, что и делала, и сетка тоже...
null4
работает традиционным нулем, ничего не делает, но позволяет безнаказанно втыкать операторы до него (и не менять все время экспорт)
sopto1 и sopto2
переводит текстуру в каналы, причем верхний (sopto1) берет координаты вектора нормали (?), а нижний координаты точки.
Дальше по каждому sopto происходит одно и то же параллельно:
shuffle "рубит" все каналы из сопа кусками по 20 сэмплов (и мы получаем 60 каналов) reorder пересортировывает их по наборам tx-ty-tz; сhopto преобразует эти все чиселки в цветовую картинку, используя tx-ty-tz как rgb, причем размер chopto 20х20 пикселей - количество "наборов" (вертикаль) на длину порубленных в шафле кусочков (горизонталь), при этом chopto начинает снизу, то есть, tx0, ty0, tz0 - это rgb для каждой точки нижнего ряда (а, и поскольку sopto "разматывал" квадрат нойза в три канала тоже начиная с левого нижнего угла, видимо, мы "восстанавливаем" нойз)
res растягивает полученные 20 на 20 пикселей в картинку 1280 на 1280; topto переводит все обратно в каналы, причем обрезка идет ровно на один пиксель (в смысле, у нас все время один сэмпл из каналов r, g, b и альфа постоянный). Это даже не обрезка, а указание конкретного пикселя относительными координатами.
rename1
переименовывает каналы из topto3 в tx, ty, tz, и они уходят в transform1, который отвечает за движение сферы, заданной sphere1. Не совсем понимаю, почему в transform1 добавлено 0.01 по z - визуально с этим добавлением или без него результаты не очень сильно различаются, но сфера меньше "вгрызается" в сетку, если что-то такое мелкое добавить. Видимо, для этого и добавлено.
Еще не понимаю, с какой целью в сфере текстурные координаты изменены с тех, что по умолчанию на By Primitive Type. Ставила дефолтные экиректангуляр аутсайд - никакой разницы не вижу.
Ну и transform1 отправлен на рендер, и именно он и дает в итоговой картинке катающийся шарик.
Возвращаемся наверх.
math1 умножает все каналы topto1 на 2.46, select1 выбирает каналы r и g, заодно переименовывает их в u и v; feedback1 позволяет избежать зацикливания, lag1 замедляет этот поток; speed_u вроде бы должен быть "накопителем" значений из лага, плюс ограничителем, если значение попытается вылезти за предел от -1 до 1, оно автоматом будет приравнено либо к -1, либо к 1 (что ближе).
constant1 задает два канала u и v с нулевыми значениями, math2 прибавляет к этим нулям значения speed_u (и не совсем понятно, для чего нужна константа и эта математика и почему нельзя напрямую засунуть выход speed_u в limit - результат не меняется). Limit не дает появиться отрицательным значениям, если им вдруг вздумается появиться (отрицательные значения будут превращены в ноль). Null1 просто нуль, он отдает данные topto1 и topto3 - указывает относительную координату, по которой нужно взять данные rgb.
Из всего этого получается, что координата местоположения сферы определяется параметрами rgb, которые до этого были координатами точки нойза, а из какой именно точки брать это rgb - диктует замороченное рекурсивное преобразование параметров rgb, которые до этого были координатами вектора нормали той же точки нойза О_о
Дальше кусок патча внизу.
Material не знаю, зачем нужен именно здесь, все работает и без него. Convert конвертирует исходный mesh сетки в тип геометрии polygon для того, чтобы wire1 мог "нарисовать" сетку. Тут я вдруг перестала понимать, как работает wireframe и вообще все эти меши-полигоны. Вайр "превращает края в трубки а точки в сферы"(с, википедия). У меша есть точки, но... нет краев, что ли? Поэтому вайр справляется только с полигональными геометриями?
И отдельный вопрос, зачем именно менять тип геометрии отдельно, почему... А, ок, я вспомнила, чтобы наглядно было, что происходит : )) Вопрос был - почему не поменять меш на полигон в самой сетке.
Дальше стандартный набор рендер-свет-камера, камера и свет подключены к нулю, чтобы можно было двигать одновременно и то и другое, буде такое желание.
Итого - я плюс-минус могу описать, что именно делает каждая нода, но я так и не поняла общий концепт, да и какие-то механизмы внутри, чуть более крупные, чем одна нода. Например, я не понимаю, насколько движение шарика связано с исходным нойзом, реагирует ли оно на "впадины" и "пики", которые визуально видно на сетке. Просто смотрю на результат - вроде не реагирует. По вычислениям - ну, тоже как-то относительно, там исходные данные очень уж сильно преобразованы. Мне кажется, что это получается уже своеобразный рандом, хотя и основанный на "не рандомных" данных. Так и есть?
Ну и весь кусок преобразований верхнего topto - где лаг, скорость и лимит - там я вообще в дебрях, и в особенности не понимаю смысл speed. Вернее, как. Я понимаю смысл спида, как он описан в вики. Я, вероятно, понимаю локальный смысл спида в этом нетворке (если я правильно определила, что он работает как "накопитель" значений предыдущей ноды), но я не понимаю, как бы я догадалась такое сделать сама.