САПР на Lazarus

[Лекс Айрин]

В целом цель достичь автокада и не ставится.

Я понимаю.

А так речь идет о развитие своей специальности кнопочек, по разделам КР,АР,ВК, ну и походу все равно будет происходить развитие общих менюшек, инструментария.

Именно частей. Как отдельных проектов.

А про одного человека я в шоке, как может один человек хорошо тянуть огромный бесплатный проект, питаться чем святым духом. Последние два месяца я цейтноте, ни написал ни строчки кода.

Тем не менее... обычно проект начинает 1 или 2 человека и очень долго тянут его. Или супер-мега-пупер корпорация, но это не наш случай.


Дело в том, что пишут для себя, а не на заказ.

[MylnikovDm]

Ну это вообще детский сад! Напишите обыкновенный конвертер и пошлите на ..., а ещё лучше в ... - всё это "умное" правительство, т.к. иначе, за год программисты РФ - точно не успеют переделать все программы в мире, под IFC.

Не надо переделывать все программы в мире, поскольку все основные пакеты для BIM уже давно умеют работать с IFC, который явялется стандартом в данной отрасли для обмена информацией. Это только у нас в России он до сих пор в юридическом смысле стандартом не является, что и пытаются исправить.
Кстати, наши российские разработчики тоже данный формат начинают поддерживать. По карйней мере в продуктах Nanosoft'а и Аскона данный формат худо-бедно работает.

Добавлено спустя 4 минуты 1 секунду:
Что касается формата IFC, то тут проблема на самом деле не в формате файла, а в его правильном наполнении. Я вам могу такой IFC выдать, который будет показывать на экране правильную картинку, но в атрибутах объектов либо вообще не будет информации, либо будет какой-нибудь бред. В результате использовать данный файл на следующих стадиях проекта будет либо вообще невозможно, либо невозможно без исправления ошибок и недоделок.

[vitaly_l]

А все остальные вокруг дураки и неучи

Я этого не говорил и даже так не думал. Более того, мне довольно часто помогают, решать какие-то задачи, в которых я слабо разбираюсь. Так вот правильно организовав процесс - работу делать в 100000 раз проще. Именно поэтому для меня всё просто.

Так вот, первые наши эксперименты положить всё это дело в обычную сетевую реляционную СУБД на базе SQL сервера (использовался PоstgreSQL 9.3) показали, что если разложить всё поэлементно в отдельные таблицы, то количество запросов при сборке модели или её редактировании получается очень большим.

Это и понятно. Но это как раз и называется неправильная организация интерфейса.

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

И что в этом сложного? Спросил у сервера, если есть изменения, то - подгрузил их в работу.

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

Это какие-то непонятные волшебные дебри. Запрет на редактирование возникает при одновременной записи. Такая ситуация бывает 1 раз на 1 000 000 и решается секундной задержкой записи, на уровне сервера.

zub писал(а):
Интересно, это оптимизм или недооценка компаса-авткада-чтотамимеетсяввиду или переоценка себя?
Похоже, что сразу и то, и другое, и третье.

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

[Лекс Айрин]

При остутсвии заний о том, как правильно организовать работу над проектом большой команды.

Никак. Только деля проект на части. Тут проблема не техническая, а организационная. Т. е., грубо говоря, из команды в 20+ человек 15 пишут четко заказанный код, трое сводят его и раздают задания, и еще двое тестируют и ловят блох. Есть, конечно, тикетный подход, когда есть задания и каждый сам выбирает что из этого делать, но он подходит скорее для очень крупных проектов.
Малая же группа просто более мобильна, ей не надо проходить несколько этапов принятия решений по дальнейшему развитию проекта.

[olegy123]

Давайте я вам расскажу, в чем тут проблема, поскольку сами вы явно ещё эту задачку решать не пробовали. BIM-модель это не просто база данных, это иерархическая модель, по сути большое дерево связанных между собой объектов.
...
А так-то да, ничего сложного.

PostgreSQL считается одной из сложной БД: cложная в настройке, также не простой инструментарий, но при этом обладает гибкостью, возможность дополнять своими плюшками.
Лично я бы не рекомендовал использовать без специалистов, даже сказал без хороших прокаченных специалистов.

Лично я считаю, что проблема не в PostgreSQL. Тем более у вас не в 10 этажей, к каждому пользователю 10Gb тянуть не надо.
Даже если вы оперируете с 1 миллионами объектов то информация о их геометрии 24мб (3(xyz)х8(double)*1000000)..
С вашими задачами справятся даже embedded SQL - с этого можно было начинать.

Добавлено спустя 50 минут 30 секунд:

Я понимаю.

Ну и зря..
Сейчас любой из GameDev состряпает 3D редактор, по функциональности он не будет уступать инженерным программам. Тот же Blender,Cinema 4D в разы сложнее и удобнее и производительнее, чем тот же Autodesk Autocad(хотя есть Autodesk 3Ds Max и скорее база у них общая)..
Поэтому писать там можно(и нужно) и не сложно. От того же 3Dхужожника, отличаются знанием гостов и понималками.. в софте обязательно нужны знакомые кнопки.
Заставит чертежника пересесть на новый софт - это более сложная задача чем написание автокада. То еще болото.

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

[veb86]

Именно частей. Как отдельных проектов.

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

Тем не менее... обычно проект начинает 1 или 2 человека и очень долго тянут его. Или супер-мега-пупер корпорация, но это не наш случай.
Дело в том, что пишут для себя, а не на заказ.

Ну вот zub и тянет его очень долго один, а иногда на разных форумах слышно как кто то хочет написать что то такое же с нуля и за 3 месяца. Вопрос, зачем если можно подтянуть существующий проект тем самым помочь себе и другим.
А то что я пишу ZCAD потому что буду им пользоваться, да это так.

[Лекс Айрин]

Сейчас любой из GameDev состряпает 3D редактор, по функциональности он не будет уступать инженерным программам.

Это не главное.

Заставит чертежника пересесть на новый софт - это более сложная задача чем написание автокада. То еще болото.

Так как я нахожусь с обеих сторон баррикады, то я прекрасно понимаю причину этого. Пересаживаться можно когда, либо нет выхода (удобного инструмента), либо когда нет работы. А если подойти посреди работы, когда открыто 100500 файлов и все мысли о работе... тогда безусловно пошлют по батюшке.

а иногда на разных форумах слышно как кто то хочет написать что то такое же с нуля и за 3 месяца.

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

[olegy123]

За три месяца CAD в одиночку не напишешь. Просто нет подходящих инструментов.

Мне это предстоит - поэтому смотрю на ZCad как на спасательный круг. Но меня пугают его структура.

[Лекс Айрин]

olegy123, тут уж сложно что-то поделать... насколько я знаю, сейчас как раз и идет упрощение структуры.

[veb86]

Мне это предстоит - поэтому смотрю на ZCad как на спасательный круг. Но меня пугают его структура.

И правильно смотрите. Я когда первый раз вышел на связь с Zub-ом мне вообще все казалось страшным и невозможным для понимания, а потом понимаешь что в целом все четко, правильно и логично. Конечно есть места куда я стараюсь не заглядывать, все таки большой опыт в 0 полноценных проектов дает о себе знать (занимался только написание модулей на vb.net-е). А вы Гуру и сразу пугает структура, мне кажется у всех огромных проектов и должна быть пугающе огромная структура

[zub]

А почему не CoolBar? Или не ControlBar? Чем они плохи?

Они для другого. ну и когда делался интерфейс зкада их еще небыло.

Я про то, что нужно внедрение JS как минимум. Потому что он ходовой. Lua тоже не помешает.

Нужно очень много что. делать это некому

Мне это предстоит - поэтому смотрю на ZCad как на спасательный круг. Но меня пугают его структура.

Что конкретно?

[vitaly_l]

Они для другого

Нет.
ControlBar - делает абсолютно тоже самое. На него можно класть, любые контролы и потом их таскать с места на место.
CoolBar - немного более ограничен, в возможностях и позволяет таскать контролы, только внутри себя.
Вы посмотрите, там есть всякие настройки и они позволяют настроить как надо. Заменить одно на другое - дело 5 минут, и они в Лазарусе из коробки.

[zub]

Contro[Cool]lBar - это контейнер для тулбаров. он не умеет быть плавающей панелью инструментов - он стоит в одном месте на форме. Разве нет?

[vitaly_l]

Contro[Cool]lBar - это контейнер для тулбаров. он не умеет быть плавающей панелью инструментов - он стоит в одном месте на форме. Разве нет?

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

[zub]

Дай тестовый проект с несколькими панельками. вертикальными и горизонтальными.
Даже если там всё хорошо, использовать это можно будет только после устранения https://bugs.freepascal.org/view.php?id=24703