Перед тем, как рассматривать геометрию, необходимо дать понятие, что же есть объекты и как с ними работать. Частично я это затронул в 2-3 части, а теперь остановимся более конкретно.
Начало и части "после" смотри по ссылкам ниже:
«Renga API & Dynamo Core. Часть 1 - понятие документа, пакетные операции экспорта в IFC и вывод чертежей».
«Renga API & Dynamo Core. Часть 2 - интерфейсы, константы, свойства, чтение свойств; выборка объектов модели и их свойства».
«Renga API & Dynamo Core. Часть 3 - создание новых свойств, присвоение объектам, транзакции».
Дальше:
«Renga API & Dynamo Core. Часть 5 - геометрия объектов, общие выводы»
1. Внутренняя организация кода (и dynamo-пакета нодов)
Сперва небольшое отступление*
1.1 Древовидная структура нодов
Также, пока всё не ушло далеко, я хочу перестроить структуру классов и методов в пакете, чтобы сделать её более читаемой и понятной пользователю. В качестве "идеала", куда стремиться я обратился к dynamo-пакету Civil3DToolkit.
Дерево вложенных методов реализуется не за счет вложенных классов, как было бы логично, а за счет папок в составе Проекта (*.csproj).
1.2 Описание всех нодов
Любая библиотека классов может содержать xml-файл описания её методов (для .NET). Для C++ за это вроде выступают заголовочные файлы (*.h), но не уверен, да и не важно -- суть в том, чтобы описывать, что делает каждый метод и какие параметры на вход он принимает - для себя и пользователей.
1.3 Хранение внешних зависимостей
Как я уже говорил в части 1 - данная библиотека классов (являющаяся по факту "обёрткой" над Renga API имеет в качестве внешней зависимости COM-библиотеку (которая пока не распространяется в составе пакета) и .NET-библиотеку Renga.NET.PluginUtility.dll (тут содержатся константы), которая уже идет в составе пакета.
2. Виды в Renga и Объекты модели на них. Визуальные стили отображения
Если в части 2 мы коснулись объектов лишь касательно, теперь сделаем это более основательно, но начнем мы с ... обозревателя проекта - понятия "вида".
3D-пространство, где мы видим модель, это лишь одно из 12, ну, ладно, 11 (не считая "неопределенного") пространств, каждое из которых имеет свой целочисленный ViewType (да, да -- очередной Enum).
Вид - это интерфейс IView, который хранит свой идентификатор (уже guid) и тот ViewType. В то же время, есть особый интерфейс, потомок IView, который работает только с объектами Renga, видимыми на данном виде - это IModelView.
Сложновато, согласен.
Список методов и свойств для IModelView представлен здесь.
К сожалению, управляться видимостью объектов на фасадах и разрезах нельзя :(, как и выбирать там объекты в принципе.
Зато на планах можно - вот мы меняем стиль отображения на цветной:
3. О параметре ICamera3D
Среди настроек, к которым есть API, можно отметить (довольно интересную, на мой взгляд), опцию ICamera3D (единственный метод от IView3DParams). Но бесполезную для Dynamo, поскольку "пройтись" по результатам выборки мы не сможем (только на одном).
Интересно да? Давайте посмотрим на реализацию.
ICamera3D существует как самостоятельный интерфейс, не зависимый от других, в то время как у него есть метод, который устанавливает положение камеры в нужном виде LookAt().
Для определения положения камеры нам потребуются уже внутренние классы для представления геометрии, то есть с данной части получится как раз плавный переход на часть 5 - посвященную геометрии объектов в Renga.
Но ... понять как идентифицировать эту камеру у меня тоже не вышло ... оставил обратную связь поддержке, потом также допишу как ответят.
4. Уровни и объекты на них
В Renga существует также понятие "Уровень", в качестве объекта ILevel у них есть 3 свойства - высота, наименование и ориентация в пространстве (Plcament3D - из числа "продвинутых" элементов геометрии).
Уровни существуют как объекты модели -- выбираются по типу
Если в пространстве модели у нас был набор объектов IModelObjectCollection в составе отдельных IModelObject, то для уровня так же есть так называемый "Объект уровня" -- ILevelObject.
Явно, он не вырождается ниоткуда, но благодаря COM-интерфейсу, мы можем этот объект получить как IModelInfo!
То есть ввести явное преобразование типа (COM QueryInterface):
ILevelObject obj = com_IModelObject as ILevelObject;
И фактически, мы получим объект уровня :)
На оранжевую группу уже ушло больше времени, конечно .. все таки началась геометрия и её определение.
Возможности сведения объекта модели к объекту уровня может позволить нам фильтровать объекты в модели не только по типу но и по уровню! Для этого я написал отдельный метод в классе Selection "GetObjectsByLevel". Его логика такова, что в процессе перебора всех объектов модели, каждый объект представляется как "объект уровня" ILevelObject, у него берется свойство LevelId и сравнивается с идентификатором нужного уровня (id), причем уровень вступает тоже как объект модели - IModelInfo (сам по себе уровень как объект ILevel не имеет идентификатора).
5. IEnityCollection и IEnity
Стоит ещё упомянуть про ещё один тип объектов и коллекции объектов в модели - это упомянутые в заголовке интерфейсы.
Entity is the root interface for other entity-specific interfaces such as IPropertyContainer, IParameterContainer, IModel (как гласит справка)
Пока, честно, не совсем понимаю зачем они и где они встретятся явно ... пока ничего про них не говорю - не розобрался.
6. Завершаем часть
Итак, данная часть стала, наконец последней "рубежной" чертой, отделяющей нас от перехода к геометрии Renga (тем более, что часть объектов мы уже затронули в части получения базисных векторов ориентации уровня в модели).
В общем -- в статье мы рассмотрели понятия уровня, объект уровня и объект модели, возможность выборки объектов по уровню. Также мы посмотрели на возможность скрытия отдельных категорий объектов (и просто объектов) на 2D виде (плане) и 3D-виде. Также для отдельных объектов можно менять стиль отображения
Не пропускайте публикации, подписывайтесь на Telegram-канал с тизерами статей.
#dynamo core #renga #renga api #rengabim #dynamo
