1 апреля в 20:00 я проведу онлайн-практикум на тему «Командная работа в Grasshopper: как ускорить проекты и выстроить эффективный процесс». На нем вы узнаете как ускорить параметрическую работу и работать одновременно над несколькими задачами.
ЗАПИСАТЬСЯ: https://forms.yandex.ru/u/69c4e14949af47b10226b7fc
Несколько лет назад ПИК обратился с задачей создать генератор паттернов фасадов для жилой застройки, чтобы архитекторы и дизайнеры могли перебирать художественные варианты, при этом не тратить время на перемоделирование.
Решение такой большой комплексной задачи требовало сначала создания MVP - минимального жизнепособного продукта на основе «реактивного» программирования в Grasshopper, чтобы проверить реализуемость идеи. И в завершении этот скрипт содержал огромное количество параметров и 70 000 компонентов. Скрипт на Grasshopper является отличным техническим заданием для написания полноценной программы.
Чтобы удержать такую огромную машину и чтобы она делала расчет в несколько секунд, необходимо было очень грамотно работать со структурой алгоритма. В программе имелся интерфейс, через который пользователь вводил данные, а данные уже обрабатывались скриптом и выдавали визуальную геометрию.
Логика работы Grasshopper такая, что когда данные меняются в начале, то обновляется весь скрипт. И нам это не подходило. Мы сделали так, что в зависимости от того, в каком месте находился пользователь в своем рабочем процессе, то та часть алгоритма работала, а остальная часть алгоритма принудительно отключалась. Таким образом, методом выборочной работы скрипта мы запускали только те процессы, которые требовали результата. Остальные части скрипта автоматически отключались, блокировали любое событие, которое могло бы их активировать в рабочем состоянии.
Чтобы ускорить работу самого скрипта, мы:
1. Переписывали некоторые стандартные компоненты и заменяли другими, более быстрыми алгоритмами в данной ситуации.
2. Создавали огромное количество кластеров с повторяющимися операциями, чтобы процесс можно было очень легко редактировать и не перемещаться из одного места в другое место.
3. Чтобы во всем этом не запутаться, у нас был разработан специальный словарь терминов, по которому можно было определять, какие части алгоритма должны были работать, какие нет и какие данные куда перемещались.
Это самый большой скрипт, который был написан в Grasshopper для таких задач. Дальше требовалось уже переписывать его на другом языке программирования и с помощью других инструментов.