Нууу, проблема с питоном сейчас в том, что его даже в школах начинают учить и «питонистов» скоро будет как грязи весной. Java же всегда имеет крепкий фундамент в виде огромного количества интерпрайз приложений. Все банки на ней написаны и кто-то должен поддерживать этот код. Джависты будут нужны всегда и везде.
Работаю непосредственно с КМД. Начало проекта по созданию КМД начинается с получения исходной документации, чаще всего КМ от заказчика. То есть просто чертежи, которые надо повторить, создать детальную модель и из этой модели получить все чертежи, спецификации и монтажные схемы. Специально для того, чтобы приложение «Металлоконструкции 3D» выполняло свои прямые функции, а именно выпуск рабочей документации КМД, укажу по пунктам то, без чего ну никак нельзя обойтись: 1. Создание сборки путем добавления к главной детали второстепенных посредством нанесения сварных швов или просто добавления в сборку. И никак не иначе. Для крупных проектов количество уникальных сборок исчисляется сотнями и каждую сборку вырисовывать в отдельном окне — это трата времени и сил впустую. Т.е. создали каркас — добавили профили, пластины, подрезки, болты — из них собрали сборки 2. Сквозная нумерация деталей/сборок через префиксы. Реализованный нынешний подход — машиностороительный, он требует ручного изменения обзначений и наименований деталей/сборок. Сравнивать детали/сборки и нумероваться должна программа, а не вручную. Помните, что сборки идут сотнями, а детали и того больше 3. Нужны координатные оси. Все изготовленные отправочные марки должны монтироваться, для этого на монтажных схемах нужны оси и высотные отметки. Сейчас получаетчся, что в Ренге оси есть, но КМД нельзя сделать, в Компасе можно сделать деталировку, но осей нет 4. Режим выбора отдельных деталей и сборок для того, это позволит быстро скопировать (например связь или колонну) в другое место и видоизменить, получив ещё одну сборку 5. Если уж по ГОСТ и ЕСКД всё оформляется, то нужны готовые стандартные шаблоны ведомостей (отправочные марки, метизы и др.) с возможностью редактирования и сохранения пользовательских шаблонов. В разделе КМ в Компас-3D ведь есть ведомости, для КМД они тем более нужны. 6. Нужен фильтр по сборкам, деталям, материалам, болтам и иным элементам. Искать элементы в боковой панели крайне неудобно, тем более по одной штуке 7. Создание пластин не только через эскиз, а прямо в модели с возможностью прямого изменения толщины, длины, ширины, фасок 8. Возможность копирования, вращения, зеркального отбражения любой детали/сборки без связи с родительской детали/сборки. Т.е. отзеркалили сборку и перенесли её в другое место, где спозиционировали как необходимо 9. Параметрические узлы нужны, и их наработка после создания базовых иструментов для 3D-моделирования является первостепенной. Отсюда вытекает создание и сохранение пользовательских узлов. Чем больше адекватных инструментов моделирования и параметрических узлов, тем больше у программы клиентов. Посмотреть, как всё подобное реализовано в других программных комплексах (Текла, Адванс стил), и сделать подобные необходимые инструменты не зазорно. Они в своей подавляющей массе повторяются и делают выполнение проектов быстрее и качественнее. Но это всё зарубежные, не родные
Что-то из разряда «гуманитарии вспоминают математику за 7 класс». Математические множества называть «какими-то кружочками» это сильно, конечно… Еще и это пристрастие к англицизмам… Есть же уже терминология: «логические операции», «логический поиск», конъюнкцию, дизъюнкция… а тут «булинг» сплошной.) А для подстановочных знаков слово wildcard почему-то не вспомнили.)
1. Создание сборки путем добавления к главной детали второстепенных посредством нанесения сварных швов или просто добавления в сборку. И никак не иначе. Для крупных проектов количество уникальных сборок исчисляется сотнями и каждую сборку вырисовывать в отдельном окне — это трата времени и сил впустую. Т.е. создали каркас — добавили профили, пластины, подрезки, болты — из них собрали сборки
2. Сквозная нумерация деталей/сборок через префиксы. Реализованный нынешний подход — машиностороительный, он требует ручного изменения обзначений и наименований деталей/сборок. Сравнивать детали/сборки и нумероваться должна программа, а не вручную. Помните, что сборки идут сотнями, а детали и того больше
3. Нужны координатные оси. Все изготовленные отправочные марки должны монтироваться, для этого на монтажных схемах нужны оси и высотные отметки. Сейчас получаетчся, что в Ренге оси есть, но КМД нельзя сделать, в Компасе можно сделать деталировку, но осей нет
4. Режим выбора отдельных деталей и сборок для того, это позволит быстро скопировать (например связь или колонну) в другое место и видоизменить, получив ещё одну сборку
5. Если уж по ГОСТ и ЕСКД всё оформляется, то нужны готовые стандартные шаблоны ведомостей (отправочные марки, метизы и др.) с возможностью редактирования и сохранения пользовательских шаблонов. В разделе КМ в Компас-3D ведь есть ведомости, для КМД они тем более нужны.
6. Нужен фильтр по сборкам, деталям, материалам, болтам и иным элементам. Искать элементы в боковой панели крайне неудобно, тем более по одной штуке
7. Создание пластин не только через эскиз, а прямо в модели с возможностью прямого изменения толщины, длины, ширины, фасок
8. Возможность копирования, вращения, зеркального отбражения любой детали/сборки без связи с родительской детали/сборки. Т.е. отзеркалили сборку и перенесли её в другое место, где спозиционировали как необходимо
9. Параметрические узлы нужны, и их наработка после создания базовых иструментов для 3D-моделирования является первостепенной. Отсюда вытекает создание и сохранение пользовательских узлов.
Чем больше адекватных инструментов моделирования и параметрических узлов, тем больше у программы клиентов. Посмотреть, как всё подобное реализовано в других программных комплексах (Текла, Адванс стил), и сделать подобные необходимые инструменты не зазорно. Они в своей подавляющей массе повторяются и делают выполнение проектов быстрее и качественнее. Но это всё зарубежные, не родные