Дождь на ленте: капли падают, разгоняются и разбиваются

Ленту на шестьдесят пикселей я повесил вертикально в окно, чтобы сделать дождь. Первая версия работала так: одна переменная позиции, каждый кадр плюс один, в конце — сброс на ноль. Получилась одиночная капля, которая честно падала по одному и тому же маршруту, как лифт. Вторая попытка честнее: я завёл две переменные и два блока кода — и капли родились в один кадр, падали строем и приземлялись синхронно, как десант по команде. Ни то, ни другое погоду не изображало.

Разгадка простая и неприятная для первой интуиции: одна переменная хранит ровно одну каплю, а живой дождь — это капли, у каждой из которых своя позиция, своя скорость и своё расписание рождения. Никакая хитрая формула это не заменит, нужен список состояний. Такой список в Arduino-мире держат в массиве-слотах: пять-восемь ячеек, каждая — потенциальная капля, свободна или занята.

В этом уроке собираем дождь по-взрослому: массив слотов, спавн по случайному интервалу, разгон капли в полёте, след, который дорисовывает затухание, и всплеск при ударе о землю. Механику затухания-шлейфа мы разбирали в отдельном уроке про fadeToBlackBy — здесь она работает на нас, а каркас кадров по-прежнему строится на millis() из урока про millis вместо delay.

Каркас выглядит так. Заводим массивы: позиция головы, период шага, счётчик до шага и флаг жива-ли — по одному на слот. Восемь слотов — до восьми капель одновременно; на ленте в шестьдесят пикселей этого достаточно с запасом, потому что при кадре в 30 мс капля живёт одну-две секунды и слоты успевают освобождаться.

Спавн отделён от рисования — и это первое, что стоит запомнить. Кадр рисуется по таймеру каждые 30 мс, а рождение капли живёт по своему таймеру: как только он срабатывает, ищем свободный слот и заполняем его, а следующий интервал рождения тут же перебрасываем кубиком — случайное число из диапазона 250–900 мс. Именно переброс после каждого спавна делает дождь неровным: капли идут не строем, а вразнобой, и глаз верит.

Падение — это не плюс-один каждый кадр, а шаг раз в dropStep кадров. Новый капле достаётся случайный шаг: единица — быстрая, двойка — вдвое медленнее. Дальше начинается физика: с шансом примерно один из пяти шагов период сокращается на единицу — капля разгоняется. Мелочь, а полёт сразу обретает вес: медленный старт, ускорение к земле. След рисовать не нужно вообще: перед движением каждого кадра вся лента гаснет через fadeToBlackBy, и прошлые позиции головы тают сами, оставляя ровно ту траекторию, которую капля прошла.

Форма хранения — второе решение каркаса. Четыре параллельных массива по восемь ячеек, как здесь, живут проще, чем массив структур: к слоту обращаемся номером, и каждая функция берёт только своё. Массив структур Kaplya kapli[8] с полями pozicia, shag, taimer, zhiva компактнее для передачи целиком в функцию и легче расширяется — но для восьми слотов выигрыша нет, а вложенные обращения kapli[i].pozicia читаются длиннее. Я держу простое правило: до пары десятков однотипных слотов — параллельные массивы, дальше — структура. На Uno оба варианта съедают одинаковые тридцать два байта, так что выбор диктует читаемость, а не память.

Три места, где я спотыкался. Первое — зерно генератора: без randomSeed() ардуиновский random каждый раз после включения питания выдаёт одну и ту же последовательность, и ваш дождь идёт по одному и тому же сценарию. Свободный аналоговый пин, ни к чему не подключённый, ловит шум и даёт при старте разные числа — одна строка в setup решает вопрос. Второе — соблазн спавнить каплю в каждом кадре: при кадре 30 мс это тридцать три рождения в секунду, и через секунду лента превращается в сплошной поток без просветов. Интервалы рождения должны быть заметно длиннее жизни одной капли — тогда на ленте живут и просветы, и очереди.

Третье место тоньше. Когда все слоты заняты, новая капля молча не рождается — цикл просто не находит свободный слот. Это не сбой, а нормальное поведение очереди с отказом: дождь в этот миг и так плотный. Я один раз потратил вечер на поиск «пропадающих капель», прежде чем понял, что их и не должно было быть — слоты кончились. Считайте это встроенным ограничителем плотности.

Ещё одна ручка, о которой легко забыть: FastLED.setBrightness() режет яркость и ток глобально, и для оконного дождя имеет смысл ставить её на 150-180 из 255 — сквозь стекло ночью полной яркости никто не видел, а блок питания и проводка дышат свободнее. Глобальный потолок не отменяет локальный: всплеск у земли всё равно пробивается выше общего уровня оператором +=, и библиотека сама прижмёт его к границе масштаба. Это тот случай, когда ограничение честнее на входе, чем клиппинг на выходе.

В симуляторе проверьте две крайности ручки. На минимуме дождь должен читаться как морось: пара капель, длинные паузы, каждая — с заметным разгоном. На максимуме — как ливень: слоты забиты, между каплями нет просветов, а у земли постоянно тлеют всплески. Кнопка-шквал интересна другим: заметьте, что при рождении каждые 60–150 мс разгон исчезает — капля не успевает ускориться, потому что долетает за считанные шаги. Густой дождь в природе и выглядит «плоским», без индивидуальных характеров.

Числа кадра тоже стоит проверить руками. Кадр 30 мс при 60 пикселях — это 533 кадра на четыре секунды падения с верха до низа; капля со шагом 2 проходит путь за 1066 тиков таймера, и если слоты разрешили только восемь капель, плотность выше определённой физически не наберётся — рождению просто негде жить. Отсюда практический потолок: на шестидесяти пикселях восемь слотов держат морось и дождь, а сплошная стена ливня потребует либо больше слотов, либо короче ленту. Я пробовал и тот и другой вариант — оба работают, но второй съедает заметный кусок кадра на show().

Всплеск — одна строка, а эффект даёт непропорционально большой: в момент приземления нижний пиксель получает добавку синего оператором +=, второй снизу — вдвое меньше. Затухание гасит брызги за пару кадров, и у земли возникает мерцающая кромка, как у лужи под дождём. Тот же приём в обратную сторону работает для метеора: яркость вспышки умножить на три — и удар будет читаться даже из соседней комнаты.

Практическая мелочь, которая портит половину подвесов: нумерация пикселей идёт от разъёма. Если лента висит разъёмом вниз, ваш «небо-ноль» оказывается снизу, и дождь льёт с земли в небо. Лечится двумя способами: переклеить ленту или перевернуть индекс — рисовать в leds[NUM_LEDS - 1 - pos]. Прежде чем сверлить отверстия под подвес, залейте один пиксель в нулевой ячейке и посмотрите, где он физически оказался, — приём из урока про первый скетч экономит один перекос на стене.

И не путайте этот дождь со статичным «дождём» из урока про ленту-прогноз погоды — там лента просто красилась синим с двумя светлыми пикселями по коду от ESP32. То — сценарий-картинка, здесь — траектории. Комбинировать их можно: внешний код шлёт интенсивность, а массив капель уже превращает её в плотность спавна.