✒️ Хроники Георга

Пару недель назад на ресурсах Нанософт разместили мой небольшой вводный курс по начале разработки под nanoCAD BIM Строительство (там ссылки идут на Rutube). Его же версия на VK Video, и YouTube. Он записывался ещё в начале января и должен был выйти раньше записанного позже курса по платформе (2 поста выше), но ... вышло то, что вышло.

Кто-то может сказать, что в эпоху ИИ-агентов курсы по разработке под что-либо почти изжили сами себя, и он будет прав и может ничего не смотреть, "скармливать" ИИ документацию с примерами и делать приложения, которые просто работают, без оглядки на дальнейшую поддержку и оптимизацию. Т.к. аналогов не было, курс не затрагивает сложные механики, а преимущественно проходится по простым вещам и идёт в дополнение к документации к API продукта (которую я сам же и писал кстати), то есть это не озвучка текста справочника, это именно материал на базе его + материалов по платформе (и то, что этот курс выходит позже курса по API платформы, даже хорошо - есть на что сослаться и куда посмотреть при возникновении вопросов).

Краем глаза посматривал на развернувшуюся дискуссию относительно предоставления чего-то там в Белокаменной для АГР. И ехидно усмехался, ожидая, когда свет увидит новый ГОСТ подобного толка для дорог ("Дороги автомобильные общего пользования. Проекты организации дорожного движения. Общие технические требования") . Вот собственно его выложили (может он там даже был раньше, просто не было в поисковой выдаче) https://tk418.ru/standartization/disqus/?ELEMENT_ID=946 (см. его "Приложение В" сразу).

С оглядкой на то, что огромная масса "дорожных" проектов несмотря на BIM\ТИМ и т.д. продолжает рисоваться в DWG, то, как предполагается выгружать данные по требованиям этого стандарта будет выглядеть оооочень занятным. Немного с этой проблематикой пришлось столкнуться полтора года назад и то пришел в ужас от объемов работы, и это с максимальной долей автоматизации через разработку.

Стандарт, безусловно, не совсем проработанный, скорее всего сразу делать по-нему не потребуют, более того, подозреваю, что конечная информационная система, в которую предполагается сие грузить также ещё не сделана или существует только в прототипе, но общий тренд весьма тревожный (с оглядкой, опять же, на факт повсеместного "рисования" в DWG). Для своего проклятого диссера пришлось делать по похожим схемам статистику прогнозируемых трудозатрат и она очень нерадостная.

Хотелось бы писать чаще, но как есть. По основной работе зимой локализовывал руководство .NET-разработчика AutoCAD под nanoCAD и решил чего пропадать добру и выложил его перевод открыто , а под nanoCAD в их справочники пошла локализация примеров и особенностей поведения API. Насколько я знаю, справочники из поставки AutoCAD SDK полностью никогда не переводили на русский. Опытным разработчикам, конечно, там читать не о чем. С распространённостью ИИ-агентов вы могли бы сказать, что то напрасный труд, но полный расклад они вам не дадут, и поди ещё проверь за ними (местами при переводах я кстати их использовал); в общем пособие будет полезно начинающим прикладным разработчикам и тем, кто пишет нечасто, с целью освежить память.

На этих же материалах запланировал записать курс из нескольких модулей по разработке под nanoCAD (AutoCAD) для разных API, времени хватило пока только на .NET, а в планах перевод и адаптация материалов по COM и ObjectARX. Открытый видеокурс разместили на ресурсах TBS (кому где удобно смотреть, YouTube, VK Video, Rutube), краткая аннотация к курсу в описании плейлиста на ютубе. Код на репозитории. К сожалению в ряде мест на демонстрации были допущены мелкие и серьезные оговорки и описки, постарался их всех описать в примечаниях под видео, так как ресурсов и желания перезаписывать не было. В любом случае, как и справочников, именно открытых курсов тоже вроде не было на русском, только несколько плейлистов.

На фоне всеобщего "хайпа" про применение ИИ в самых различным сферах, в частности, в распознавании образов по чертежам, остаются не замеченными или слабо освещенными теоретические и прикладные исследования в области инженерной графики (задачами которой и являются эта и многие другие "боли" инженеров).

В общем, вот весьма занятная диссертация, выходящая скоро на защиту, "Алгоритмы преобразования чертежно-конструкторской документации в трехмерную каркасную модель" по упомянутому процессу без всяких ИИ с прогнозируемым результатом. Наверняка автор не будет против предоставить опытные версии используемой автоматизации заинтересованным пользователям (наверное, в приоритете представителям проектных бюро и институтов).

Познавательная статья, о использовании обновлённого Renga API для создания объектов на примере полезной практической задачи, включенной кстати в дорожную карту -- создание меток уклонов элементов (на примере кровли). Реализация получилась, конечно, не идеальной (ограничения есть ограничения), но кому-то может пригодится. Подробности и ссылка на "попробовать" в статье.

P.S. Апологеты Renga наверняка познают культурный шок от вида цветного текста, в API завезли, но в сам продукт ещё нет.

P.P.S. Пасхолочка - там среди функций плагинчика в конце статьи есть смена цвета текстов.

https://georggrebenyuk.github.io/blog/article_25092025_renga.html

Докладываюсь по промежуточной версии своего "конвертера" с кодовым названием "вилы". Все материалы, краткие описания и исходный код под GPL 3 приведены на отдельной страничке https://github.com/Vinny-Environment.

Реализовано ограниченное чтение-запись формата SMDX (Топоматик), чтение-запись простенького формата dotbim (на нем, в основном, тестировал), запись в формат Navisworks NWC (для этого пришлось аж написать отдельную библиотеку с портированием С++ API в .NET).
Сделаны 2 плагинчика на экспорт к Renga и Navisworks. К Renga по сути вышла актуализированная версия моего давнего плагинчика renga_3d_export 2 года назад. Теперь можно в Navisworks сохранять сцену в NWC среди прочего (не знаю зачем, но можно).

Писал на скорую руку, где вылетало-правил, может быть нестабильно.

В планах много всего. Следующий на очереди CADLib 🥴, далее вероятно Pilot-BIM, Civil3d; из форматов -- GLTF, IFC, FBX. Ну и прочие форматы под "российские" программы и СОДы, их очень много разных плохо-совместимых.
В любом случае начало положено, дальше надеюсь будет проще, хотя и постоянно вношу изменения в логику по ходу работы над новым.

Занявшись очень давно откладываемой идеей конвертера обменных форматов данных из различных САПР и СОД друг в друга (при наличии на то программной возможности) пришлось глубоко погружаться в специфику. Далее будут публикации, посвященные конкретным форматам и объектным моделям САПР и СОД.
Саму разработку пока не публикую -- хочу добавить ещё несколько обработчиков для солидности.

Первым парад открывает статья об обменном формате SMDX от Топоматик.
Неприкрашенные цензурой мнения и экспрессивные высказывания при разработке см. во втором канальчике-дневнике @georg_apocalypse 😬.

https://georggrebenyuk.github.io/blog/article_26082025_SMDX.html

В продолжение цикла статей ModelStudio COM API третья часть -- на этот раз про потрясающий инструментарий, позволяющий программно вычислять значения формул для заданных объектов и самое важное - связывать текстовый примитив или вхождение блока с параметрическим объектом, прописывая в значение текста или атрибута блока формулу, которая будет ДИНАМИЧЕСКИ связанной с объектом и связанный анотатированный объект может двигаться вслед за основным. Мне кажется, видел запросы на реализацию различных меток в модели и на чертежах, но это невозможно было сделать стандартным образом -- а тут используя блоки и тот же .NET API можно фактически создавать любые выноски в том числе для аксонометрических схем и листов. То есть задел вроде как огромный в использовании этого компонента COM API!

https://georggrebenyuk.github.io/blog/article_22062025_MST.html

Неожиданно-быстро вышла статейка в журнале "Известия Петербургского университета путей сообщения", от подачи до выхода чуть менее 2 месяцев всего с одним дополнением текста после рецензирования, очень быстрый (на фоне иных журналов) срок публикации статьи.

Статья "Метод выявления колейности и вертикальных конструкций по облакам точек автомобильных дорог на основе экстремальных уклонов" о подноготной алгоритма, реализованного в плагине TBS Clouds по выявлению вертикальных конструкций (писал о нем в апреле). Как я позже пробовал на больших файлах, всё упиралось в производительность и на мой взгляд, любые подобные алгоритмы должны подаваться именно в оптимизированной форме, но я пока не дорос до такого: большие данные, большие проблемы, оптимизация ... вот фоном пытаюсь освоить -- это отдельная гигантская область интересов.

Как и предыдущие, опубликовал запись о работе на researchgate: https://www.researchgate.net/publication/392858603_A_Method_for_the_Detection_of_Motorway_Rutting_and_Vertical_Structural_Damage_Using_Point_Clouds_on_Extreme_Gradients

Копаясь в дебрях ModelStudio COM, частично перекочевавшее в nanoCAD BIM Конструкции\Строительство, открыл для себя некоторые интересные детали о возможностях взаимодействия с Библиотекой стандартных компонентов, XPG-файлами, созданием параметрики. Изложил в статейке, которая пойдет как продолжением первой части за прошлый сентябрь по ModelStudio COM

P.S. Оно же, ещё более отредактированное и дополненное уйдет в справочники для nanoCAD BIM Строительство, там требуется значительная вводная, которую в данной статье оставил за бортом.

https://georggrebenyuk.github.io/blog/article_18062025_MST.html

Статейка-описание рабочего процесса, как используя nanoCAD и PostGIS сформировать чертежи с топоосновой вдоль дорог в фоновом режиме (без ручных действий). Чисто кодом. Сам код не приводится, детально описывается состав действий, отступления "как бы это делалось вручную".

По сути, это была отчаянная попытка (удачная) не делать тоже самое вручную в Civil 3D. Примерно пара дней на изобретение подхода, его реализацию, тестирование и получение результата. Вручную вышло бы дольше и с большей вероятностью появления ошибок от тупой монотонной работы.

Завёл себе второй канальчик aka флудильня/бытовой дневник Live. Понравился такой жанр у некоторых людей. "Кружочки" я принципиально игнорирую, их постфактум не отредактируешь 😁. Хоть там и заявлено наличие ненормативной лексики, я такие места чуть погодя правлю на нейтральные выражения (из-за этого, на всякий случай, включен запрет на копирование материалов). Да и обязательства работы в нескольких местах накладывают отпечаток на цензуру, особенно на политические/экономические темы -- их там вообще не будет. Также постараюсь вести систему тегирования -- до чего "тут" пока не дошли руки.

Здесь останутся серьезные/профессиональные статьи, а разные шутки, досуг, фотки и не-связанные с основной тематикой материалы публикации будут там; изредка буду делать перекрестные ссылки, когда приличия или объем не позволяют уходить в детали или наоборот -- описывать сопутствующую подоплёку.

Ожидания от научной деятельности -- исследования, математические модели, компьютерное моделирование ...

Реалии -- монотонное пролистывание подборок "Документы СССР" о постановлениях, где же появилось первое упоминание словосочетания "транспортное строительство" и что оно значит 😁

P.S. Заодно интересно почитывать декреты первых лет советской власти (утешая себя, что это хоть как-то полезно)

Вчера, 15 апреля, на сайте Нанософт опубликовали новость о выпуске версии 24.1 nanoCAD BIM Строительство, в личном кабинете дистрибутивы доступны для загрузки с 10 апреля, а 31 марта там в же в ЛК выложили версию SDK (набор разработчика) для выпускаемой версии. Этот же SDK ещё ранее, 28 февраля был опубликован в Клубе разработчиков. В этом же Клубе разработчиков в разделе лицензии теперь можно запросить серийный номер и на nanoCAD BIM Строительство 24. Дополнительно, справка разработчика доступна в онлайн виде наряду с локальной версией.

К чему вся эта вводная -- приглашение к тестированию возможностей разработчика. Не буду приводить список изменений, он представлен по ссылке выше, оговорю лишь, что пояснения к API старались даваться в сжатом и понятном виде, т.к. я сам немного разработчик, и порой сетую на отсутствие подробных справок.

Из принципиально нового, с конца декабря 2024 для всех разработчиков под продукты Нанософт доступен публичный NuGet-сервер (знающие поймут про что речь), информация по нему приведена в статье в составе онлайн-документации.

P.S. Так вышло, что примерно в это же время, месяцем раньше существенные обновления в части API появились и у Renga после почти 7-летней паузы в активном развитии (средств разработки), публикации про это тоже ожидаются в контексте налаживая совместной работы в разных САПР, подробности пока опускаю.

Хотел бы я писать чаще, но дал себе "зарок" минимально начинать что-то новое, пока не доделаю свою кандидатскую диссертацию иначе вообще никогда не захочу ей заниматься. Так как с ней временная вынужденная пауза, то публикую анонс новой разработки под модуль "Облака точек" платформы nanoCAD как совместную разработку с ребятами из TBS.
Краткое описание мотивов разработки и текущих функций отразил в статье. На картинке к посту одна из функций плагина по идентификации наклонных конструкций, идея и разработка которой удачно вошли в свою диссертацию.

Тут же, пользуясь случаем, предлагаю посетить грядущую местную конференцию в Санкт-Петербурге 22 апреля, на которой в 16 часов намечен доклад от Сэтл Строй, по заданию которых, собственно, этот модуль и начинал разрабатываться.

Пролистывал недавние защиты работ по своей научной специальности 2.5.1 и зачитался работой по цифровым моделям рельефа. Кто интересуется темой, будет полезно, очень много картинок, схем, параметров открытых моделей, способов оценки их точности и подходов к распознаванию отдельных элементов с научной точки зрения. Я темой глубоко не интересовался, возможно для искушенных людей будет мало нового.

Ссылка на информацию по защитам -- https://www.nngasu.ru/science/dissertation_advice/information_of_defense/dissertation_212_162_09.php. Коротин Антон Сергеевич «Методы повышения точности и достоверности цифровых моделей рельефа»

Познавательная статья про Autodesk 😅: экспроприация у экспроприаторов

Многие в курсе, что Autodesk еще задолго ДО очень неохотно относился к выпуску оффлайн-справок по продуктам и его отдельным инструментам. Недавно у меня появилась острая нужда детально изучить один из разделов справки, на которую никогда не было оффлайн-версии. Вечно сидеть с VPN я не хотел, потому промучавшись в общей сложности неделю я таки нашел вариант сохранять любую (надеюсь) справку в локальный формат. Итого весь процесс за минусом ожидания загрузки непосредственно файлов часами занимает несколько минут. Статья про это. Вернее, не статья, а целое "технопорно"
https://georggrebenyuk.github.io/blog/article_18012025_DOC_1.html

Я немного отойду от злости и скопирую последние версии справок для нескольких продуктов, сперва делал самое нужное мне -- Civil 3D API Reference Guide.
Если кто пожелает повторить путь самурая и найдет ошибки пишите, я делал всё на одном дыхании.

С точки зрения формата получения данных это можно назвать даже DDoS атакой, ну и ладно, Autodesk сами виноваты, что не делали оффлайн справок. 😄

Там же, глава 10.6, какое прекрасное описание будущего ... очень похоже на современность, вернее даже мечты современных инженеров об удобстве работы. Особенно понравившийся абзац в середине фрагмента выделил жирным.

Чтобы проще и лучше представить себе современное состояние работ по САПР, мы начнем свое изложение идеализированным описанием полностью автоматизированного крупного КБ или проектного института относительно близкого будущего. Полная автоматизация понимается не в смысле полного исключения человека из процесса проектирования, а в смысле освобождения его от всех рутинных работ. Основой описываемого идеализированного САПР является многомашинный вычислительный комплекс, состоящий из крупных (общеинститутских) ЭВМ, мини-ЭВМ в отделах и отдельных группах и, наконец, из микро-ЭВМ, вмонтированных в автоматизированные рабочие места (АРМ) каждого сотрудника.

Все мини-ЭВМ, как правило, снабжаются автоматическими линиями по производству технической документации (чертежные автоматы, АЦПУ, копировальные и брошюровочные машины, выводные устройства, выпускающие носители с соответствующими программами для оборудования с ЧПУ). Еще более мощными линиями такого рода снабжается общеинститутский ВЦ. В ряде случаев подобный центр подготовки технической документации (ЦПТД) может исключить необходимость иметь подобные линии при отдельных мини-ЭВМ.

Вычислительный комплекс через Государственную сеть вычислительных центров должен иметь автоматический выход на централизованные специализированные банки данных по материалам, стандартным конструктивным элементам, комплектующим деталям, оборудованию и т. п. В случае отсутствия сети каждый проектный институт (или КБ) должен заводить упрощенные (ориентированные на свои нужды) банки такого рода. Нет нужды доказывать, что централизованные (пополняемые разработчиками всей страны и всеми доступными зарубежными материалами) банки данных могут обеспечить гораздо более полный и качественный сервис для проектантов, чем любые упрощенные доморощенные варианты.

Под автоматическим выходом на централизованные банки данных здесь понимается возможность для каждого сотрудника, не сходя со своего рабочего места, оперативно получить все необходимые ему сведения (включая чертежи) об интересующем его объекте. Поскольку данные получаются через институтский вычислительный комплекс, то при решении использовать запрошенный стандартный элемент в своем разделе проекта сотрудник не должен вводить никаких данных (кроме имени требуемого элемента) в ЭВМ. Нужно заметить, что борьба с ручным вводом информации в ЭВМ является одной из главных отличительных черт комплексной автоматизации вообще и САПР в особенности.

Вычислительный комплекс САПР должен быть обеспечен машинным автоматизированным архивом проектов, выполненных в данном институте или КБ. Из этого архива в установленном порядке (с минимальной задержкой после окончания разработок) должны пополняться соответствующие централизованные банки. Кроме того, сам институт (или КБ) может вести один или несколько (специализированных) централизованных банков данных (в соответствии с произведенным распределением). Ко всем этим данным в принципе также должна быть обеспечена возможность оперативного доступа непосредственно с рабочих мест.

Предположим, что в процессе проектирования, скажем завода, один проектант переместил в определенное место какую-то единицу оборудования, а другой проектант еще не убрал с этого места "свое" оборудование. В этом случае база данных в соответствующий момент времени внутренне противоречива, ибо представляет объект, который в действительности не может существовать

(глава 6.10, Глушков В.М. Основы безбумажной информатики. Изд. 2-е, испр. -- 1987)

Стоооооп. А ведь это же современные проблемы синхронизации информационных моделей!
Читая книгу по совету научного руководителя по аспирантуре, с грустью осознаю, что все текущие проблемы давным-давно уже поднимались и даже решались в рамках более серьезных трудов, вот только их практическая реализация как и многих других сильно запоздала, а то и вовсе не известна современникам, пылясь в архивах библиотек. После такого уже опускаются руки что-то писать "научное", когда понимаешь что очень многое уже давно было написано, надо лишь реализовать ...

В ноябре-декабре в журнале "Вестник компьютерных и информационных технологий" вышли парочка статей (были написаны ещё в марте 🙈) по материалам давнего проекта в стенах СПбПУ по обработке данных облаков точек на транспортную инфраструктуру СПб; статьи были написаны ради соблюдения минимума публикаций в профильном журнале по своему коду специальности 2.5.1 по аспирантуре (надеюсь, в следующем году будет защита ☹️)

Тексты выложил на researchgate, "Моделирование зависимости плотности облаков точек от скорости съемки" и "Методика оценки качества облаков точек по условию плотности". Если первая довольно очевидная, то вторую можно использовать в том числе при приемке работ по лазерному сканированию.

P.S. Я ничего не пишу в канале по своей привычной сфере только оттого, чтобы эти умные мысли потом система антиплагиата не нашла в интернет-статьях.