Schöck
| Правила | Регистрация | Пользователи | Поиск | Сообщения за день | Все разделы прочитаны |  Справка по форуму | Файлообменник |

Вернуться   Форум DWG.RU > Программное обеспечение > Программирование > Создание CAD программы с нуля

Создание CAD программы с нуля

Ответ
Поиск в этой теме
Непрочитано 19.11.2013, 00:29 6 |
Создание CAD программы с нуля
zamtmn
 
КИПиА
 
Tyumen
Регистрация: 21.03.2005
Сообщений: 1,453

Всем привет!
В свободное время делаю для себя небольшую 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
  • некоторые потуги автоматизации слаботочных разделов проекта
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 версия такой болезнью не страдает.

Для запуска доступны следующие ключи командной строки:
  • NLL - отключение загрузки файла докинга окон, окна открываются непристыкованными, но докинг работает
  • SI - полное отключение докинга, зкад работает в однооконном режиме (очень недоделанном)
  • UPDATEPO - отключение закрузки локализации, будет запущена английская версия. Также в этом режиме доступна команда обновления файлов локализации
  • NOSPLASH - отключение показа окна загрузки
  • путь/к/файлу.dxf - открыть указанный файл

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

Вложения
Тип файла: zip glu.zip (903.8 Кб, 379 просмотров)


Последний раз редактировалось zamtmn, 08.07.2020 в 00:19.
Просмотров: 112287
 
Непрочитано 15.09.2019, 22:00
#341
АлексЮстасу

топограф, технолог
 
Блог
 
Регистрация: 24.05.2009
Москва
Сообщений: 2,817


Цитата:
Сообщение от zamtmn Посмотреть сообщение
На чертеже вставлено несколько устройств. они между собой связаны
Чтобы сразу не закопаться, да и в принципе естественно, что лучше изначально разделить разное. Описания-определения объектов и связи между объектами. Первичное, по-моему, описания-определения. Т.к. связи бывают у чего-то определенного, и зависят от сущностей и свойств объектов. Т.е. сначала разобраться с описаниями-определениями. А потом с взаимосвязями.
С определениями-описаниями, например, такие вопросы:
- в целом способ хранения идентификаторов типов объектов и характеристик объектов. Как в расширенных данных или еще как-то.
- сразу встроить в графические элементы эти возможности или добавлять их по необходимости.
- хранить ли идентификаторы и характеристики одним способом или разными. Одним, допустим - в "таблицах", где одно поле отведено для идентификаторов типов объектов, а остальные для характеристик. Или разными, допустим, идентификатор - название таблицы, а их поля для характеристик.
- определять уже существующие неопределенные графические элементы.
- определять графические элементы на основе их графических свойств. Как у Вас в примерах: блок такой-то в таком слое и пр. - извещатель дымовой потолочный, а эдакий - двигатель.
- определять один графический элемент как несколько типов объектов.
- заменять объектные определения.
- удалять объектные определения из графических элементов.
Вопросов много.
И со "связями" тоже сейчас неопределенность. В одних случаях Вы имеете в виду видовую принадлежность - когда пишете про потребителей энергии и частный случай, двигатель, про "ветки дерева".
В других случаях пишете о связях конкретных объектов друг с другом, о "главных" и "представителях"...
__________________
количество моих сообщений не говорит о знании Автокада
АлексЮстасу вне форума  
 
Автор темы   Непрочитано 16.09.2019, 09:41
#342
zamtmn

КИПиА
 
Регистрация: 21.03.2005
Tyumen
Сообщений: 1,453
<phrase 1=


>>- в целом способ хранения идентификаторов типов объектов и характеристик объектов. Как в расширенных данных или еще как-то.
Да. К примитиву привязана некая сущность - "расширитель" - в ней лежат имена, типы и значения дополнительных свойств

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

...

>>Вопросов много.
Да. А объяснятель из меня плохой. надо доводить до возможности показать концепт.


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

>>И со "связями" тоже сейчас неопределенность. В одних случаях Вы имеете в виду видовую принадлежность - когда пишете про потребителей энергии и частный случай, двигатель, про "ветки дерева".
Нужно все идентифицировать - как отдельную часть "размазанного" примитива, так и весь его в целом.
zamtmn вне форума  
 
Непрочитано 17.09.2019, 03:55
#343
АлексЮстасу

топограф, технолог
 
Блог
 
Регистрация: 24.05.2009
Москва
Сообщений: 2,817


Цитата:
Сообщение от zamtmn Посмотреть сообщение
Можно встроить, но это неудобною приведет либо к появлению одного гиперпримитива с гигантским набором свойств, либо к 100500 одинаковым примитивам, отличающихся только набором дополнительных свойств
Я представлял себе это как одно обязательное поле - для идентификатора типа объекта плюс возможность определять любое нужное число свойств. Причем, обязательное поле изначально пустое, а при вставке из меню объектов с автоматической записью в него названия типа объекта. И при вставке обычной командой запись в него условного названия. Если блок, то название блока+слой+цвет. Или т.п.
Цитата:
Сообщение от zamtmn Посмотреть сообщение
лавные и представители - это возможность движка работать с "размазаными" примитивами, состоящими из совершенно разных примитивов, но объедененные набором дополнительных данных. Будь это извещатель на плане и на схеме, колодец на плане и на профиле - неважно.
Гм... Может быть решить это через поле ID объектов - для всех объектов, отображающих один, относящихся к одному, давать одинаковое значение? Тогда при удалении-добавлении что "главных", что "представителей" ничего не нарушится.
__________________
количество моих сообщений не говорит о знании Автокада
АлексЮстасу вне форума  
 
Автор темы   Непрочитано 19.09.2019, 11:36
#344
zamtmn

КИПиА
 
Регистрация: 21.03.2005
Tyumen
Сообщений: 1,453
<phrase 1=


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

>>Может быть решить это через поле ID объектов
Это можно решить разными способами, суть не в этом. Суть в том набор данных размазывается по чертежу.

>>Тогда при удалении-добавлении что "главных", что "представителей" ничего не нарушится.
Будут теже проблемы. например на чертеже есть "главный" и "представитель" мы копируем:
1 - оба примитива
2 - только главного
3 - представителя
я хочу чтобы в результате
1 - появился новый главный и новый представитель нового главного
2 - появился новый главный
3 - появился новый представитель старого главного
Решение влоб нового главного и нового прелставителя этого нового главного не даст. Нужно вмешательство в движек, в алгоритм копирования. Такое же вмешательство нужно в удаление и сохранение\загрузку
zamtmn вне форума  
 
Непрочитано 19.09.2019, 13:45
#345
bigden


 
Регистрация: 05.08.2008
Сообщений: 704


zamtmn, а какую ИДЕ используете?
bigden вне форума  
 
Автор темы   Непрочитано 19.09.2019, 13:49
#346
zamtmn

КИПиА
 
Регистрация: 21.03.2005
Tyumen
Сообщений: 1,453
<phrase 1=


IDE - Lazarus, компилятор - FPC
zamtmn вне форума  
 
Непрочитано 08.01.2020, 07:33
#347
CalcProg


 
Регистрация: 02.10.2016
Сообщений: 171


уважаемый zamtmn, на мой взгляд ваша ошибка в том, что вы думаете как чертёжник, а не как программист. Для вас первичен чертёж, а не объектная модель. Хотя, на первом месте должна быть объектная модель ( в вашем случае электрическая схема), а уж потом чертёж этой модели (схемы). И оперировать вы должны объектами, а не примитивами.
У примитива на чертеже должна быть, только одна ссылка на объект, частью которого он является. Как говориться: 'мухи отдельно, котлеты отдельно'.
CalcProg вне форума  
 
Непрочитано 08.01.2020, 08:27
#348
nickname2019


 
Регистрация: 18.11.2019
Сообщений: 398


Цитата:
Сообщение от CalcProg Посмотреть сообщение
уважаемый zamtmn, на мой взгляд ваша ошибка в том, что вы думаете как чертёжник, а не как программист. Для вас первичен чертёж, а не объектная модель. Хотя, на первом месте должна быть объектная модель ( в вашем случае электрическая схема), а уж потом чертёж этой модели (схемы). И оперировать вы должны объектами, а не примитивами.
У примитива на чертеже должна быть, только одна ссылка на объект, частью которого он является. Как говориться: 'мухи отдельно, котлеты отдельно'.
Имхо, объектно-ориентированное программирование обладает весьма существенными недостатками, главный из которых - сложность "дерева" наследования, сложность внесения изменений в это дерево и, как следствие, трудности с передачей проекта "в массы", на сопровождение другими людьми и т.д.
Не забывайте, объектную модель можно представить как простой чертеж (квадратики, стрелочки наследования и т.д.), но не любой чертеж можно представить как ПРОСТУЮ объектную модель. Когда мы пытаемся создать объектную модель на некий процесс, мы, часто, усложняем себе задачу.
nickname2019 вне форума  
 
Автор темы   Непрочитано 08.01.2020, 10:21
#349
zamtmn

КИПиА
 
Регистрация: 21.03.2005
Tyumen
Сообщений: 1,453
<phrase 1=


CalcProg
Возможно. В свое время я пытался работать в множестве разных программ, в том числе написанных программистами только непонятно для кого((. Обычно в них работать невозможно, т.к. при всей продуманности модели внимания разным удобностям не уделяется и работать с реальными данными не вписывающимися в задуманную модель становится невозможно.
Я пытаюсь сделать дешево и универсально в рамках своего понимания проблем. Объектная модель бывает разная и построение ее может начинаться не всегда с схемы а например с плана
nickname2019
Сложности не от "объектно-ориентированное" - в лоб программку для черчения можно написать быстро, просто и красиво на любом языке ИМХО. Но работать она будет с сотнями примитивов, потом начнутся проблемы в виде торможений ИМХО.
И вот тут начинаются усложнения - линейные списки становятся деревьями, множественные мелкие объекты из объектов становятся набором байтов чтоб память выделять не под каждый отдельно а одним большим куском и тд и тп...
zamtmn вне форума  
 
Непрочитано 08.01.2020, 10:34
#350
Сергей812


 
Регистрация: 10.08.2013
Сообщений: 8,265


Offtop:
Цитата:
Сообщение от zamtmn Посмотреть сообщение
Я пытаюсь сделать дешево и универсально в рамках своего понимания проблем.
"дешево" явно лишнее - по количеству трудозатрат за эти годы)
Сергей812 вне форума  
 
Непрочитано 08.01.2020, 10:37
#351
nickname2019


 
Регистрация: 18.11.2019
Сообщений: 398


Цитата:
Сообщение от zamtmn Посмотреть сообщение
Сложности не от "объектно-ориентированное" - в лоб программку для черчения можно написать быстро, просто и красиво на любом языке ИМХО. Но работать она будет с сотнями примитивов, потом начнутся проблемы в виде торможений ИМХО.
И вот тут начинаются усложнения - линейные списки становятся деревьями, множественные мелкие объекты из объектов становятся набором байтов чтоб память выделять не под каждый отдельно а одним большим куском и тд и тп...
Тут как раз мне более-менее понятно: можно купить стороннее графическое ядро и строить программу на нем (сразу попав в топы графических редакторов по производительности), либо сочинять это ядро самому. Я вижу трудности в построении объектной модели именно интеллектуальных графических объектов с учетом их взаимосвязи (проводов, розеток, контроллеров, арматуры, бетона и т.д.).Тут ООП, на мой взгляд, будет усложнять задачу.
nickname2019 вне форума  
 
Непрочитано 08.01.2020, 11:18
#352
CalcProg


 
Регистрация: 02.10.2016
Сообщений: 171


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

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

----- добавлено через ~22 мин. -----
лично я разделил все задачи при проектировании сапр.
Отдельно программа управленя проектом.
Содержит данные о проекте ( наименование, исходные данные (изыскания, район стротельства), тип здания (сооружения), поэтажный план и фасады, расчеты фундамента, стен, кровли, 3д модель и т.д.)
Каждый пункт в программе управления проектом это отдельная задача, решаемая с помошью различных программ. Одной из которых является векторный графический редактор. Который в зависимости от решаемой задачи использует тот или иной модуль (фундамент, стены, кровля, 3д модель).

----- добавлено через ~30 мин. -----
то есть векторный гафрический редактор должен уметь спроить простейшие примитивы и выполнять с ними простейшие операции, всё остальное должна делать твоя надстройка(модуль), соответственно данные вгр и надстройки( или модуля) должны быть отделены друг от друга и связанны между собой только ссылками (указателями).
CalcProg вне форума  
 
Непрочитано 08.01.2020, 11:51
#353
nickname2019


 
Регистрация: 18.11.2019
Сообщений: 398


Цитата:
Сообщение от CalcProg Посмотреть сообщение
Содержит данные о проекте ( наименование, исходные данные (изыскания, район стротельства), тип здания (сооружения), поэтажный план и фасады, расчеты фундамента, стен, кровли, 3д модель и т.д.)
Каждый пункт в программе управления проектом это отдельная задача, решаемая с помошью различных программ. Одной из которых является векторный графический редактор. Который в зависимости от решаемой задачи использует тот или иной модуль (фундамент, стены, кровля, 3д модель).
Это приводит к проблеме: нужно изначально определить свойства и поведение всех строительных элементов, которые могут появиться в проекте. Это не решаемая задача даже для корпораций уровня Autodesk.
Хотя, если менеджмент обладает достаточной квалификацией, то можно свалить проблему на пользователя - пусть он сам мучается с семействами.
nickname2019 вне форума  
 
Непрочитано 08.01.2020, 11:54
#354
CalcProg


 
Регистрация: 02.10.2016
Сообщений: 171


Нет ничего не решаемого.
CalcProg вне форума  
 
Непрочитано 08.01.2020, 11:56
#355
nickname2019


 
Регистрация: 18.11.2019
Сообщений: 398


Цитата:
Сообщение от CalcProg Посмотреть сообщение
Нет ничего не решаемого.
Самое простое и дешевое решение - дать пользователю вносить изменения в объектную структуру интеллектуальных объектов.
nickname2019 вне форума  
 
Непрочитано 08.01.2020, 14:05
#356
CalcProg


 
Регистрация: 02.10.2016
Сообщений: 171


редактор объектов? )))
но сперва надо организовать модель, структуру, определится с типами объектов их свойствами, создать обработчики объектов определенного типа.
CalcProg вне форума  
 
Непрочитано 08.01.2020, 14:15
#357
nickname2019


 
Регистрация: 18.11.2019
Сообщений: 398


Цитата:
Сообщение от CalcProg Посмотреть сообщение
редактор объектов? )))
но сперва надо организовать модель, структуру, определится с типами объектов их свойствами, создать обработчики объектов определенного типа.
Это работа на годы. Самое интересное - когда создашь "скелет" - выяснится, что он в этом виде вообще никому не нужен.
Проще создать редактор объектов для юзеров, а базу объектов пополнять по ходу дела (или сами пусть пополняют). Т.е. язык описания объектов должен быть нетипизированным.

Типа языка Brainfuck.
nickname2019 вне форума  
 
Непрочитано 08.01.2020, 19:16
#358
veb86

Проектировщик электрических сетей
 
Регистрация: 17.01.2014
Пенза
Сообщений: 171


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

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

----- добавлено через ~22 мин. -----
лично я разделил все задачи при проектировании сапр.
Отдельно программа управленя проектом.
Содержит данные о проекте ( наименование, исходные данные (изыскания, район стротельства), тип здания (сооружения), поэтажный план и фасады, расчеты фундамента, стен, кровли, 3д модель и т.д.)
Каждый пункт в программе управления проектом это отдельная задача, решаемая с помошью различных программ. Одной из которых является векторный графический редактор. Который в зависимости от решаемой задачи использует тот или иной модуль (фундамент, стены, кровля, 3д модель).

----- добавлено через ~30 мин. -----
то есть векторный гафрический редактор должен уметь спроить простейшие примитивы и выполнять с ними простейшие операции, всё остальное должна делать твоя надстройка(модуль), соответственно данные вгр и надстройки( или модуля) должны быть отделены друг от друга и связанны между собой только ссылками (указателями).
С чего вы вообще все это взяли! В программе имеется БД УГО и БД изделий. Возможно создание сложных списков и выборности. Вы вначале попользуйтесь тем, что имеется.
Я сижу тоже стараюсь что то писать что бы уйти от кружочков и палочек. В zcad сейчас вполне можно создавать разные графические УГО и каждому из них или всем вместе дать значение(например УГО розетка - Присвоить ей марку, и в спецификации она учтется)
В программе реализована не плохая работа с сетями СС, сознаюсь прямо, полноценно от и до проект реализовать в zcad-е сложно, но возможно. По мне не хватает некоторых функций как раз обычного электронного кульмана. Я обычно 80% делаю в зкад, а остальные 20% до оформление, спецификация и тд в другом Каде (хотя реально и спецификацию мог бы делать в зкад, лень БД изделий забивать).
Сейчас делаю ЭМО, идет туго, вообще туго, времени мало. Будет наличие большинства УГО и появится БД изделий на электрику и свет, построение однолинейной схемы, кабельный журнал и так же спецификация. Планируется нормальная гибкость, но не 100%!!!. Только когда это все чудо придет, пока сказать сложно.
Самая главная проблема ZCAD это отсутствие коммьюните, реально программист только один, проект большой и сложный. Вот сидит zamtmn и думает добавить функцию "обрезка" (двинуть в сторону электронного кульмана) или двинуть проект в сторону САПР, древовидную структуру (здание-этаж-помещение-щит-автомат). Как бы и обрезка нужна и плюшку хочется.

Цитата:
лично я разделил все задачи при проектировании сапр.
Отдельно программа управленя проектом.
Содержит данные о проекте ( наименование, исходные данные (изыскания, район стротельства), тип здания (сооружения), поэтажный план и фасады, расчеты фундамента, стен, кровли, 3д модель и т.д.)
Каждый пункт в программе управления проектом это отдельная задача, решаемая с помошью различных программ. Одной из которых является векторный графический редактор. Который в зависимости от решаемой задачи использует тот или иной модуль (фундамент, стены, кровля, 3д модель).
Складывается ощущение что Вы уже создали САПР, если да то какой?
И тут начинается что бы начертить проект капитального ремонта двух этажного магазина, нужно забить фигову тучу не нужной информации и потом надеяться что программа соизволит выдать что то.
Да и разносить это все по разным программам, то еще удовольствие. Сегодня связь работает, завтра потерялась... После завтра автокад 2030 вышел, и они изменили кучу всего, а значит вам нужно опять все соединять, Петя сидит на 2008 автокаде, а Лена на 2014.

Все правильно zamtmn делает, ему просто рук не хватает и времени!!!
veb86 вне форума  
 
Автор темы   Непрочитано 08.01.2020, 23:27
#359
zamtmn

КИПиА
 
Регистрация: 21.03.2005
Tyumen
Сообщений: 1,453
<phrase 1=


CalcProg
>>То есть к примитиву привязывать не данные, а ссылку (указатель).
Ваша "ссылка (указатель)" это данные привязанные к примитиву. как вы их интерпретируете - дело десятое. Я за то что к примитиву можно привязать хоть что. хоть указатель кудато, хоть какойто конкретный набор параметров.
Откуда у вас уверенность что все смешано в кучу и завязано на внутреннюю реализацию примитивов? Я много сил потратил на разделение внутренней структуры - это кстати тоже весомая причина усложнения.
Святая вера в то что если чтото хранить снаружи то все сразу улучшится)) Но это только детали реализации.

nickname2019
>>Самое простое и дешевое решение - дать пользователю вносить изменения в объектную структуру интеллектуальных объектов.
В зкаде так и сделано, пользователь может делать с набором параметров все что хочет. Но будет несколько стандартизированных параметров для организации удобного представления устройств и их составных частей.

Сергей812
>>"дешево" явно лишнее - по количеству трудозатрат за эти годы)
Все окупается. Как в виде положительных эмоций от интересного хобби, так и материально в виде ускорения\упрощения решения задач в реальной работе.
Я имел ввиду что стараюсь не писать лишнего - например настройки в инспекторе - экономия на нудном гуе
zamtmn вне форума  
 
Непрочитано 09.01.2020, 06:26
#360
nickname2019


 
Регистрация: 18.11.2019
Сообщений: 398


Цитата:
Сообщение от zamtmn Посмотреть сообщение
В зкаде так и сделано, пользователь может делать с набором параметров все что хочет. Но будет несколько стандартизированных параметров для организации удобного представления устройств и их составных частей.
Имхо, нужен встроенный язык программирования наподобие "лисп".
nickname2019 вне форума  
Ответ
Вернуться   Форум DWG.RU > Программное обеспечение > Программирование > Создание CAD программы с нуля

Размещение рекламы
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск