Revit: Почему моя стена BoundaryBox не совпадает с ее LocationCurve? - PullRequest
0 голосов
/ 30 апреля 2019

Используя Revit API, я разделил стену на 3 части. Для этого я создаю 3 строки:

Line.CreateBound(p1, p2)
Line.CreateBound(p2, p3)
Line.CreateBound(p3, p4)

Затем я создаю стену с каждой из этих линий, которые являются последовательными и выровненными. Результат не такой, как ожидалось, поскольку третья стена перекрывает вторую, см. Иллюстрацию ниже.

Overlapping wall

Теперь это может быть программной ошибкой, но я печатаю конечные точки линий непосредственно перед созданием 3 стен, и эти точки являются совершенно последовательными в правильном порядке. Печать выглядит следующим образом (я удаляю координаты Y и Z, они постоянны):

Now creating a new wall, from (11.811023622, ...) to (17.388451444, ...)
Now creating a new wall, from (17.388451444, ...) to (18.044619423, ...)
Now creating a new wall, from (18.044619423, ...) to (28.871391076, ...)

Если я затем использую надстройку RevitLookup для проверки этой проблемной стены, я вижу, что источник ее LocationCurve действительно находится по адресу (18.044619423, ...). Но если я посмотрю на свойства BoundingBox Min и Max , я вижу, что он начинается с 17.388 .. и поднимается до +28,871391076. Это то, что показано на иллюстрации ..

Кроме того, я использую этот метод расщепления на некоторых других стенах в моей геометрии, для которых у меня нет проблем, и я получаю 3 красиво последовательные стены!

Поэтому мой вопрос таков: пропускаю ли я где-нибудь свойство, которое каким-то образом «сдвигает» стену BoundingBox с ее кривой местоположения? Что бы это как-то объяснить? Как еще я могу объяснить и исправить это?

Спасибо большое! Arnaud.

Ответы [ 3 ]

1 голос
/ 07 мая 2019

Вы можете предотвратить объединение стены 3 со стеной 1, установив для свойства местоположения JoinType для обеих линий значение JoinType.None .

1 голос
/ 01 мая 2019

Может быть, Revit автоматически каким-то образом соединяет стены и изменяет их геометрию, чтобы хорошо их соединить. Представьте, например, две перпендикулярные стены вдоль осей X и Y, от (0,0) до (1,0) и (0,1), соответственно, с толщиной стенки 0,2. Revit соединит их. Для этого он вытянет их в углу, где они встречаются в начале координат. Из-за этого их ограничивающие рамки не заканчиваются в (0,0) (или в (0, -0,1) и (-0,1,0)), как вы могли ожидать. Вместо этого они оба будут иметь общий угол в (-0,1, -0,1). Таким образом, оба ограничивающих прямоугольника будут иметь максимальное расширение 1.1 вместо 1.0. Я надеюсь, что это объяснение понятно. На картинке было бы сказано более тысячи слов ... извините за глупую попытку использовать слова вместо этого.

0 голосов
/ 06 мая 2019

РЕДАКТИРОВАТЬ: с помощью функции WallUtils.DisallowWallJoinAtEnd добились цели!

Итак, это состояние после некоторого исследования: третья стена действительно автоматически расширяет свой BoundaryBox, так что она соединяется с первой стеной.И при этом она перекрывает небольшую стену (см. «Стену 2» на рисунке ниже - эта стена относится к другому типу , чем стены 1 и 3 (которые относятся к тому же типу), поэтому игнорируется, когда стена 3ищет место для соединения между ними (это было только 20 см в длину). Делая "Стена 2" немного длиннее (40 см), помогает и предотвращает автоматическое расширение 3-й стены до первой стены, что я и сделалздесь:

Walls not overlapping or auto-expanding

Тогда все в порядке. Но это не решает проблему . Я не видел никакого способапредотвращение «автоматического расширения» BoundingBox или любой другой способ управления максимальным расстоянием, на котором он ищет другую стену.

Я также попытался сначала наложить 3 различных типа, а затем изменить тип стены 3к тому же типу стены, что и у стены 1: когда их типы стен отличаются: без расширения. Когда я изменяю тип стены, она расширяется, даже если стена уже создана.

Наконец, действительно странное поведениечто для какой-то ваУ меня вообще нет этой проблемы.Это: 3 стены того же типа, что и у меня, когда есть проблема, с такой же длиной 20 см для стены 2. Это последнее, что действительно не объяснимо.

...