ДИНАМО — ЭТО ХОРОШИЙ ТУПИК В АВТОМАТИЗАЦИИ (часть 1)
Последние пару дней я упоролся в очередные незапланированные семейства. Из беседы в чате про крепления воздуховодов я перешёл к разработке.
Сначала нашёл свои старые наработки двухгодичной давности. Всё переделал, стало и красивее, и функциональнее, больше возможностей по подсчёту.
Если для трубопроводов я создал библиотеку без автоматизации (вот она: https://muratovbim.pro/product/biblioteka-krepleniya-dlya-truboprovodov/), так как целевая аудитория была проектировщики ИЖС, то тут очевидно, что целевая аудитория шире и, скорее, даже совсем не ижээсники, а проектировщики более крупных зданий. Поэтому нужна автоматизация по расстановке креплений на протяжённых трассах.
Вот ею я и занимался эти несколько дней. Пока что в стадии тестов, но кое-какие выводы я для себя сформулировал, поделюсь ими с вами.
1. Динамо — это хороший способ дёшево начать автоматизировать свою работу. Можете посмотреть вебинар о том, что это: https://youtu.be/VDqzQxGiVj8
2. Под дёшево я подразумеваю более низкий порог входа. Вот прям так с ноги сюда не залететь, но постепенно, потихоньку, освоиться можно. Даже довольно простые вещи могут сэкономить много времени по сравнению с ручной работой. Часть этих задач по сути на себя забрала «Параметризация» из МодПлюса, простые сценарии там воспроизвести проще, чем даже в Динамо, а со сложными тоже придётся морочиться из-за синтаксиса.
3. Основная работа, с которой сталкиваюсь в Динамо, — обработка списков. Вся ваша автоматизация в Динамо — это бесконечные танцы со списками, их уровнями и типами переплетений.
И вот тут закрадывается основная боль. Рано или поздно вам придётся обрабатывать всё более сложные в плане уровней списки. Самое дурацкое тут — уровни вложенности списков, которые могут меняться в зависимости от того, какие элементы приходят в скрипт. Соответственно, не всегда получится обработать их одним способом. Чаще всего получится, но не всегда.
Выходов тут два: либо на каком-то этапе делать списки плоскими, чтобы они были предсказуемыми, либо уводить работу со списками в более контролируемые среды, например в те же Питон-ноды. Это не обязательно весь скрипт, это может быть та его часть, которую трудно нормально обработать нодами.
Иногда решить задачу циклами в Питоне мне проще, чем придумывать обработку нодами. Я просто не знаю, как это по уму сделать нодами, мне проще открыть Питон-нод и написать циклы. Получается не всегда с первого раза, но в итоге работает. Ну и само собой, рано или поздно вы упрётесь в ограниченность стандартной библиотеки нодов. Что-то появляется в новых версиях, дополняется, но иногда их реализация просто сомнительная. На пакеты тоже надеяться не нужно, это слишком ограничивает вашу работу и не даёт нормально расшаривать скрипты.
Отдельно бесило, когда авторы пакета называют свой нод так же, как называется стандартный нод. Подкладывать такую свинью пользователям — это тоже надо быть тем ещё свинтусом.
Поэтому когда-то я пользовался пакетами, потом стал выделять из них Питоновские ноды и добавлять в скрипты, чтобы не зависеть от пакетов. Потом я стал сам всё писать в Питоне. Изредка могу зайти на Гитхаб пакета Клокворк и прям оттуда выдёргиваю нужный мне код.
Последние пару дней я упоролся в очередные незапланированные семейства. Из беседы в чате про крепления воздуховодов я перешёл к разработке.
Сначала нашёл свои старые наработки двухгодичной давности. Всё переделал, стало и красивее, и функциональнее, больше возможностей по подсчёту.
Если для трубопроводов я создал библиотеку без автоматизации (вот она: https://muratovbim.pro/product/biblioteka-krepleniya-dlya-truboprovodov/), так как целевая аудитория была проектировщики ИЖС, то тут очевидно, что целевая аудитория шире и, скорее, даже совсем не ижээсники, а проектировщики более крупных зданий. Поэтому нужна автоматизация по расстановке креплений на протяжённых трассах.
Вот ею я и занимался эти несколько дней. Пока что в стадии тестов, но кое-какие выводы я для себя сформулировал, поделюсь ими с вами.
1. Динамо — это хороший способ дёшево начать автоматизировать свою работу. Можете посмотреть вебинар о том, что это: https://youtu.be/VDqzQxGiVj8
2. Под дёшево я подразумеваю более низкий порог входа. Вот прям так с ноги сюда не залететь, но постепенно, потихоньку, освоиться можно. Даже довольно простые вещи могут сэкономить много времени по сравнению с ручной работой. Часть этих задач по сути на себя забрала «Параметризация» из МодПлюса, простые сценарии там воспроизвести проще, чем даже в Динамо, а со сложными тоже придётся морочиться из-за синтаксиса.
3. Основная работа, с которой сталкиваюсь в Динамо, — обработка списков. Вся ваша автоматизация в Динамо — это бесконечные танцы со списками, их уровнями и типами переплетений.
И вот тут закрадывается основная боль. Рано или поздно вам придётся обрабатывать всё более сложные в плане уровней списки. Самое дурацкое тут — уровни вложенности списков, которые могут меняться в зависимости от того, какие элементы приходят в скрипт. Соответственно, не всегда получится обработать их одним способом. Чаще всего получится, но не всегда.
Выходов тут два: либо на каком-то этапе делать списки плоскими, чтобы они были предсказуемыми, либо уводить работу со списками в более контролируемые среды, например в те же Питон-ноды. Это не обязательно весь скрипт, это может быть та его часть, которую трудно нормально обработать нодами.
Иногда решить задачу циклами в Питоне мне проще, чем придумывать обработку нодами. Я просто не знаю, как это по уму сделать нодами, мне проще открыть Питон-нод и написать циклы. Получается не всегда с первого раза, но в итоге работает. Ну и само собой, рано или поздно вы упрётесь в ограниченность стандартной библиотеки нодов. Что-то появляется в новых версиях, дополняется, но иногда их реализация просто сомнительная. На пакеты тоже надеяться не нужно, это слишком ограничивает вашу работу и не даёт нормально расшаривать скрипты.
Отдельно бесило, когда авторы пакета называют свой нод так же, как называется стандартный нод. Подкладывать такую свинью пользователям — это тоже надо быть тем ещё свинтусом.
Поэтому когда-то я пользовался пакетами, потом стал выделять из них Питоновские ноды и добавлять в скрипты, чтобы не зависеть от пакетов. Потом я стал сам всё писать в Питоне. Изредка могу зайти на Гитхаб пакета Клокворк и прям оттуда выдёргиваю нужный мне код.
Блог Вадима Муратова
Библиотека: крепления для трубопроводов — Блог Вадима Муратова
Версия Revit — 2019
ДИНАМО — ЭТО ХОРОШИЙ ТУПИК В АВТОМАТИЗАЦИИ (часть 2)
Проблемы у классического нодового Динамо я бы выделил следующие:
1. Все ноды обрабатываются вместе, что иногда приводит к сбоям в алгоритме, приходится как минимум перезапускать скрипт несколько раз. Не очень часто, но бывает нужно, чтобы алгоритм не забегал вперёд и работал по цепочке, особенно когда есть параллельная обработка нескольких веток, которые в какой-то момент должны сойтись вместе.
2. Ноды в Динамо, конечно, тоже являются программным кодом, тоже циклами по обработке списков, но каждый нод генерирует такие списки, иногда они усложняются до невозможности их предсказуемо использовать.
3. Зависимость от стандартных библиотек довольно скоро обернётся серьёзными трудностями в получении результата. Пакеты выручают, но это «грязные» скрипты, они годятся только для работы в одного.
4. Сложности с созданием интерфейсов для пользователя. В последних версиях стало лучше, но всё же проблемы есть.
5. Разработчики, которые решили поменять механизм Питона без автоматической конвертации, которые иногда выводят одни ноды и заменяют на другие под теми же именами, что приводит к ошибкам. Понятно, что надо развиваться, обновлять, но это всё равно неудобно.
В общем, Динамо — это хорошо, когда нужно накидать что-то простое. Но это в итоге станет тупиком, если планируете делать более сложные вещи. А вы будете их делать, если встанете на этот путь. Питон тоже не спасение, хотя он сильно расширит ваши возможности. Если выбирать, на что потратить время, лучше всё же лезть в Си шарп и плагины. Это сложнее, сильно сложнее, чем накидать что-то в Питоне, но тем не менее. Время всё равно потратите, так потратьте на что-то более перспективное по части автоматизации. Можете там втихоря что-то пописывать, а пацанам за гаражами говорить, что мамку Си шарпа четырнадцать раз за ночь и даже не устали.
Применительно к моей текущей задаче — Динамо обрабатывает нестабильно. Как только меняется модель и структура списков изменяется, то тут же вылезают ошибки. И что мне делать? Я ведь хочу закончить этот скрипт. Значит, я буду уводить в Питон всё, что не работает так, как мне нужно. Боль, слёзы, а что поделать.
Учите Си шарп с детства, не повторяйте моих ошибок.
Проблемы у классического нодового Динамо я бы выделил следующие:
1. Все ноды обрабатываются вместе, что иногда приводит к сбоям в алгоритме, приходится как минимум перезапускать скрипт несколько раз. Не очень часто, но бывает нужно, чтобы алгоритм не забегал вперёд и работал по цепочке, особенно когда есть параллельная обработка нескольких веток, которые в какой-то момент должны сойтись вместе.
2. Ноды в Динамо, конечно, тоже являются программным кодом, тоже циклами по обработке списков, но каждый нод генерирует такие списки, иногда они усложняются до невозможности их предсказуемо использовать.
3. Зависимость от стандартных библиотек довольно скоро обернётся серьёзными трудностями в получении результата. Пакеты выручают, но это «грязные» скрипты, они годятся только для работы в одного.
4. Сложности с созданием интерфейсов для пользователя. В последних версиях стало лучше, но всё же проблемы есть.
5. Разработчики, которые решили поменять механизм Питона без автоматической конвертации, которые иногда выводят одни ноды и заменяют на другие под теми же именами, что приводит к ошибкам. Понятно, что надо развиваться, обновлять, но это всё равно неудобно.
В общем, Динамо — это хорошо, когда нужно накидать что-то простое. Но это в итоге станет тупиком, если планируете делать более сложные вещи. А вы будете их делать, если встанете на этот путь. Питон тоже не спасение, хотя он сильно расширит ваши возможности. Если выбирать, на что потратить время, лучше всё же лезть в Си шарп и плагины. Это сложнее, сильно сложнее, чем накидать что-то в Питоне, но тем не менее. Время всё равно потратите, так потратьте на что-то более перспективное по части автоматизации. Можете там втихоря что-то пописывать, а пацанам за гаражами говорить, что мамку Си шарпа четырнадцать раз за ночь и даже не устали.
Применительно к моей текущей задаче — Динамо обрабатывает нестабильно. Как только меняется модель и структура списков изменяется, то тут же вылезают ошибки. И что мне делать? Я ведь хочу закончить этот скрипт. Значит, я буду уводить в Питон всё, что не работает так, как мне нужно. Боль, слёзы, а что поделать.
Учите Си шарп с детства, не повторяйте моих ошибок.
Вот вам пример работы в Динамо без Питона и с Питоном
Первый алгоритм я писал два года назад, когда сильно хуже умел в Питон. Что-то я использовал, но это было по мелочи, списки какие-нибудь проверить через zip.
Второй алгоритм придумал сегодня. Тут как бы ничего гениального, но добавление Ревит АПИ помогло решить проблему без прямого участия геометрии. Щас подробнее распишу.
Задача: нужно получить расстояние от точки вставки крепления до ближайшего перекрытия сверху. При этом перекрытие в связанной модели.
Старый алгоритм
Немного Питона тут всё же сделать пришлось, но его я где-то раскопал в интернете, на форуме Динамо, скорее всего. Код получал из связанной модели перекрытия и крыши.
Дальше начиналась пляска. Из полученных элементов получаю геометрию — солиды, твёрдотельную геометрию. Беру точки вставки семейства, проецирую её на эти солиды. И вот тут важное отличие обработки в Динамо от обработки программным кодом.
Динамо не умеет вовремя остановиться. Поскольку заранее я не знаю, какое перекрытие мне подойдёт, я вынужден проецировать все точки на все перекрытия. Точек много, перекрытий пусть не сильно, но всё это перемножается и выдаёт мне кучу значений. Преобразование в геометрию — это долго. Перемножить — долго. Дальше нужно ещё обработать результаты, это тоже отдельная работа.
В итоге я всё же получаю свою точку, по сути я там беру расстояния и ищу наименьшее, то есть беру самую близкую плиту. Строю линию, получаю её длину — вот и длина моих шпилек у креплений. Можно было не строить линию, а взять координаты Z, но суть мало меняется.
Это долгий и сложный алгоритм, потому что Динамо будет брать всё в кучу и обрабатывать всё сразу. А мне потом ещё и данные правильные выделять.
Новый алгоритм
Сперва я прилёг на кровать. Потом подумал, что могу также в Питоне получить перекрытия, а затем взять или координаты или что-нибудь такое. И сразу там же пробежаться по точкам вставки креплений, сравнить их с координатой плиты и выбрать ближайшую большую. В целом, мне ведь и плита по сути не нужна, только отметка низа.
Это я и сделал. Координату плиты получить не удалось, но с неё можно получить габаритный ящик — bounding box. Это такой кубик, в которой вписывается вся геометрия плиты. У него есть точка максимума и минимума. Из точки минимума я могу вытащить отметку низа, координату Z. Вот и получилась точка, куда надо тащить шпильку, а значит и легко получаю длину шпильки.
Я подозреваю, что такой метод должен работать побыстрее. Ведь мне не приходится проверять все плиты со всеми точками. Не приходится получать геометрию плиты, хотя не уверен, ведь баундинг бокс тоже по сути какая-то геометрия. С другой стороны, это не тело, а две точки. В общем, сам алгоритм стал короче и проще, надеюсь, ещё и быстрее.
Оценить скорость прям супер точно не могу, скрипт в целом срабатывает не моментально даже на небольшой модели. Думаю, это из-за того, что Динамо приходится ещё расставлять крепления, это тоже он делает не особо шустро. Но очевидный плюс — не нужно ничего дополнительно обрабатывать, я все данные генерирую в самом коде, он работает в основном с числами, просто сравнивает списки. Это явно должно быть быстрее.
Есть у алгоритма минус, которого нет у первого способа. Он не будет работать со скатными кровлями, так как баундинг бокс всегда будет давать граничный кубик в виде параллелепипеда, но с этим можно смириться, мне кажется. Геометрию можно и в Питоне получать, конечно, но я пока не углублялся в эту тему, в данном случае это всё же излишне.
Вот такая получается разница, всё показал на картинках.
Первый алгоритм я писал два года назад, когда сильно хуже умел в Питон. Что-то я использовал, но это было по мелочи, списки какие-нибудь проверить через zip.
Второй алгоритм придумал сегодня. Тут как бы ничего гениального, но добавление Ревит АПИ помогло решить проблему без прямого участия геометрии. Щас подробнее распишу.
Задача: нужно получить расстояние от точки вставки крепления до ближайшего перекрытия сверху. При этом перекрытие в связанной модели.
Старый алгоритм
Немного Питона тут всё же сделать пришлось, но его я где-то раскопал в интернете, на форуме Динамо, скорее всего. Код получал из связанной модели перекрытия и крыши.
Дальше начиналась пляска. Из полученных элементов получаю геометрию — солиды, твёрдотельную геометрию. Беру точки вставки семейства, проецирую её на эти солиды. И вот тут важное отличие обработки в Динамо от обработки программным кодом.
Динамо не умеет вовремя остановиться. Поскольку заранее я не знаю, какое перекрытие мне подойдёт, я вынужден проецировать все точки на все перекрытия. Точек много, перекрытий пусть не сильно, но всё это перемножается и выдаёт мне кучу значений. Преобразование в геометрию — это долго. Перемножить — долго. Дальше нужно ещё обработать результаты, это тоже отдельная работа.
В итоге я всё же получаю свою точку, по сути я там беру расстояния и ищу наименьшее, то есть беру самую близкую плиту. Строю линию, получаю её длину — вот и длина моих шпилек у креплений. Можно было не строить линию, а взять координаты Z, но суть мало меняется.
Это долгий и сложный алгоритм, потому что Динамо будет брать всё в кучу и обрабатывать всё сразу. А мне потом ещё и данные правильные выделять.
Новый алгоритм
Сперва я прилёг на кровать. Потом подумал, что могу также в Питоне получить перекрытия, а затем взять или координаты или что-нибудь такое. И сразу там же пробежаться по точкам вставки креплений, сравнить их с координатой плиты и выбрать ближайшую большую. В целом, мне ведь и плита по сути не нужна, только отметка низа.
Это я и сделал. Координату плиты получить не удалось, но с неё можно получить габаритный ящик — bounding box. Это такой кубик, в которой вписывается вся геометрия плиты. У него есть точка максимума и минимума. Из точки минимума я могу вытащить отметку низа, координату Z. Вот и получилась точка, куда надо тащить шпильку, а значит и легко получаю длину шпильки.
Я подозреваю, что такой метод должен работать побыстрее. Ведь мне не приходится проверять все плиты со всеми точками. Не приходится получать геометрию плиты, хотя не уверен, ведь баундинг бокс тоже по сути какая-то геометрия. С другой стороны, это не тело, а две точки. В общем, сам алгоритм стал короче и проще, надеюсь, ещё и быстрее.
Оценить скорость прям супер точно не могу, скрипт в целом срабатывает не моментально даже на небольшой модели. Думаю, это из-за того, что Динамо приходится ещё расставлять крепления, это тоже он делает не особо шустро. Но очевидный плюс — не нужно ничего дополнительно обрабатывать, я все данные генерирую в самом коде, он работает в основном с числами, просто сравнивает списки. Это явно должно быть быстрее.
Есть у алгоритма минус, которого нет у первого способа. Он не будет работать со скатными кровлями, так как баундинг бокс всегда будет давать граничный кубик в виде параллелепипеда, но с этим можно смириться, мне кажется. Геометрию можно и в Питоне получать, конечно, но я пока не углублялся в эту тему, в данном случае это всё же излишне.
Вот такая получается разница, всё показал на картинках.
Иногда полезно вылезти из-за компа и посмотреть на реалии.
Вот так гуляю по детскому миру, поехали за обувью ребёнку на весну, смотрю — а там эти самые крепления воздуховодов к профлисту.
И оказалось, что по идее надо бы заложить возможность вращать трапециевидный кронштейны, так как воздуховоды же могут под разным углом к профилю идти.
В то же время, ну вот кто будет так морочиться и крутить эти кронштейны? Только ради устранения пересечений.
Но тогда проще вообще обрезать геометрию кронштейнов, чтобы она не залезала на профлист. Будет некрасиво, зато меньше геморроя. В спецификации посчитается же.
Но это пока только мысли. Спринклерный крепеж тоже есть, правда, его засунул в библиотеку креплений труб, что в целом логично, конечно. Но в будущем перенесу в библиотеку с креплениями труб, где скрипт будет раскидывать крепеж на горизонтальных магистралях.
Если, конечно, в очередной раз не забью на это, потому что идеальное решение сделать не получается.
Вот так гуляю по детскому миру, поехали за обувью ребёнку на весну, смотрю — а там эти самые крепления воздуховодов к профлисту.
И оказалось, что по идее надо бы заложить возможность вращать трапециевидный кронштейны, так как воздуховоды же могут под разным углом к профилю идти.
В то же время, ну вот кто будет так морочиться и крутить эти кронштейны? Только ради устранения пересечений.
Но тогда проще вообще обрезать геометрию кронштейнов, чтобы она не залезала на профлист. Будет некрасиво, зато меньше геморроя. В спецификации посчитается же.
Но это пока только мысли. Спринклерный крепеж тоже есть, правда, его засунул в библиотеку креплений труб, что в целом логично, конечно. Но в будущем перенесу в библиотеку с креплениями труб, где скрипт будет раскидывать крепеж на горизонтальных магистралях.
Если, конечно, в очередной раз не забью на это, потому что идеальное решение сделать не получается.
Такое тоже можете проектировать с моими библиотеками.
Вот: https://muratovbim.pro/product/kuhonnye-zonty/
Вот: https://muratovbim.pro/product/kuhonnye-zonty/
СЕГОДНЯ ПРЯМОЙ ЭФИР ПО РАЗРАБОТКЕ СЕМЕЙСТВ
Братья и сестры во софте! Сегодня, 04.03.2025 года в 19:00 МСК, проведу прямой эфир на Твиче.
Что там будет и почему не по шаблонам. Там будет разработка реального семейства для реального заказчика, а модели ему реально надо получить до конца недели. Реально буду реальными руками делать реальный заказ.
Поэтому во вторник делаем стрим по разработке, а в четверг — по шаблону.
Сегодня делаем щелевой диффузор с КСД с регулируемым количеством подключений. Количество щелей тоже регулируется.
Сделаем геометрию, настроим соединители, вполне вероятно, что с помощью Динамо нагенерируем данные для таблицы выбора, чтобы учесть шаг 1 мм для решётки и камеры.
Вообще, у меня есть бесплатный курс про такое семейство. Непривычно, конечно, видеть слово «бесплатно» в канале Муратова, ну да что ж поделать, ничто человеческое мне не чуждо. Вот курс: https://stepik.org/course/185148
Итак, до встречи на Твиче: https://www.twitch.tv/muratovbim
Кто будет онлайн — ставьте огонёчки. Запись смогут посмотреть доны в ВК.
Братья и сестры во софте! Сегодня, 04.03.2025 года в 19:00 МСК, проведу прямой эфир на Твиче.
Что там будет и почему не по шаблонам. Там будет разработка реального семейства для реального заказчика, а модели ему реально надо получить до конца недели. Реально буду реальными руками делать реальный заказ.
Поэтому во вторник делаем стрим по разработке, а в четверг — по шаблону.
Сегодня делаем щелевой диффузор с КСД с регулируемым количеством подключений. Количество щелей тоже регулируется.
Сделаем геометрию, настроим соединители, вполне вероятно, что с помощью Динамо нагенерируем данные для таблицы выбора, чтобы учесть шаг 1 мм для решётки и камеры.
Вообще, у меня есть бесплатный курс про такое семейство. Непривычно, конечно, видеть слово «бесплатно» в канале Муратова, ну да что ж поделать, ничто человеческое мне не чуждо. Вот курс: https://stepik.org/course/185148
Итак, до встречи на Твиче: https://www.twitch.tv/muratovbim
Кто будет онлайн — ставьте огонёчки. Запись смогут посмотреть доны в ВК.
Stepik: online education
Курс Муратова: семейство щелевой решетки с адаптером в Revit
Бесплатный мини-курс по разработке семейства щелевой решетки с адаптером в Autodesk Revit. Покажу, как с нуля сделать BIM-модель воздухораспределителя.
Вчера я вам втирал, как классно упростил алгоритм для расстановки креплений после того, как прилёг на кровать.
Но потом я пошёл снова лёг на кровать, уже чтобы спать. И в тот момент я понял:надо больше лежать на кровати мой алгоритм хорошо будет работать только с плоскими перекрытиями. А как только появится какая-нибудь разноуровневая история, то всё пойдёт по известным органам, в быту гениталиям.
Потому что скрипт найдёт обе плиты, возьмёт отметку их низа и более низкая плита определится, как ближайшая. Значит, со всего этажа крепления потянут шпилечки к ней.
Поэтому уйти от работы с геометрией нельзя. Поэтому вернул в алгоритм проклятые солиды. Немного переработал обработку пересечений, стало попроще, но ключевой момент остался — плита обрабатывается как геометрия с проецированием точек на неё вдоль оси Зэд.
Перед этим проверил, в каком виде приходит плита, учитываются ли в солиде отверстия. Проверил — да, учитываются. Даже если плита состоит из нескольких замкнутых контуров, всё равно все солиды выглядят прям как плита в модели.
Значит, можно пулять в неё точки, определять расстояния и тянуть шпильки. Правда, это потребует от проектировщика аккуратности в моделировании, на картинке слева вверху видно, как шпильки улетели на этаж выше. Потому что в плите, куда по идее должны были прилететь шпильки, отверстие, соответственно, шпилькам некуда крепится.
В общем, пока оставлю такую версию, мне предложили ещё пускать лучи, но это тема мудрёная, так что пока умею только в лучи добра или поноса, смотря что покушаю. Вернусь к скрипту позже, когда разберусь с текущими заказами.
Скрипт работает долго, но вроде бы получается красиво. Надо ещё будет сделать версию для тех, у кого нет подложки Ревита, там будет как раз простой вариант с прокидываем шпилек до ровной плоскости, перепады не учесть.
Но потом я пошёл снова лёг на кровать, уже чтобы спать. И в тот момент я понял:
Потому что скрипт найдёт обе плиты, возьмёт отметку их низа и более низкая плита определится, как ближайшая. Значит, со всего этажа крепления потянут шпилечки к ней.
Поэтому уйти от работы с геометрией нельзя. Поэтому вернул в алгоритм проклятые солиды. Немного переработал обработку пересечений, стало попроще, но ключевой момент остался — плита обрабатывается как геометрия с проецированием точек на неё вдоль оси Зэд.
Перед этим проверил, в каком виде приходит плита, учитываются ли в солиде отверстия. Проверил — да, учитываются. Даже если плита состоит из нескольких замкнутых контуров, всё равно все солиды выглядят прям как плита в модели.
Значит, можно пулять в неё точки, определять расстояния и тянуть шпильки. Правда, это потребует от проектировщика аккуратности в моделировании, на картинке слева вверху видно, как шпильки улетели на этаж выше. Потому что в плите, куда по идее должны были прилететь шпильки, отверстие, соответственно, шпилькам некуда крепится.
В общем, пока оставлю такую версию, мне предложили ещё пускать лучи, но это тема мудрёная, так что пока умею только в лучи добра или поноса, смотря что покушаю. Вернусь к скрипту позже, когда разберусь с текущими заказами.
Скрипт работает долго, но вроде бы получается красиво. Надо ещё будет сделать версию для тех, у кого нет подложки Ревита, там будет как раз простой вариант с прокидываем шпилек до ровной плоскости, перепады не учесть.
Вчера на прямом эфире Динамо зависло...
Так что доделать прям до конца семейство не получилось, но в этом посте расскажу пару интересных моментов. С геометрией мы разобрались, это я сделать успел, там из интересного разве что система массивов для отображения разного количества патрубков и соединителей.
Собственно, а чего же зависло Динамо? А такое бывает, когда обрабатываешь списки на полмиллиона позиций. Если переводить это в строки таблицы выбора, которую я в Динамо и пытался сгенерировать, то это уже не так много строк, в моём случае было 116 тысяч с небольшим.
Это слишком большое количество для семейства. В таблице такого размера поиск будет идти очень долго, каждое изменение параметра, даже не связанного с марками, будет приводить к подписаниям.
Какое же решение? Нужно разбивать такие таблицы на несколько. Судя по всему, для Ревита критично не количество таблиц, а размер той конкретной, по которой он ведёт поиск. Поэтому после того, как Ревит и Динамо закрылись без сохранения данных, я вновь накидал скрипт, но теперь сделал его умнее.
Вместо того, чтобы генерировать сразу всё, я добавил нод, которым могу управлять количеством строк. И сам алгоритм оттестировал на небольшом количестве длин решётки. Три длины давали 72 строки или 360 позиций в списке. Собрал тестовые данные, проверил экспорт в Эксель — всё работает.
Дальше я решил не вбивать сразу всё количество длин, а как раз-таки разбить на несколько таблиц варианты по длинам решётки. Выбрал разбивку на 8 таблиц. Получились таблицы по 600 строк, восьмая на 650. На тот момент не было уверенности, что это будет работать прям быстро, как хотелось бы.
Загрузил все восемь таблиц, написал формулу для подставки имени таблицы, из которой семейство вытянет данные. Можно было бы генерировать её в Экселе, но мне что-то стало неохота, пусть занятие такое себе.
В результате всё работает отлично! Семейство не мгновенно, но достаточно быстро меняется, так что результатом я доволен. В будущем буду ещё применять такую сильную разбивку на отдельные таблицы, пусть это и менее удобно с точки зрения управления данными. В теории можно в Экселе генерировать одну сплошную таблицу, а потом на других листах ссылаться на неё и выводить нужное количество строк, но ведь и Эксель не особо шустро работает, когда так много строк.
Второй момент — это условное обозначение. С щелевыми диффузорами всегда были вопросики, но вчера пришла идея, как показывать эти дурацкие треугольники. Делать один длиннющий — я такое делал, мне кажется, это не особо красивым. Делать несколько треугольников — ну ок, а как выбрать их количество, как много их надо и как этим управлять. Но потом...
Для массивов я вкладываю семейство патрубка. Потом он, соответственно, множится по количеству нужных мне точек входа в камеру. Идея простая — вложить треугольник в патрубок. Где не надо, оно будет скрываться, где надо — отображаться. Для плана сделал символическими линиями, для 3Д — линиями модели. И в итоге я не парюсь о том, как управлять количеством треугольников, всё происходит само. Дал пользователю возможность управлять размером треугольника и отступом и от диффузора и всё, отличное решение.
Запись эфира доны смогут посмотреть в ВК. Ну а те фишки, что не показал на эфире, рассказал здесь для всех.
Так что доделать прям до конца семейство не получилось, но в этом посте расскажу пару интересных моментов. С геометрией мы разобрались, это я сделать успел, там из интересного разве что система массивов для отображения разного количества патрубков и соединителей.
Собственно, а чего же зависло Динамо? А такое бывает, когда обрабатываешь списки на полмиллиона позиций. Если переводить это в строки таблицы выбора, которую я в Динамо и пытался сгенерировать, то это уже не так много строк, в моём случае было 116 тысяч с небольшим.
Это слишком большое количество для семейства. В таблице такого размера поиск будет идти очень долго, каждое изменение параметра, даже не связанного с марками, будет приводить к подписаниям.
Какое же решение? Нужно разбивать такие таблицы на несколько. Судя по всему, для Ревита критично не количество таблиц, а размер той конкретной, по которой он ведёт поиск. Поэтому после того, как Ревит и Динамо закрылись без сохранения данных, я вновь накидал скрипт, но теперь сделал его умнее.
Вместо того, чтобы генерировать сразу всё, я добавил нод, которым могу управлять количеством строк. И сам алгоритм оттестировал на небольшом количестве длин решётки. Три длины давали 72 строки или 360 позиций в списке. Собрал тестовые данные, проверил экспорт в Эксель — всё работает.
Дальше я решил не вбивать сразу всё количество длин, а как раз-таки разбить на несколько таблиц варианты по длинам решётки. Выбрал разбивку на 8 таблиц. Получились таблицы по 600 строк, восьмая на 650. На тот момент не было уверенности, что это будет работать прям быстро, как хотелось бы.
Загрузил все восемь таблиц, написал формулу для подставки имени таблицы, из которой семейство вытянет данные. Можно было бы генерировать её в Экселе, но мне что-то стало неохота, пусть занятие такое себе.
if(L < 751, "ЛРЩ 150-750",
if(L < 1351, "ЛРЩ 751-1350",
if(L < 1951, "ЛРЩ 1351-1950",
if(L < 2551, "ЛРЩ 1951-2550",
if(L < 3151, "ЛРЩ 2551-3150",
if(L < 3751, "ЛРЩ 3151-3750",
if(L < 4351, "ЛРЩ 3751-4350",
"ЛРЩ 4351-5000")))))))
В результате всё работает отлично! Семейство не мгновенно, но достаточно быстро меняется, так что результатом я доволен. В будущем буду ещё применять такую сильную разбивку на отдельные таблицы, пусть это и менее удобно с точки зрения управления данными. В теории можно в Экселе генерировать одну сплошную таблицу, а потом на других листах ссылаться на неё и выводить нужное количество строк, но ведь и Эксель не особо шустро работает, когда так много строк.
Второй момент — это условное обозначение. С щелевыми диффузорами всегда были вопросики, но вчера пришла идея, как показывать эти дурацкие треугольники. Делать один длиннющий — я такое делал, мне кажется, это не особо красивым. Делать несколько треугольников — ну ок, а как выбрать их количество, как много их надо и как этим управлять. Но потом...
Для массивов я вкладываю семейство патрубка. Потом он, соответственно, множится по количеству нужных мне точек входа в камеру. Идея простая — вложить треугольник в патрубок. Где не надо, оно будет скрываться, где надо — отображаться. Для плана сделал символическими линиями, для 3Д — линиями модели. И в итоге я не парюсь о том, как управлять количеством треугольников, всё происходит само. Дал пользователю возможность управлять размером треугольника и отступом и от диффузора и всё, отличное решение.
Запись эфира доны смогут посмотреть в ВК. Ну а те фишки, что не показал на эфире, рассказал здесь для всех.
Изменения следующие:
1. Ушёл от системы двух версий скриптов. Теперь версия одна, для Ревита 2019. В более новых версиях тоже будет работать, но с Ревита 2023 надо доставить один пакет в Динамо. В файлах библиотек есть инструкция, как это сделать.
2. Для воздуховодов изменил алгоритм поиска точек разрыва, теперь должно работать лучше.
Это вообще какая-то дурацкая магия. В одной модели запускаешь — всё режется идеально. Запускаешь в другой или в другой версии Ревита — выдаёт ошибку. Тот же алгоритм, всё то же, ан нет, ошибки.
3. Добавил для воздуховодов улучшенную проверку длины. Теперь не должно быть ситуации, когда длина воздуховода чуть больше той, на которую надо делить, но при этом недостаточно большая, чтобы разделиться. Такое вполне возможно, если длина деления 1250, а фактическая длина воздуховода в модели 1251 мм, например. Теперь такие воздуховоды не должны обрабатываться. Это довольно редкая ситуация, на тестах она не возникала, поэтому пропустил момент.
4. Добавил и для воздуховодов и для труб очистку данных из Экселя. В Динамо есть косяк: если пользователь удаляет данные в Экселе просто очисткой ячеек, а не удалением строк, то в скрипт могут прилетать нуллы. Когда остальные ноды пытаются их обработать, то получают ошибку, так как это и есть по сути ошибки импорта данных. Пришлось самому чистить, так как доверять Динамо нельзя.
Это прямо вообще не особо популярные библиотеки, поэтому вкладываться в них не вижу смысла. Но то немногое количество клиентов, что есть, несколько раз обращались с вопросами, в итоге решил внести правки, чтобы они работали комфортнее, а я не отвлекался на корректировки. Когда я их создавал, думал, что они станут пушка-бомбой, особенно в ИЖС, где неплохо бы делить трубы канализации на куски. Ну а в вентиляции тоже такой запрос несколько раз видел, вероятно, увидел запрос от всех людей, кому это реально было нужно.
Но я не плачу, я держусь.
Кто покупал ранее — скачивайте в личном кабинете обновление.
Скрипт для деления труб: https://muratovbim.pro/product/skripty-dynamo-delenie-truboprovodov-na-otrezki/
Скрипт для деления воздуховодов: https://muratovbim.pro/product/dynamo-delenie-vozduhovodov-na-otrezki/
Статья о разработке: https://muratovbim.pro/blog/dynamo-biblioteka-razdelenie_truboprovodov_i_vozdukhovodov_na_otrezki/
Please open Telegram to view this post
VIEW IN TELEGRAM
Блог Вадима Муратова
Скрипты Dynamo: деление трубопроводов на отрезки — Блог Вадима Муратова
Скрипт Dynamo, который поделит трубы на отрезки заданной длины. Длину вы задаёте сами в файле Экселя. Таким образом можно реализовать любую логику деления труб, а также при желании расставить опоры, если готовы к тому, что они будут разрывать трубы в месте…
Взгляните, какую красоту делают на моих семействах креплений для трубопроводов.
Ссылка в магазин: https://muratovbim.pro/product/biblioteka-krepleniya-dlya-truboprovodov/
Единственное, что тут можно улучшить — использовать ещё больше моих семейств🙂
Ссылка в магазин: https://muratovbim.pro/product/biblioteka-krepleniya-dlya-truboprovodov/
Единственное, что тут можно улучшить — использовать ещё больше моих семейств
Please open Telegram to view this post
VIEW IN TELEGRAM
ЗАВТРА ПРЯМОЙ ЭФИР ПО ШАБЛОНАМ
6 марта в 19:00 МСК проведу очередной прямой эфир.
Решил, что нужно добить обозначения. Уровни и оси сделали на прошлом стриме, теперь надо сделать разрезы и фрагменты планов. Речь про вот эти вот стрелочки и кружочки, а не сами виды.
И вот уже после этого будем настраивать виды, фильтры, шаблоны видов.
Если чувствуете, что плаваете в теме фильтров видов, а это важно для работы, то попробуйте мой мини-курс на Степике, можно оплатить в том числе зарубежными картами. С Украины платежи тоже проходят.
А что же с курсом по созданию шаблона? Рассказываю.
Я думаю сделать его модульным. До сих пор я работал над «фоновыми» элементами шаблона: всякие линии, настройки полутонов, размеры и высотные отметки, тексты, уровни и оси, дальше добавятся ещё разрезы и фрагменты плана. Пять с лишним часов видео про такие важные, но всё же второстепенные элементы. Ну, кроме разрезов, их вы видите часто при работе, а всё остальное — такие вот фоновые настройки, с ними редко взаимодействуют. Поэтому первый модуль будет как раз про вот это вот всё.
Дальше уже будут модули про работы с видами, с семействами, автоматизация и так далее.
И выпускать все эти модули я хочу не где-то на Степике, не выкладывать файлы на сайте, я хочу сделать свою видеошколу. Работы над этим уже ведутся. Будет у меня свой Степик, пусть попроще, пусть более колхозный, зато свой. И вот там уже буду выкладывать свои курсы и видеоуроки.
Поэтому мне нужно решить сначала технические вопросы с видеошколой, потом всё оформить на сайте. И вот тогда здравствуйте, добро пожаловать. Очень надеюсь, что всё получится, но это требует времени.
6 марта в 19:00 МСК проведу очередной прямой эфир.
Решил, что нужно добить обозначения. Уровни и оси сделали на прошлом стриме, теперь надо сделать разрезы и фрагменты планов. Речь про вот эти вот стрелочки и кружочки, а не сами виды.
И вот уже после этого будем настраивать виды, фильтры, шаблоны видов.
Если чувствуете, что плаваете в теме фильтров видов, а это важно для работы, то попробуйте мой мини-курс на Степике, можно оплатить в том числе зарубежными картами. С Украины платежи тоже проходят.
А что же с курсом по созданию шаблона? Рассказываю.
Я думаю сделать его модульным. До сих пор я работал над «фоновыми» элементами шаблона: всякие линии, настройки полутонов, размеры и высотные отметки, тексты, уровни и оси, дальше добавятся ещё разрезы и фрагменты плана. Пять с лишним часов видео про такие важные, но всё же второстепенные элементы. Ну, кроме разрезов, их вы видите часто при работе, а всё остальное — такие вот фоновые настройки, с ними редко взаимодействуют. Поэтому первый модуль будет как раз про вот это вот всё.
Дальше уже будут модули про работы с видами, с семействами, автоматизация и так далее.
И выпускать все эти модули я хочу не где-то на Степике, не выкладывать файлы на сайте, я хочу сделать свою видеошколу. Работы над этим уже ведутся. Будет у меня свой Степик, пусть попроще, пусть более колхозный, зато свой. И вот там уже буду выкладывать свои курсы и видеоуроки.
Поэтому мне нужно решить сначала технические вопросы с видеошколой, потом всё оформить на сайте. И вот тогда здравствуйте, добро пожаловать. Очень надеюсь, что всё получится, но это требует времени.