Alexandr Popov
Ответы в темах
-
АвторСообщения
-
Итак, к чему я пришел. Все эти поверхности можно выгрузить в xml следующим образом:
Затем я открываю этот файл и сохраняю в формате екселя (более стабильная база данных получается. Dynamo и xml прочитал, но выстроил по мне не понятной структуре (строки/столбцы)
На 7 помещений получилось 2300 строк информации
Затем запускаю скрипт в динамо, который производит требуемые вычисления и выводит информацию в ексель в нужном для наших расчетов виде.
Расчет конечно надо ещё подпилить, чтобы нулевые значения не выводил, но это мелочи, действительно проблема, что он на реальной задаче не отрабатывает.
Если кому интересно “пощупать” скинул все файлы сюда
Ещё нюансик если вы лишний раз сделаете UnwrapElement (или например помещение анврапните) то получите вот такую ошибку:
IronPython.Runtime.Types.ReflectedIndexer или #indexer
Вобщем запомните что надо в таком случае убрать лишний анврап.
И ещё частая ошибка
IronPython.Runtime.Types.BuiltInFunction
Это означает что вы в конце функции скобочки не поставили, н-р: GetTypes(), Geometry() и т.п.
Надо же а волтайпбайнейм и не заметил. Ну вот благодаря данной подсказке закончил скрипт по площадям наружных стен у помещений. Еще раз благодарю!
Ок, можно обсудить. Я предполагаю, что в ближайшее время Алексей Лобанов поделится своими наработками, он дальше моего ушел, демонстрировал на вебинаре по динамо. Но можно конечно и мой скрипт развивать.
- Я в настоящий момент создаю потолки перекрытиями автоматически по параметру в помещениях “Высота потолка”. К данному параметру соответственно и привязываю расчет площади стен. Можно и предложенным вариантом сделать (предлагаете добавить в скрипт?)
- думаю в пределах погрешности норм
- У окон по-моему точка вставки на уровне пола, не могу представить как она в перекрытии может оказаться. Но то, что окно к нижнему помещению отнесется это да. Было дело долго на эту тему думал, методику расчета придумывал, потом плюнул на 1% помещений проекта решил доп параметром учесть, вручную внести где добавить а где вычесть.
- Проблему не вычитания витражей из стен решил довольно просто, создал прозрачные панели в категории Окна (а не в Панели витража, как по умолчанию). Промежуточные панели решил вручную учитывать пока. Но методика частично уже была разработана. Столкнулся с такой проблемой, что чем сложнее вычисления, тем они нестабильнее работают и на одной срабатывают, а на другой косячат. Пока оставил это, предполагая, что на торцах стен и перекрытий должны быть импосты и панели на несколько помещений – это ошибка.
- Довольно просто подправить скрипт, чтобы не учитывал, всё руки не доходят. Когда срочно кому-то надо было учесть такой случай, предложил им добавить параметры “Вычесть площадь стены” и “Прибавить площадь стены”. Понимаю, что ручная работа, но всё же не больше 5% помещений с такой ручной настройкой. В одном объекте например у нас границу помещения рисовали перед витражной системой наружной стены, т.е. в этом случае мы в минус по всему бы объекту ушли по отделке. А так в запас пока идет)) Но конечно надо исправить и подчеркну, что возможность искусственной корректировки должна быть и всё в любом случае надо просматривать.
По поводу идей как можно с геометриями играться и пересечениями, я скрипт давненько выкладывал Теплотехнический расчет, там вот я пытался через Geometry много чего насчитать.
Ну и раз оживили тему, то вот свеженький пример дальнейшей автоматизации
И тестовый вариант доработки, для помещений с точками в номере (например 3.1.2) (пока не обкатал, не уверен в стабильности)
Спасибо всем! И чтобы продемонстрировать, что Ваша помощь не напрасна, скидываю скрипт где мне это пригодилось. Уверен, что будет ещё масса мест, где такое решение понадобится.
Дмитрий, писал тебе в скайп, напишу и сюда свое мнение, чтобы люди тоже могли увидеть и обсудить.
Автодеск может без труда купить и Лобанова и его Dyno, вопрос в цене. И если захочет то прикроет, как он делал с десятками программ гораздо большего уровня сложности, с командами в сотни программистов.
А для того чтобы разрабатывать отечественный софт нужны финансовые вливания как минимум на 5 лет, пока софт не прибыльный и не достигнет уровня ревита. Да ещё и платить команде разработчиков надо будет больше чем платит автодеск своим, т.к. иначе опять лучшие туда уедут, а тут останутся программировать “не лучшие”, и эти “не лучшие” будут пытаться сделать что-то круче “лучших”.
Хорошая программа может появиться только в крупной компании, где происходят крупные выделения денег на неё, и что самое главное, где должности распределяются не по знакомствам и связям, а по знаниям и эффективности людей. У нас же если где миллиарды, то тут же свои люди, свои компании, которые пилят, субподрядчики на субподрядчиках, начальники с з/п по ляму на начальниках, а в итоге делают студенты за 2 копейки и в короткие сроки (т.к. распил долго происходил).
-
АвторСообщения