open design alliance что это
ТЕХНОЛОГИИ, ИНЖИНИРИНГ, ИННОВАЦИИ
Измеритель диаметра, измеритель эксцентриситета, автоматизация, ГИС, моделирование, разработка программного обеспечения и электроники, БИМ
Open Design Alliance и платформа разработки Teigha: итоги и перспективы
При этом ODA устранила зависимость пользователей от единственного поставщика продуктов и сопровождения.
Платформа разработки Teigha предлагает разработчикам САПР несколько отраслевых продуктов для различных дисциплин, включая архитектуру, гражданское строительство, проектирование изделий и техническую публикацию. (Источник: Open Design Alliance)
Основным продуктом ODA теперь является платформа разработки Teigha. Ее можно использовать в качестве основы для создания полновесной САПР. В последние годы ODA добавила поддержку чтения/записи для Autodesk Revit, поддержку 3D PDF, технологию рендеринга и многое другое.
Следующее поколение Teigha
В этом году ODA анонсировала три новых расширения библиотек разработки: Teigha Cloud, Teigha Visualize и Teigha Publish. Детали:
Teigha Cloud — это среда для разработки приложений САПР, которые исполняются в облаке и могут использоваться в браузере. Первоначально задуманная как инструмент просмотра, Teigha Cloud в ближайшие месяцы будет дополнена различными инструментами редактирования и поддержкой клиент-серверных приложений.
Teigha Visualize — это набор средств разработки программного обеспечения (SDK) для создания высокопроизводительных приложений для рендеринга, адаптированных для САПР и соответствующей технической графики. Некоторые расширения Teigha требуют отдельной лицензии, но Teigha Visualize входит в стандартное лицензионное соглашение. Выделение рендеринга из базовой технологии Teigha позволит производителям программного обеспечения использовать SDK при создании новых приложений для обработки всех видов визуальных инженерных данных, например, данных 2D и 3D моделирования и анализа. К концу года Teigha Visualize будет поддерживать многопоточную обработку метафайлов, что позволит выполнять быстрый рендеринг с использованием графического процессора.
Что дальше?
Членами ODA являются более 1200 поставщиков программного обеспечения, компаний, использующих САПР, и учебных заведений. Петерсон отметил рост членства в организации, поскольку возвращаются бывшие члены альянса, которые ушли по той или иной причине. «Мы годами не повышали цены, — сказал Петерсон. — Мы предлагаем больше технологий и возможностей, чем когда-либо прежде, по той же цене для наших членов». ODA принадлежит ее участникам и не публикует конкретных сведений о доходах или расходах. Но Петерсон признался, что увеличение доходов от платы за лицензии и членство позволило ODA расширить штат до 75 программистов и взяться за реализацию новых задач.
Elysium CADdoctor — один из сотен программных продуктов, которые используют платформу разработки Teigha от Open Design Alliance. (Источник: Элизиум)
Автор: Рэндолл С. Ньютон является ответственным редактором GraphicSpeak. Более 25 лет пишет об инженерных и конструкторских технологиях.
Понравилась статья? Тогда поддержите нас, поделитесь с друзьями и заглядывайте по рекламным ссылкам!
Open Design Alliance
Open Design Alliance (ODA) (До 2003 года — OpenDWG Alliance) — некоммерческое объединение (консорциум) компаний-производителей программного обеспечения. Open Design Alliance был создан с целью разработки программных библиотек, позволяющих читать и записывать файлы формата DWG. По мнению участников консорциума, это должно способствовать распространению формата DWG в качестве открытого стандарта обмена данными между различными САПР. Для достижения этой цели были разработаны спецификации Teigha, доступ к которым открыт всем желающим. ODA осуществляет поддержку Teigha в актуальном состоянии. Финансирование разработки программных библиотек производится на членские взносы участников консорциума.
Содержание
Программные библиотеки, разрабатываемые ODA
История Open Design Alliance
Предшественники
Из-за некоторых недостатков, присущих формату DXF, в конце 1980-х возникла потребность в средствах, способных читать и записывать файлы формата DWG. Для удовлетворения этой потребности ряд производителей, среди которых следует отметить Cimmetry Systems, Cyco, Kamel Software, MarComp, Sirlin и Softsources, осуществили обратную разработку формата файла DWG. В результате, эти компании выпустили различные программные утилиты, просмотровщики файлов и другие приложения к AutoCAD от Autodesk.
В период с 1990 по 1997 MarComp был ведущим разработчиком программных утилит, позволяющих получить доступ к файлам DWG. MarComp разрабатывал свою программную библиотеку, используя метод чёрного ящика (в роли чёрного ящика выступал файл DWG). Программная библиотека, разработанная MarComp называлась AUTODIRECT. К концу 1997 года библиотека AUTODIRECT поддерживала 8 версий файлов AutoCAD, начиная от DWG 2.5 и заканчивая DWG R14.
В январе 1998 года MarComp был поглощен компанией Visio Corporation (в настоящее время подразделение корпорации Microsoft).
Образование OpenDWG Alliance
Компания Visio Corporation решила сделать формат DWG открытым стандартом, позволяющим обмениваться данными между различными САПР без риска потери данных. С этой целью в феврале 1998 года Visio Corporation и еще несколько компаний создали консорциум OpenDWG Alliance — независимую некоммерческую организацию, целью которого являлось продвижение DWG, как открытого, общедоступного страндарта для хранения чертежных данных. Всем участникам OpenDWG Alliance были доступны утилиты OpenDWG ToolKit и OpenDWG ViewKit, разработанные на основе библиотек AUTODIRECT.
В 2002 году OpenDWG Alliance представил абсолютно новый набор программных библиотек — DWGdirect, написанный «с нуля» на объектно-ориентированном языке программирования С++.
В 2003 году OpenDWG Alliance изменил название на Open Design Alliance.
В 2008 году были разработаны программные библиотеки DGNDirect для поддержки формата DGN.
OpenDWG Сегодня
Open Design Alliance поддерживает и регулярно обновляет спецификацию Teigha, в соответствии с изменениями формата DWG. В Open Design Alliance состоит 32 участника-учредителя (Founding Members) и свыше 600 коммерческих (Commercial Members) и поддерживающих участников (Sustaining Members) (данные на начало 2008 года). В число коммерческих участников (Commercial Members) входит ПроПро Группа (bCAD). В число поддерживающих участников (Sustaining Members) входят, например, ведущие российские производители САПР, такие как: АСКОН (Компас), Топ Системы (T-FLEX CAD) и другие.
Участие в Open Design Alliance
Виды участия в ODA
Основные участники (Founding Members) имеют неограниченный доступ ко всем исходным кодам программных библиотек, разрабатываемых Open Design Alliance и могут внедрять библиотеки Open Design Alliance в свои коммерческие продукты. Основным участникам (Founding Members) предоставляется расширенная техническая поддержка Open Design Alliance. Кроме того, основные участники могут выдвигать своего представителя в совет директоров организации.
Поддерживающие участники (Sustaining Members) могут внедрять программные библиотеки, разрабатываемые Open Design Alliance, в свои коммерческие продукты и пользоваться технической поддержкой Open Design Alliance. Поддерживающим участникам (Sustaining Members) не предоставляется доступ к исходным кодам программных библиотек.
Коммерческие участники (Commercial Members) имеют право использовать программные библиотеки, разработанные Open Design Alliance, для своих внутренних программ, с ограничением на их распространение. Количество программных продуктов (разработанных с помощью библиотек Open Design Alliance), проданных или переданных сторонним организациям (пользователям) не должно превышать 100 единиц.
Ассоциированные участники (Associate Members) могут использовать библиотеки, разрабатываемые Open Design Alliance, исключительно для своих внутренних программ. Ассоциированные участники (Associate Members) не имеют права распространять библиотеки Open Design Alliance в составе какого-либо коммерческого приложения, или совместно с каким-либо другим коммерческим приложением.
Ассоциированное участие (Associate Membership) стоит 250$ за первый год, в дальнейшем, в случае продолжения сотрудничества в качестве ассоциированного участника (Associate Member), стоимость участия снижается до 100$ в год.
Основные участники (Founding Members) ODA
Open Design Alliance и Autodesk
Open Design Alliance продвигает формат DWG в качестве открытого стандарта для обмена данными между различными САПР. В то же время Autodesk не желает открывать спецификации формата DWG и предлагает использовать для обмена данными формат DXF. В качестве альтернативы DWGDirect компанией Autodesk была разработана программная библиотека RealDWG, которая лицензируется для приложений, не конкурирующих с продуктами Autodesk.
Осенью 2006-го года Open Design Alliance представил обновленные библиотеки DirectDWG, которые включали в себя и технологию TrustedDWG, в том числе служебное сообщение в командной строке: «Autodesk DWG. This file is a Trusted DWG last saved by an Autodesk application or Autodesk licensed application».
13 ноября 2006 года компания Autodesk подала судебный иск к организации Open Design Alliance. Как утверждалось в исковом заявлении, альянс нарушает авторские права Autodesk, используя торговую марку Autodesk и уверяя, будто AutoCAD 2007 и другие продукты Autodesk могут работать с DWG-файлами, создаваемыми в приложениях других разработчиков, как если бы они были созданы программным обеспечением Autodesk [2] [3]
В начале 2007 года Autodesk подала прошение в USPTO по поводу отмены торговой марки «OpenDWG», принадлежащей Open Design Alliance, заявляя, что она была заброшена. [5] Это прошение также было приостановлено в связи с иском компании Autodesk к компании SolidWorks через Американский окружной суд (US District Court). [6]
Teigha больше не существует
Мы надеемся опубликовать обзор состоявшейся 10-11 сентября в Праге конференции разработчиков Альянса по открытому проектированию (ODA), но уже сейчас по некоторым признакам видно, что ODA чувствует себя уверенно и намерен выйти на новый уровень влияния на рынок.
Ниже публикуется официальный пресс-релиз о ребрендинге Альянса. Термин «Teigha», который было трудно произносить не только Ральфу Грабовски (об этом он признался в твиттере), прекратил существование.
Ребрендинг – это заметно, это освежает компанию и её восприятие внешним миром. Свежий сайт Альянса, хотя и лаконичный, но оптимистичный, – тоже о чем-то говорит. При этом стоит обратить внимание на акцентированные на сайте возможности, которые ODA считает своими преимуществами.
Теперь ODA выносит на первый план вот что: «Построение полного CAD-приложения. Комбинация полного набора ODA-компонентов позволит быстро построить ваше следующее CAD-приложение». Полный набор? Возможно, Альянс планирует что-то существенное за пределами доступа, визуализации и публикации…
Изящно встроены в маркетинг бренды лидеров рынка: видимо, они – не партнёры, не пользователи, но они «доверяют Альянсу»:
Скоттдейл, Аризона, 18 сентября 2018. Альянс по открытому проектированию, разработчик средств интероперабельности, визуализации и других основополагающих технологий индустрии САПР, сегодня объявил, что до сих пор использовавшийся ODA-бренд «Teigha» изменён на бренд «Open Design Alliance».
«Название «Open Design Alliance» широко известно и весьма уважаемо в нашей индустрии, – говорит Нил Петерсон, президент ODA. – Это уместное название, оно ясно отражает нашу миссию и отношение к ней пользователей. С другой стороны, имя Teigha после восьми лет использования так не встретило должного отклика в нашем сообществе. Поэтому мы будем пользоваться уже всем известным брендом ODA».
Наше решение носит стратегический характер. Главная миссия ODA – разработка софтвера, нам нет смысла тратить деньги на продвижение нового бренда. В рамках принятых изменений мы обновили наш логотип и так адаптировали наш слоган, чтобы стала более понятной наша миссия – обеспечить равный доступ к основным форматам данных и к технологиям CAD».
Open design alliance что это
Click to learn more.»>
Click to learn more.»>
Click to learn more.»>
Click to learn more.»>
Click to learn more.»>
Click to learn more.»>
Click to learn more.»>
Click to learn more.»>
Click to learn more.»>
What’s the difference between the ODA Support levels?
Standard level includes using Documentation, Educational Portal, Technical Forum, reviewed by ODA development team, and Bug reporting.
Priority level provides all the features of Standard one and Direct support.
Can I subscribe to only one product?
No, ODA membership includes subscribing to a сore SDKs package: Drawings, IFC, Visualize, Open Cloud, Publish, Architecture.
Can I pay a subscription only once?
No, ODA SDKs licensed through an annual subscription model. In case of termination of the subscription you lose the right to distribute the ODA-based product, even if it was developed during the validity of the license.
Also all online resources become unavailable after termination of the subscription.
Can I use non-commercial membership at the time of development of my product?
Yes, but you cannot to commercialize your product.
Also SIG product subscriptions not available for non-commercial members.
Do you work with resellers?
ODA does not work with resellers – your customers will need to become an ODA member directly. Your company can pay for the membership, but your customers will need to sign the paperwork and become a member of ODA. We do not offer any reseller discounts, all members pay the same published prices that you can find on the Pricing page of our website.
For the billing address, put your information and company. For the membership, put your customer’s information and company.
Teigha for Architecture: First project
В данной статье я расскажу о библиотеке Teigha — альтернативе для работы с dwg файлами и объектами ACA. Мы напишем небольшой пример, который создает дом из ACA-объектов и сохраняет его в dwg файл. Затем, попробуем открыть этот файл в AutoCAD Architecture и проверить, совместимы ли эти файлы с оригинальным Автокадом.
Альтернатива AutoCAD и ObjectARX
В общем, «библиотека поддерживает много чего». Для начала попробуем загрузить и отрисовать какой-нибудь dwg чертеж используя стандартный сэмпл из комплекта поставки Teigha: 
Ок, dwg файл у нас прочитался и нарисовался. Впрочем, как и dwg файл, который я использовал для титульной картинки к статье.
Этот стандартный сэмпл представляет из себя оконное C++ приложение и позволяет загружать, просматривать и редактировать dwg файлы без Автокада. Еще одна важная особенность: API объектов Автокада и Teigha почти идентичны, поэтому можно легко переписать существующий ObjectARX плагин для работы с приложением, основанным на Teigha.
Большинство аналогов Автокада, такие как BricsCAD, ZWCad, IntelliCAD, используют Teigha для работы с dwg форматом и acad-объектами.
Особенности объектов AutoCAD Architecture
Теперь перейдем к архитектурным объектам и работе с ними. Для этого вкратце напомню основные моменты:
AutoCAD Architecture оперирует специальными высокоуровневыми объектами, разработанными для архитектурного проектирования: стенами, дверями, окнами, крышами и прочими конструкционными частями. Объекты viewport-dependent, т.е. они могут по-разному отрисовывать себя в зависимости от направления камеры. Объектам назначен стиль. Если изменить стиль, то изменятся все объекты этого стиля. Объекты состоят из компонентов, каждый из которых имеет свои визуальные настройки: цвет, тип линий, материал, масштаб (например, дверь в 3D состоит из рамы, полотна, стекла). Для разных вариантов отображения объект рисует разную геометрию, поэтому количество и настройки компонентов различны для разных представлений.
Библиотека Teigha for Architecture (TA)
Для работы с архитектурными объектами, кроме самого ACA и его открытого API для создания плагинов, можно использовать библиотеку Teigha for Architecture от Open Design Alliance.
TA — это библиотека С++ классов, в которой реализованы все основные примитивы ACA, такие как стены, окна, двери, крыши, балки, проемы и тд. Библиотека позволяет читать эти объекты из dwg форматов всех версий, записывать (конвертировать) в последнюю версию dwg; в библиотеке реализован рендеринг всех примитивов для различных представлений и конфигураций. Т.к. aca-объекты взаиподействуют друг с другом, в TA также реализованы вспомогательные классы и механизмы ACA — это anchor, display manager, property sets, relation graph и прочая обвязка.
Начинаем работать с TA API
Общих слов, на мой взгляд, уже более чем достаточно. Теперь посмотрим что физически из себя представляет Teigha и попробуем написать первую простую команду. Я буду использовать старую VS 2005, но библиотеки мультиплатформенны и в комплекте идет генератор солюшенов для студий вплоть до 2015. В зависимости от типа лицензии вам может быть доступен либо полный код всей библиотеки, либо построенные бинарники и заголовочные файлы.
Комплект TA-библиотек будет примерно таким: 
По сути это обычные виндовые dll (можно сбилдить и под другие платформы: ios, linux, unix и тд). Lib файлы к ним идут в отдельной папке. Кроме TA будут необходимы Teigha Core библиотеки, тк TA это расширение над Core-объектами. Core реализует основные механизмы и объекты обычного автокада.
Инициализация ТА
Для начальной инициализации библиотеки нам потребуется класс, который выполняет платформо-зависимые операции с файлами.
В комлекте уже есть готовые расширения под Windows: ExSystemServices и ExHostAppServices; В данном случае нам их будет достаточно.
Далее, инициализируем библиотеку и графическую подсистему
OdStaticRxObject добавляет объекту логику addRef \ Release; Библиотека сохраняет ссылку на объект MyServices и использует его для платформозависимых операций.
Инициализируем библиотеки ТА:
AecBase, AecArchBase и все остальные – это tx модули (т.е. dll библиотеки) c картинки выше. Они уже слинкованы с помощью lib файлов, но этого недостаточно. Необходимо инициализировать их как модули. Что это значит? В период выполнения в памяти существует словарь загруженных классов. Этот словарь используется для механизма кастов указателей между разными типами TA-объектов и для создания самих экземпляров TA-классов через централизованный механизм псевдо-конструкторов.
Например, при выполнении команды ::odrxDynamicLinker()->loadApp( OD_T(«AecArchBase») ) внутри фреймворка будет вызвана функция AECArchBase::initApp(). Схематично, initApp() зарегистрирует в глобальном словаре классы, которые реализованы в данной библиотеке, вызвав для каждого статическую функцию rxInit():
После этого заработает механизм создания объектов и можно будет создать, например, стену вызовом AECDbWallPtr pWall = AECDbWall::CreateAECObject(). В противном случае попытка создать объект TA-класса выкинет исключение.
Cоздаем пустую dwg базу вызовом
Это центральный объект, он представляет из себя объектную базу данных, которая сохраняется и загружается из dwg файла. В него мы будем добавлять все созданные архитектурные объекты. По завершении, мы сохраним эту базу в dwg файл вызовом
Далее, еще немного инициализируем загруженные библиотеки и display manager
В базе создается AEC-словарь с дефолтными настройками единиц измерения для длины, площади, объема, углов, настроек печати и регестрируются display representations реализованные в этих модулях. О display manager, display representations и связанных с этим механизмами я напишу отдельный пост.
На этом инициализация закончена. Если пропустить какие-то шаги, то результат может быть различен: либо у вас не будут создаваться объекты, либо они не будут отрисовываться (увидите пустой экран), либо получите еще какие-то глюки, в зависимости от того, какой шаг пропустили.
На данный момент полный код у нас выглядит вот так:
Я добавил команду zoom extents, чтобы при открытии созданного файла мы сразу видели объекты, которые туда добавили и симметричную деинициализацию библиотеки. Для упрощения я убрал проверку ошибок и конструкции try\catch вокруг основных действий.
Сейчас программа создаст пустой dwg файл, который можно открыть и поглядеть Автокадом.
Работа с объектами
Эта функция создает объект «стиль стены» AECDbWallStyle, выставляет ему некоторые настройки, а затем обращается к display manager и меняет цвета для plan display representation (2d вид сверху) и model display representation (3d view).
В данном случае мы установили желтый цвет для стены в 3д представлении. На вид выглядит сложновато, но тому есть причины: так работает механизм display representations и display manager в ACA. Он гибкий и имеет много возможностей, но его логика не сразу очевидна и нуждается в некотором изучении.
OdDbObjectId — ссылка времени выполнения
OdDbObjectId – это класс, с помощью которого объекты базы ссылаются друг на друга в период выполнения. Внутри он хранит указатель на реальный объект в памяти. Используя OdDbObjectId::openObject() можно получить указатель на объект с которым связан ObjectId. Смысл в том, что пока к объекту не обратились по этому id, он может быть не загружен в память и внутренний указатель OdDbObjectId может быть равен NULL. Когда мы специально обратились по этому id для чтения или записи, тогда фреймворк создаст экземпляр реального объекта и заполнит его поля данными из базы, а внутренний указатель OdDbObjectId получит адрес созданного объекта. openObject() возвращает этот указатель.
Такой механизм позволяет осуществлять частичную загрузку крупной базы (dwg файла). В этом случае OdDbObjectId будут существовать для каждого объекта, но реально созданы в памяти будут только те объекты, к которым явно обращаются.
Если нужно чтобы ссылка на объект сохранялась между запусками, то нужно использовать OdDbHandle.
Например, функция add_wall_style вернула нам idWallStyle. В данном случае стиль был только что явно создан вызовом AECDbWallStyle::CreateAECObject() и idWallStyle хранит внутри указатель на реальный объект в памяти. Чтобы получить доступ на запись к объекту-стилю надо выполнить операцию
openObject() вернет реальный указатель на объект и им можно будет пользоваться.
В библиотеке вместо обычных С++ указателей используются смартпоинтеры OdSmartPtr
Деструктор такого смартпоинтера оповещает фреймворк о закрытии объекта, что может вызвать пересчет связанных объектов, отправку оповещений и т.д.
Теперь добавляем стену вызовом:
Как видим, add_wall не делает ничего особого. Она создает объект AECDbWall со стилем, который мы создали немного раньше. Объект AECDbWall добавляется в model space базы – специальный словарь, в котором хранятся все объекты, которые отрисуются при рендеринге базы (это упрощение).
Далее, стене устанавливается начальная точка, конечная точка и кривизна. Т.е. стена может быть не только прямой, но и выпуклой.
Если все сделали верно, то у нас получится dwg файл с одной желтой прямоугольной стеной. В данном случае я просматриваю файл с помощью сэмпла из поставки Teigha, но в ACA он будет отрисован точно также. 
Правда я вручную развернул камеру в 3D представление. По умолчанию у вас будет вид сверху.
Теперь, попробуем добавить аж 4 стены, причем одну выпуклую:
Получили некий зачаток будущего домика: 
Как видим, стены не просто нарисовались отдельными объектами, а между ними автоматом построился плавный переход в точках контакта друг с другом. Это одна из автоматических функций TA, называется cleanup стен.
Добавление окон в чертеж
Теперь добавим в наш домик окна. С окнами логика аналогична дверям: необходимо создать стиль окон, которые мы хотим добавлять в чертеж, а потом добавить объекты-окна этого стиля.
Как видно из кода, создается объект AECDbWindowStyle и добавляется в базу. Далее, стилю выставляются некоторые настройки (хотя можно использовать и дефолтные), а затем переопределяются цвета нескольких компонентов для 2D и 3D представления. Компоненты в данном случае – это физические части окна: стекло, рама, створка.
Добавляем окно к первой стене функцией add_window:
Функция add_window() аналогична add_wall() с одним различием: тут используется объект anchor.
Мы создаем объект AECDbWindow и помещаем его в model space базы. Затем выставляем некоторые настройки этому конкретному экземпляру AECDbWindow.
После этого мы вставляем окно в стену. Стену и окно связывает особый объект производный от AECDbAnchorEntToCurve. Он содержит отступы вдоль осей x, y, z от начала координатной системы стены до начала координатной системы окна. При вызове AttachWallAnchor() создается экземпляр этого объекта и помещается в базу. Сама стена напрямую не знает вставлены ли в нее окна или нет. Создание анкора затрагивает другой базовый механизм – relation graph. Relation graph содержит взаимоотношения между объектами – кто к кому прикреплен, кто кому принадлежит, кто кем владеет. При модификации стены relation graph получит сообщение о том что объект AECDbWall изменился, пройдет по всем зависимостям и вызовет обновление связанных объектов (в данном случае AECDbWindow). Так, если мы подвинули стену, то окна подвинутся вместе с ней, потому что получат оповещение от relation graph-а. Можно получить доступ к этому графу и запросить зависимости для конкретного объекта. Окно, в принципе, знает к кому оно прикреплено, тк хранит в себе ссылку на созданный анкор.
Смотрим что вышло: 
Я специально изменил цвет стен, чтобы окно было лучше видно. В коде у вас сразу стены должны быть голубые, я просто подбирал цвета по ходу написания статьи.
В TA есть масса предопределенных стилей и типов окон, которые задаются через перечисления:
Мы выбрали AECDefs::ewtGlider и AECDefs::esRectangular, но, как видите, вариантов форм много. Используя и другие настройки можно создать очень сложный тип окна со внутренним рисунком на стеклах и многими створками. И все это не надо рисовать вручную или реализовывать программно, надо только выставить несколько настроек существующему объекту или стилю.
Вообще, все объекты TA сложны и имеют массу настроек. Это дает довольно широкие возможности прямо «из коробки».
Добавим окна во все прямые стены:
Я не стал дописывать код, но каждым окном можно управлять отдельно: изменить процент его открытия, цвета и тд. А если изменить их стиль, то это изменение отразиться на всех них разом.
Добавление дверей в чертеж
Для полноты картины добавим дверь. Для двери создадим 2D профиль для полотна (створка с дыркой-окошком), затем создать стиль с таким профилем, а потом мы сможем создавать объекты-двери этого стиля. Но можно использовать и дефолтные стили. Двери, как и окна ( и все другие проемы ) присоединяются к стенам с помощью анкора.
Здесь есть один новый момент: мы открываем на чтение стену и берем ее длину чтобы посчитать отступ.
В итоге у нас дверь вставилась в круглую стену: 
Вставим еще окона в круглую стену:
В результате у нас получился очень дырявый домик без крыши и пола: 
Добавление крыши в чертеж
Напишем функцию add_roof()
Крыша создается на основе двумерного профиля, направление обхода которого направлено против часовой стрелки. Вызов makeCCW() как раз преобразует направление обхода, если оно было противоположным. Это важно, тк алгоритм ждет на вход именно такой профиль и не сработает в противном случае.
Профиль у нас совпадает с центральной линией стен. Далее, для каждого отрезка профиля задается наклон ската крыши, количество фейсов которыми будет представлен скат, подъем начала ската по Z относительно плоскости OXY (SetFaceHeightByIndex), и свес крыши (overhang). SetSegmentCount() работает только для отрезков у которых есть кривизна. Эта величина задает точность аппроксимации – сколько прямых отрезков будет использовано чтобы аппроксимировать полукруглый сегмент.
Получилась такая крыша: 
Вариаций настройки крыш много и можно создать крышу почти любой формы – двускатные, многоскатные, шатровые и так далее. Каждый скат представляет из себя отдельный объект RoofSlab который можно редактировать вручную.
Добавление перекрытия в чертеж
Осталось добавить хотябы небольшую имитацию пола\фундамента. Для этого используем объект slab ( перекрытие ). Напишем функцию add_slab
В данном случае мы создаем новый стиль перекрытия и добавляем в него компоненты. Компонент представляет из себя кусок перекрытия и содержит такие параметры как толщина, подъем над OXY, имя, материал, индекс и пр. Перекрытие может содержать несколько компонетов, которые различаются по своим настройкам. Например, если у них разный отступ от OXY, то один объект-перекрытие такого стиля может отрисовать все полы и потолки в многоэтажном здании.
Настройки стиля применяются к конкретному объекту, который хранит форму данного перекрытия. В данном случае мы создаем slab, и инициализируем его профиль таким же контуром как низ стен, только с небольшим отступом по краям.
Далее идет работа с display manager чтобы переопределить цвета разных компонентов перекрытия.
В финале наш дом будет выглядить вот так: 
Для теста, попробуем загрузить получившийся dwg файл в Autodesk ACA: 
Вот наш дом, загруженный в Autocad Architecture. Выглядит еще лучше.