Вставка окна или двери в геометрию стены.
- В этой теме 15 ответов, 7 участников, последнее обновление 6 лет, 1 месяц назад сделано
.
-
Сообщения
-
Коллеги, здравствуйте. Только начал разбираться с динамо и сразу возник вопрос на который не смог найти ответа просмотрев кучу видео.
Вопрос в следующем. Какими базовыми нодами динамо можно вставить семейство окна или двери по заданным координатам?
У меня есть стена, я указываю точку для вставки семейства и могу разместить там любое семейство, за исключением тех, у которых есть основа. То есть дверь, проем, окно, я не могу разместить. Подскажите как быть?
Если тема была, прошу дать ссылку на решение. Спасибо.
Коллеги, аналогичный вопрос. Хелп!
Хотелось бы спросить, для чего вообще нужна вставка двери/окна по таким координатам? Действительно ведь, они от стены неотъемлемы. Как один из вариантов, можно вставить стену по тем координатам (а потом в нее посадить двери/окна) и если не нужна – скрыть для просмотра.
Вставляется как обычное семейство.
1. Без хоста по точке NewFamilyInstance Method (XYZ, FamilySymbol, StructuralType)
2. С хостом (стеной) NewFamilyInstance Method (XYZ, FamilySymbol, Element, StructuralType)
3. Почитать подобный скрипт можно тут http://spiderinnet.typepad.com/blog/2013/05/in-revit-net-api-2013-though-the-newwall-method-has-been-moved-to-the-wall-class-itself-the-familyinstance-generation-meth.html
они от стены неотъемлемы
Не совсем так. Можно создать семейство без хоста и назначить ему категорию “Двери”. Будет StandAlone дверь. Почему бы и нет? и вставляйте её хоть посреди комнаты
Конкретно в моём случае. Есть куча моделей, пришедших в Ревит через IFC. Стены, перекрытия передались нормально. Двери/окна и проёмы, лестницы, увы, передались обобщёнными моделями. Максимум что удалось сделать – это присвоить им соответствующие категории. Но, так как дальше нам предстоит расчёт отделки, а следовательно (в случае с дверями/окнами) просчёт откосов, то такая ситуация нас не устраивает. Также в целом раздражает, что для каждой двери/окна/лестницы создался свой типоразмер (хотя их по факту всего ничего). Помимо этого у всех у них привязка к уровню 0, а не к реальному, на котором они находятся. А есть экземпляры вообще без привязки (так называемый, -1). По сему стоит задача (на первый взгляд простая), опишу только по дверям:
а) считать данные (положение/направление, тип, прочие атрибуты) с имеющихся псевдо-дверей;
б) по созданной заранее таблице сопоставления типоразмеров разместить в тех же точках и с теми же направлениями корректные двери, наполненные унаследованными атрибутами;
в) удалить псевдо-двери.
При этом. Про дверь без хоста. Так как при расчёте физических объёмов работ, нам важно знать сколько и каких дверей в конкретной стене, важно получать объёмы и площади по стене за вычетом дверных проёмов, насколько правомерно применение подхода “без хоста”?
Приведенные методы попробую. Отпишусь
Я занимался c дверями в IFC. Скажу сразу. Дело это очень тяжелое. Для автозамены на двери простыми скриптами не обойдешься. Я парсил файл, брал оттуда координаты и …. Забил на все поскольку моих любительских познаний мало, для полноценного программирования таких задач.
Однако, нашел программу, которая гораздо лучше, чем стандартный импортер, импортит ИФЦ в Ревит. Предлагаю воспользоваться. Возможно, поможет. Кстати, даже не Архикадовские ИФЦ лучше распознает. Пробовал на ИФЦ из НоваКада и каких-то ещё… Работает норм. Если скрипт не поможет, то все… задача “глына”.
http://www.graphisoft.ru/downloads/interoperability.htmlПо дверям и окнам задачу свою (локальную) решил.
Через FamilyInstance.SetType меняю текущую “дверь неправильно типоразмера” на “нужного типоразмера”.
Попытка вставки дверей через FamilyInstance.ByCoordinates не задалась. Пока не задалась. Словил два эффекта: либо Dynamo повисает, либо вставляет двери, но не в те координаты, что задавал (какие-то на бум координаты у дверей оказываются). Плюс вставленные двери в проекте они не видны и выбираются только через команду на семействе “Выбрать все экземпляры”. Хотя, предполагаю, что это дело в стадии и виде, в котором указана конкретная стадия.
Аналога NewFamilyInstance Method (XYZ, FamilySymbol, Element, StructuralType) в динамовских нодах не нашёл. Что странно. Может плохо искал?
А можно автоматически из стены вырезать обобщенную модель (полостную форму). В контексте заданий на отверстия.
Привет товарищи!! Никак не пойму что не так???
вот скрипт:
def U(elem): # короткая функция, чтобы каждый раз не писать UnwrapElement(), вместо этого достаточно U()
a = UnwrapElement(elem)
return apoints = U(IN[3])
elemTypeSymbol = U(IN[1])
wallTypeHost = U(IN[2])
Struct = StructuralType
lvl = U(IN[4])elementlist=[]
TransactionManager.Instance.EnsureInTransaction(doc)
for point in points:
newobj = doc.Create.NewFamilyInstance(point.ToXyz(),elemTypeSymbol,lvl,StructuralType.NonStructural)
elementlist.append(newobj.ToDSType(False))
TransactionManager.Instance.TransactionTaskDone()OUT=elementlist
Подскажите пожалуйста….
Ром, Анврапаете не правильно.
Мне уже надоело писать на форуме людям про анврап…. Посмотрите ноды ClockWork – там анврап классно реализован. Если не найдете – скину скрипта что с Unwrap не так, вы имеете ввиду в цикл его вставить? Скиньте хотя бы ссылку, а то не понятно.
Совершенно верно. UnwrapElement(element)
ЭЛЕМЕНТ! а не список целиком.
Если список одноуровневый – поможет цикл. А если список содержит вложенные списки?
А если “список” вовсе не список, а одиночный элемент?
Мы циклом опять влетим в “список” и выбьет ошибку.
Вывод: лучше всего организовать рекурсивную обработку списка.
Код обработки любого списка я взял из нодов Clockwork и выглядит он таким образом:
https://pastebin.com/WKhzcZRF
- Для ответа в этой теме необходимо авторизоваться.