Ограничение процессов Dynamo
- В этой теме 9 ответов, 3 участника, последнее обновление 6 лет назад сделано
.
-
Сообщения
-
Кто сталкивался с такой проблемой, когда Dynamo необходимо обработать большой массив данных, то программа просто зависает на процессе обработки? То есть сама программа чем-то вроде как занимается, но результата можно ждать вечно – его не будет.
В “диспетчере задач” Я вижу сначала то, как Dynamo занимает всю оперативную память, а потом будь-то бы срабатывает какая-то защита и оперативная память под процесс Dynamo не превышает 1 гб (1024 мб). Причём даже если наивысший приоритет процессу задать.
Понятно, что скорее всего не хватает оперативной памяти, её всего 8 гб на борту, учитывая, что 2 гб забирает себе винда.
Печально, если Dynamo так плохо работает с оперативной памятью. Потому что я ожидал, что программа может и бо’льшие массивы данных обрабатывать, не запинаясь в процессе.
Чуть позже скину файл примера. Просто сейчас нет возможности. Может быть я просто что-то не так сделал, не оптимизировал так, как это необходимо.Динамо таки плох для обработки больших массивов данных. Постоянно приходится думать об оптимизации алгоритмов и облегчении способов фильрации. Особенно плохо Ревит (а не динамо) работает с большим количеством транзакций.
Вывод: если надо что-то действительно серьезное – ситуацию немножко ускорит python for revit, revitpythonshell, или любая другая консоль Питона. Существенное улучшение в производительности добавит только C#
В данном случае я использую DynamoSandbox. То есть без связки с ревитом.
Таким образом, я полагаю, тут безвыходная ситуацияТак как пример скинуть не могу ближайшее время, то дам ссылку на мою предыдущую тему, где очень хорошо описывается моя задача:
ИваСерж, А Вам спасибо, что в той теме дали решение тогда решение, которое впоследствии я внедрил и оно заработало. Просто я с очень большими перерывами возвращаюсь к этому проекту.
Обидно будет, если вся работа в динамо насмарку. Придётся тогда пробовать Grasshopper для отрисовки геометрии. Может быть там с этой проблемой дела обстоят лучше. И потом уже думать как эту геометрию переносить в ревит, если до этого дойдёт.
Если речь идет о скрипте из прошлой темы, то я сразу видел проблемы с оптимизацией.
Самое простое решение – отказаться от построения “красивой” геометрии в Динамо. Т.е. Динамо тратит очень большую часть памяти на просчет и рендер графики. От этой фигни можно уйти и пользоваться для отрисовки не нодом Line.ByStartPointEndPoint, а методами РевитАПИ для построения линий непосредственно в Ревите. Как ни странно, Ревит геометрию построит быстрее, чем с той же задачей справится Динамо.
Если готовы заниматься таким, то займемся прорисовкой линий через АПИ плотнее – там свои нюансы. Для построения линии модели помимо двух точек Ревит хочет ещё и плоскость, но это другая тема….Для большой модели, там где полигонов в мэше не 16, как в примере прошлой темы, а за несколько тысяч, я использую облегчённую версию скрипта. Там он не строит нижнюю сетку вообще. Таким образом, я рассчитывал сильно снизить нагрузку на программу. Она, конечно, не делает всё идеально, но то я уже ручками могу дорисовать в том же AutoCad (хотя и отвратительно это признавать).
Я бы с радостью отказался от рендера в самом динамо. Он мне нафиг не нужен. На данном этапе мне достаточно просто сохранить итоговую геометрию в sat файл.
Но всё же, мне кажется, дело не в отображении геометрии. Ведь когда я испытывал геометрию, которая считалась на моём компе минут 15, то после прорисовки я её спокойно вращал во вьюпорте. То есть, как я думаю, проблем с отображением геометрии нет, если я её могу поворачивать без тормозов. Но может быть я что-то не понимаю…Вот пример облегчённого скрипта.
https://ru.files.fm/u/3hjjf6pn
В архиве: скрипт dyn, dxf-файл с полигонами, sat-файл куда идёт сохранение5000 полигонов у меня строило. Но в этот раз, видимо, больше. Нужно глянуть…
Но всё же, мне кажется, дело не в отображении геометрии.
К сожалению, большая растрата памяти на прорисовку геометрии – это не мои догадки, а официальное заявление от создателей.
Вот статья на эту тему
https://github.com/DynamoDS/Dynamo/wiki/Efficiently-Working-With-Large-Data-Sets-In-DynamoGeometry nodes in Dynamo are always tessellated*. This leaves you with two options to work with untessellated geometry: Python nodes and ZeroTouch nodes. As long as you don’t return a geometry object out of your Python or ZeroTouch node, the geometry will not be tessellated.
Т.е. однозначно и безапелационно, для ускорения скрипта надо отказаться использовать нод Line.ByStartPointEndPoint и использовать методы АПИ.
// В архиве: скрипт dyn, dxf-файл с полигонами, sat-файл куда идёт сохранение 5000 полигонов у меня строило. //
Я глянул из любопытства. Из твоих 5000 полигонов расположенных по криволинейной поверхности далее строится около 45 000 отрезков (их даже сложно выделить в автокаде, он тормозит и более 20 000 тысяч за раз выделять отказывается). Не удивительно, что динамо считает несколько минут.
У меня вопрос – что это? зачем это нужно?
По поводу оптимизации – писать нужно на языке программирования (т.к. ноды и библиотеки динамо могут тормозить) и желательно не использовать движок динамо, искать другие, тут все зависит для чего это нужно.Это дипломная работа в университет. Параметрическая архитектура на примере пространственно-стержневых систем.
Я уже переболел всей этой параметрической болезнью, но тему уже не изменить.
Что-то типа этого:
Понял.
Ну с апи ревита я ещё вплотную не работал. Нужно почитать, для начала, что там и как…
Но думаю это уже вне дипломной работы. Потому что я всё-таки заставил обработать мою геометрию. Проблема была в том, что забыл слои почистить перед экспортом.)
- Для ответа в этой теме необходимо авторизоваться.