Открываю новую рубрику "Synchro Инсайд", буду скидывать сюда всякие лайфхаки по работе с софтом. Если у кого есть вопросы, кидайте в комментарии, расскажу, что знаю. Чего не знаю, попробую на досуге раскопать. Или нет :)
Начнём с простенького примера, который, тем не менее, вызывает сложности у обучающихся, потому что ни в учебном ролике на YouTube, ни в разделе Help самой программы не описан весь алгоритм, поэтому, несмотря на скрупулёзное следование инструкции, у большинства начинающих четырёхмерщиков кран сперва вращается примерно так:
Вообще, большинство роликов и весь Help сделаны по старой версии софта, многие фишки из тьюториала в актуальном релизе Synchro либо не работают вовсе, либо работают не там и не так.
Вот у вас есть загруженная в базу трёхмерка башенного крана (о том, как не надо делать трёхмерку, мы обсудили здесь), трёхмерка назначена на ресурс в категории "Технические", ресурс назначен на работу. Можно не полениться и тут же сделать для крана отдельный визуальный профиль, чтобы он не менял окраску в процессе работы, а был зимой и летом одним цветом. Настройки профиля при этом будут выглядеть вот так:
Щелкаем правой клавишей в окне "3D пути" >> Добавить. Переходим в "Свойства 3D пути", присваиваем новому пути имя, идём в "Свойства работы" и там назначаем на ресурс "Башенный кран" новосозданный 3D-путь. Попутно можем назначить и помянутый выше визуальный профиль. Следующим шагом делаем то самое действие, которое пропущено в справке и в видеоуроке. Для 3D-пути ставим Выравнивание >> Вручную.
Только в этом случае все последующие шаги, описанные в справке, приведут вас к искомому результату. Подробно описывать не буду, дальше там всё изложено вполне доходчиво и правильно.
Дальше, правда, возникает один нюанс, который ощутимо снижает ценность вращения крана непосредственно для целей 4D-моделирования. Дело в том, что спланировать таким образом реальную циклограмму работы крана довольно затруднительно, что в условиях живого реализуемого проекта почти равносильно "невозможно".
Поясню суть проблемы. Если кран "вешается" на работу по монтажу какого-то элемента (что вроде бы логично), то он подаёт элемент, возможно, какое-то время его держит, потом уходит, а работа по монтажу продолжается. Хуже того, в настройках 3D-пути время для каждого визуального цикла задаётся в процентах от длительности работы. Т.е. чётко спланировать время работы крана можно только с калькулятором и только при условии, что кран действует на всём протяжении выполнения работы (игры с кривой потребления не рассматриваю, это ещё больше усложняет алгоритм, но точности не добавляет). Получается, что проще всего сделать для крана отдельную работу с фиксированной длительностью и копировать её под каждый подаваемый элемент. Или вообще ввести для крановых работ отдельный раздел WBS. Насколько это раздует объём графика, и как сложно будет это всё актуализировать при ежесуточном обновлении проекта, думаю, пояснять не надо.
И вот что с этим делать на реальных, а не показушных проектах, я, честно говоря, пока не знаю. Про показушные проекты мы уже говорили ранее. На данный момент для моделирования положения крана при монтаже конструкции мы используем не 3D-пути, а 3D-трансформацию. У этого метода куча своих издержек, о нём, если хотите, расскажу в другой раз. Он, как минимум, позволяет не раздувать количество работ графика до немыслимых величин.
Делитесь в комментариях, у кого какие есть соображения о плюсах/минусах практического использования 3D-путей для моделирования циклов крана в реальных "боевых" проектах. Я же пока просто рассказал, как заставить кран правильно вращаться.
Как принято говорить в интернетах, живите с этим.
