[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
• некоторые потуги автоматизации слаботочных разделов проекта

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 - открыть указанный файл

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

[АлексЮстасу]

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

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

[zamtmn]

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

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

...

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


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

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

[АлексЮстасу]

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

Я представлял себе это как одно обязательное поле - для идентификатора типа объекта плюс возможность определять любое нужное число свойств. Причем, обязательное поле изначально пустое, а при вставке из меню объектов с автоматической записью в него названия типа объекта. И при вставке обычной командой запись в него условного названия. Если блок, то название блока+слой+цвет. Или т.п.

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

Гм... Может быть решить это через поле ID объектов - для всех объектов, отображающих один, относящихся к одному, давать одинаковое значение? Тогда при удалении-добавлении что "главных", что "представителей" ничего не нарушится.

[zamtmn]

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

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

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

[bigden]

zamtmn, а какую ИДЕ используете?

[zamtmn]

IDE - Lazarus, компилятор - FPC

[CalcProg]

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

[nickname2019]

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

Имхо, объектно-ориентированное программирование обладает весьма существенными недостатками, главный из которых - сложность "дерева" наследования, сложность внесения изменений в это дерево и, как следствие, трудности с передачей проекта "в массы", на сопровождение другими людьми и т.д.
Не забывайте, объектную модель можно представить как простой чертеж (квадратики, стрелочки наследования и т.д.), но не любой чертеж можно представить как ПРОСТУЮ объектную модель. Когда мы пытаемся создать объектную модель на некий процесс, мы, часто, усложняем себе задачу.

[zamtmn]

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

[Сергей812]

Offtop:

Сообщение от zamtmn Я пытаюсь сделать дешево и универсально в рамках своего понимания проблем.

"дешево" явно лишнее - по количеству трудозатрат за эти годы)

[nickname2019]

Сообщение от zamtmn Сложности не от "объектно-ориентированное" - в лоб программку для черчения можно написать быстро, просто и красиво на любом языке ИМХО. Но работать она будет с сотнями примитивов, потом начнутся проблемы в виде торможений ИМХО. И вот тут начинаются усложнения - линейные списки становятся деревьями, множественные мелкие объекты из объектов становятся набором байтов чтоб память выделять не под каждый отдельно а одним большим куском и тд и тп...

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

[CalcProg]

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

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

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

----- добавлено через ~30 мин. -----
то есть векторный гафрический редактор должен уметь спроить простейшие примитивы и выполнять с ними простейшие операции, всё остальное должна делать твоя надстройка(модуль), соответственно данные вгр и надстройки( или модуля) должны быть отделены друг от друга и связанны между собой только ссылками (указателями).

[nickname2019]

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

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

[CalcProg]

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

[nickname2019]

Сообщение от CalcProg Нет ничего не решаемого.

Самое простое и дешевое решение - дать пользователю вносить изменения в объектную структуру интеллектуальных объектов.

[CalcProg]

редактор объектов? )))
но сперва надо организовать модель, структуру, определится с типами объектов их свойствами, создать обработчики объектов определенного типа.

[nickname2019]

Сообщение от CalcProg редактор объектов? ))) но сперва надо организовать модель, структуру, определится с типами объектов их свойствами, создать обработчики объектов определенного типа.

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

Типа языка Brainfuck.

[veb86]

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

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

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

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

Все правильно zamtmn делает, ему просто рук не хватает и времени!!!

[zamtmn]

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

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

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

[nickname2019]

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

Имхо, нужен встроенный язык программирования наподобие "лисп".