[zamtmn]

Всем привет!
В свободное время делаю для себя небольшую CAD программу - всегда было интересно как это работает внутри.
На данный момент есть следующие наработки:

• Довольно быстрый OpenGL рендеринг чертежа
• Кроссплатформенность (Windows/Linux, x86/x64, win/gtk/qt)
• поддержка подмножества DXF версии 2000
• поддержка SHX, TTF шрифтов
• поддержка типов линий
• поддержка примитивов POINT, LINE, CIRCLE, POLYLINE, LWPOLYLINE, ARC, ELLIPSE, INSERT, TEXT, MTEXT, 3DFACE, SOLID, SPLINE, HATCH
• некоторые потуги автоматизации слаботочных разделов проекта

Cтраничка программы на SourceForge
Cтраничка программы на GitHub
Cтраничка программы на Ohloh

Программа пишется на паскале, компилируется в Lazarus/FPC. Исходный код открыт и лежит в SVN репозитории Git репозитории
Текущую сборку программы можно взять тут, но лучше тут (более менее свежие сборки для Windows_x86 и для Linux_x86_64, другие - стареханькие). Для работы требуется аппаратная поддержка OpenGL на целевом компе
Также программу можно собрать самомтоятельно, для этого понадобятся:

• релизный Lazarus версии не менее 2.0.10 на базе FPC версии не менее 3.2

Программа не требует установки и не пишет\читает ничего в системные папки (за исключением TEMP) Под windows не допускаются кирилические (и другие) символы в пути к программе (в путях к dxf файлам допускаются), linux версия такой болезнью не страдает.

Любые замечания/предложения приветствуются!

[zamtmn]

Еще "фича" - выбор за пределами экрана. при нажатии ctrl рамка выбора не подрезается по экрану, без нажатия - как в автокаде - подрезается.
https://imgur.com/a/2HNgurZ
Программа записи видео не показывает надпись "ctrl" во время движения мышки, только в момент нажатия кнопок. Когда диагональный крест рамки полностью на экране - контрол не нажат, когда вылазит за пределы нажат

[Marsikus]

Автодеск эту фичу только в 2018 версии Автокада родить изволил. Так что скоро Автокад перегонишь

[zamtmn]

Marsikus
скорей бы уже))


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

Сам по этому случаю тоже постараюсь родить 1.0 (без фантастических планов, по текущему состоянию) Поэтому приглашаю всех интересующихся на https://github.com/zamtmn/zcad/issues - баги, необходимые фичи

[Marsikus]

А какая платформа у тебя в приоритете по количеству пользователей: винь или линь?

[zamtmn]

конечно винь. в линуксе только я и 1.5 интересующихся))

[zamtmn]

Небольшой релиз.
Добавил команду stretch. Думал придется для нее копаться в движке... нет, получилось сделать снаружи, скрестив секрамку и редактирование примитивов за грипсы.
Изменил систему присвоения версий. Как ее принято организовывать используя гит? в свн все просто - ревизия это по сути и есть номер версии. В гите вижу только в уме инкрементировать циферки и вписывать их в тэги. Неудобно.

[Marsikus]

Так ведь коммит не обязательно подразумевает новую версию. Такая логика у гита.

[zamtmn]

Конечно не каждый комит релиз, но каждый релиз это какойто комит, и например имея

zcad_v0.9_svn2510.7z zcad_v0.9_svn314.7z

ясно что версия 2510 гораздо новее.
В свн каждый комит имеет номер, и он инкрементируется каждый раз при комите.

[zamtmn]

Багофиксы 0.9.8.3
Подумываю ввести блоки форматов, для авьозаполнения ведомости чертежей и пакетной печати. Нужен механизм похожий на видимость в автокадовских динблоках чтоб было удобно эти блоки форматов переключать.
Динблоки мне не реализовать, буду придумать чтото похожее с обычными блоками

[Сергей812]

Сообщение от zamtmn Нужен механизм похожий на видимость в автокадовских динблоках чтоб было удобно эти блоки форматов переключать.

если программно - то что мешает перевставлять обычные блоки форматок с переносом информации?

[zamtmn]

Програмно. ничто не мешает.

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

[Сергей812]

Сообщение от zamtmn Проблема в том чтобы встроить это незаметно в интерфейс

в каком плане незаметно? Заполняется автоматически без участия пользователя?

[zamtmn]

Заполнение какраз давно работает - через инспектор в "переменные" блока.
незаметно - например как в динблоках добавлять грипс с комбобоксом по нажатию - такого механизма в зкаде нет и реализовать проблемно((

[Сергей812]

а через контекстное меню - если выделен блок или блоки форматов, то появляются еще пункты?

[gumel]

Сообщение от Marsikus Автодеск эту фичу только в 2018 версии Автокада родить изволил. Так что скоро Автокад перегонишь

zamtmn, я знаю как обогнать Автодеск

Речь про блоки. Я бы расширил функционал объектных привязок и блоков. Например для блоков сделал бы возможность отключения (добавив к блокам некоторое свойство со значением true/false) стандартных привязок (mid, end и т.п.) И (!) сделал бы некоторые специальные точки внутри блока за которые можно было привязываться. Стало бы намного удобней, поскольку блок это уже отдельная единица чертежа, и зачастую (да почти всегда) большинство привязок для каждого примитива внутри блока попросту не нужны!

[ShaggyDoc]

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

В отношении форматок и не надо "незаметно". Это важная команда, вообще достойная индивидуального диалогового окна.

У меня она вообще была сделана в виде Мастера. Надо ведь заполнить много данных:
Выбор размера формата
Выбор вида основной надписи
Заполнение граф, причем так, чтобы тексты могли повторяться для объекта и проектной организации
Возможное использование логотипа
и всё прочее.

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

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

[zamtmn]

gumel
У меня пробегали похожие мысли:
1 - доп свойство для всех примитивов "участие_в_привязке"=(да,нет,как_у_владельца), но оно общее на все привязки, а не на каждый тип
2 - специальные блоки (например просто точки) которые будучи добавлены в другой блок добавляют ему доп точки привязки. названия их наяинаются например на OSPOINT_*
3 - рисующая команда отключает обычные привязки и включает (2). Напимер комнда рисующая кабели включит привязки OSPOINT_CABLE_* и сюда попадут блоки с названиями OSPOINT_CABLE_CONNECTOR, OSPOINT_CABLE_TERMINAL и т.п.

1 легко залезет в расширеные данные примитивов, а 2 и 3 уже DXF совместимо

[gumel]

В принципе да, можно наверное и для всех примитивов сделать подобную фитчу.

Но для блоков это архиважно. Например имеем такой блок:



Ну ясно же, что объектная привязка нужна тут далеко не во всех точках ))

[zamtmn]

ShaggyDoc
Я планирую общий механизм для разных применений - менять блоки форматов, менять УГО извещателей, светильников и т.п.
Блок выделен, название блока и список альтернатив фигурируют в конфиге команды, определения блоков альтернатив присутствуют в чертеже или базе программы... Предлагаем замену, а что там: УГО или форматка - пользователю виднее.

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

----- добавлено через ~8 мин. -----
gumel
В принципе реализация не сложна. в дополнение к существующим настройкам привязки добавить текстовое поле с названиями блоков создающих доп точки привязок...
Но такой механизм будет требовать поддержки от базы определений блоков и от команд рисования примитивов

[veb86]

Сообщение от zamtmn В принципе реализация не сложна. в дополнение к существующим настройкам привязки добавить текстовое поле с названиями блоков создающих доп точки привязок... Но такой механизм будет требовать поддержки от базы определений блоков и от команд рисования примитивов

Мне кажется в блоки надо просто включить приметив точку, и программно определять, если внутри блока есть точка то привязываемся только к ней, если ее нет то привязываемся как обычно к линиям и тд. При создании блока пользователь сам должен продумать где и сколько будет располагаться точек привязок. Обязательно настройку: учитывать точки привязок или нет. Что бы ее можно было отключить и привязываться ко всему.

Сообщение от zamtmn Да наверно для штампа имеет смысл отдельный диалог - графы длинные, их много - все в инспекторе будет неудобно. Но это уже сахарок))

Главное это механизм. Гую даже я смогу добавить, на штампы.

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