Мы много лет состоим с Алексеем Павловичем в отношениях взаимного уважения и дружбы ))) В данном случае ситуация действительно была критической для конструкторов, и эмоции взяли верх. Мы понимаем.
Для образовательных задач предоставляется академическая лицензия на все компоненты C3D Toolkit. Подробнее здесь c3dlabs.com/ru/info/education
Если такое сотрудничество интересно, напишите на info@c3dlabs.com.
Вопрос цены мы обсуждаем индивидуально. В том числе учитываем, на каком этапе разработки находится продукт заказчика, по какой модели будет продаваться.
Закрывать движок в наши планы не входит. Смысл нашей работы и состоит в том, чтобы дать разработчикам САПР удобный и полезный инструмент.
C3D Vision — достаточно молодой компонент в линейке C3D Toolkit. Пока реализована поддержка Windows и Linux. Я думаю, это даже к счастью, что мы еще не реализовали поддержку iOS (с Metal), что позволит нам проанализировать некоторые подходы для дальнейшей его поддержки. В любом случае, нас это не пугает, т.к. C3D Vision имеет модульную основу, что позволяет разработать отдельный плагин для поддержки того или иного отрисовщика, в том числе и Metal, не модифицируя остальные модули движка.
Как я отмечал в ответе на предыдущий комментарий, реализация плагина отрисовщика занимает незначительную часть по отношению ко всему движку, но, естественно, будет необходим потратить определенное время на изучение Metal, т.к. мы с ним не работали, тут никуда не денешься.
«Нет, свою математику мы не писали, т.к. решение OpenGL является стандартом практически для всех ОС и смысла в этом нет.
Обертка — слово неподходящее, это все же движок, со своим функционалом, оптимизацией, а также инструментарием. Что такое “Обертка”? Если говорить простым языком, в большинстве случаев это промежуточный слой между прикладной программой и другой библиотекой или интерфейсом другого API, цель обертки — упростить и сделать более удобной работу конечного пользователя, но есть и др. цели. Тут разработан именно движок, а обертка над стандартной библиотекой OpenGL занимает объем не более 3-6% от всего кода. Поверьте, что и тут достаточно работы, чтобы сделать ориентированный визуализатор в данной области. И самое главное — разработать необходимый набор функционала, которого не ни в OpenGL, ни в DirectX, и вряд ли когда появится.
Для ясности привожу примеры: как и в большинстве движков, разработано представление сцены в виде графа, который не имеет отношение к OpenGL и DirectX. Также много механизмов оптимизации LOD, Frustum culling, …, которые не связаны с этими библиотеками, ну а про привязки, локаторы, манипуляторы и, как следствие, собственную событийную модель или поддержку физических устройств я уже говорить не буду. Тем не менее в данной библиотеке присутствует всего лишь два класса, которые выполняют роль оболочки и реализовывают перевызов нескольких функций из OpenGL. Хочу также отметить, что на создание подобных движков уходят годы работы не одного человека, а целой группы. Короче, все зависит от потребности, если вам не обходимо визуализировать кубик — это одно, если мы говорим о библиотеке с большим множеством решений — это совершенно другой расклад. Спасибо за ваше внимание, мы всегда готовы дать максимально развернутый ответ на ваши вопросы».
цитируем ответ автора: «В КОМПАС-3D Viewer нет аннотирования, он открывает только файлы КОМПАС, для просмотра сборки нужно найти в БД и выгрузить все файлы сборки».
Учитывая, что вы затеяли обсуждение КОМПАС-3D в комментариях под статьей о C3D Toolkit, позвольте сделать небольшое уточнение.
Группа компаний АСКОН имеет в своей структуре несколько подразделений (читай — самостоятельных компаний), которые занимаются разработкой и продвижением на рынке различных программных продуктов. Система трехмерного моделирования КОМПАС-3D — одно из флагманских решений, но не единственное. Есть и другое программное обеспечение в портфеле АСКОН.
Как уже было сказано ранее, компания C3D Labs была образована из математической группы разработки КОМПАС-3D в Коломне. Сейчас мы занимаемся созданием программных компонентов C3D Modeler, C3D Solver, C3D Vision и C3D Converter. Эти компоненты используются уже не конечными пользователями, а разработчиками CAx-систем. То есть мы, программисты, делаем продукт для таких же, как мы, программистов.
Геометрическое ядро C3D Modeler, о котором шла речь в статье — это библиотека, которую можно использовать для моделирования и расчетов. При этом мы уже несколько лет разрабатываем собственный движок для визуализации, адаптированный под специфику САПР — C3D Vision. На сегодняшний день он не используется в КОМПАС-3D.
Собственно, с нашей визуализацией может ознакомиться любой желающий, бесплатно скачав приложение C3D Viewer. Для этого необходимо перейти по ссылке, заполнить небольшую форму и на указанный адрес в автоматическом режиме будут высланы данные для скачивания. Приложение умеет читать форматы STEP, IGES, X_T (X_B), SAT, STL, VRML, C3D и может сохранять модели в C3D. Кстати, именно с его помощью было сделано изображение велосипеда, спроектированного в КОМПАС-3D.
Бесплатное приложение C3D Viewer
Для работы с большими сборками необходимо настроить параметры в разделе Performance.
Функциональность САПР и функциональность геометрического ядра — это немного разные понятия. Реализовать в пользовательском приложении построение образующей тела вращения в эскиз за одно действие вполне можно с помощью C3D Modeler. Более того, для любой поверхности движения (в том числе и вращения) можно получить образующую, а потом спроецировать и параметризовать ее, например наложив размер. Вот вам ссылка на соответствующий раздел в документации по ядру.
Общение человека с кривой пересечения (допустим, двух NURBS поверхностей) происходит следующим образом: человек сообщает кривой пресечения значение параметра, а кривая выдает точку в пространстве, соответствующую этому параметру.
То есть в кривой пересечения лежит некоторая информация (это не обязательно множество точек; могут лежать пересекаемые поверхности и некоторые данные о параметре кривой), которая позволяет рассчитать точку на пересечении поверхностей с максимальной машинной точностью, выше которой не имеет смысла уточнять.
Никаких кусочно-линейных представлений, кубических кривых, аппроксимационных кривых в кривой пересечения нет. Кривая пересечения поверхностей — это объект, который для указанного параметра выдает точку в пространстве (как и все другие кривые).
Надеемся, это пояснение ответит вопрос о точности кривой пересечения.
Спасибо за интересный комментарий. Попробуем ответить на ваши вопросы по порядку:
Нужно уточнить, что значит «масштабируемость», и что значит «дефекты».
«Масштабируемость» означает, что при любом масштабе изображение будет настолько гладким, насколько гладкая сама модель. Круглое всегда остаётся круглым, угол — углом. Под «дефектом» же подразумевается нарушение изложенного принципа.
Полигональный меш (faces) можно масштабировать без дефектов, т. к. это векторное представление. И, на самом деле, как это указано далее, на экране мы все равно видим полигональный меш, даже если геометрическое ядро использует NURBS.
Информация о форме геометрической модели в граничном представлении задаётся аналитически. Точность её отображения на экране определяется на уровне приложения и расчёт мешей производится таким образом, чтобы модель визуально казалась гладкой. Если мы возьмём исходную полигональную модель, то, вне зависимости от выбранной САПР, при увеличении масштаба мы сперва увидим увеличивающиеся треугольники, а затем модель станет угловатой. Ограничение в этом случае задаётся на уровне 3D-модели — с какой точностью изначально был рассчитан меш, например при записи STL, с такой точностью нам и придется работать дальше.
Сетка из треугольников для работы с чертежами не подходит — на чертеже нужны гладкие и чёткие контуры, а сетка создаст визуальную грязь.
Опять же, здесь нет ясности, почему она не подходит, ведь на экране мы все равно ее же и видим, хотелось бы понять, чем чертеж отличается от изображения на экране.
Рассмотрим куб. При проецировании его граничного представления на плоскость получаем квадрат. В случае с полигональным представлением мы увидим при проецировании квадрат с диагональю. Теперь представьте проецирование цилиндра в чертёж. Диагоналей будет гораздо больше. Они и образуют ту визуальную грязь, о которой упоминалось выше:
Кстати, обратите внимание на автоматически проставляемый размер в КОМПАС-3D, который для шара в полигональном формате STL (проекция слева) отобразился с погрешностью.
Хотелось бы понять, чем чертеж отличается от изображения на экране (насколько мне удалось понять, тот же SolidWorks выводит в dxf кусочно-линейное представление при экспорте чертежа). Стоит ли ожидать, что при экспорте из КОМПАС в какой-либо векторный формат мы увидим чистые кривые NURBS?
КОМПАС-3D при экспорте кривых в векторные форматы (в том числе при экспорте чертежей) в общем случае передает именно NURBS, а не кусочно-линейное представление.
Движение управляющих органов станка с числовым программным управлением, который работает с 3D-моделью, намного проще задавать с помощью математических формул.
Насколько это реализуемо в действительности? Есть какие-либо форматы CAM (G-Code, например), которые принимают хотя бы NURBS в качестве исходных данных? Насколько мне известно, G-CODE может делать окружности и полярную систему координат.
Речь идёт о том, что при наличии граничного представления модели, при желании, можно построить более точную траекторию режущего инструмента. При полигональном представлении модели этого сделать нельзя, так как исходная информация о форме изготавливаемого объекта отсутствует и заменена приближенной.
Если говорить о технической стороне разработки программ, то наши друзья из компании DP Technology (разработчики CAM-системы ESPRIT) подсказывают, что им встречались публикации, в которых отдельные энтузиасты предлагали собственные версии G-кода, способного выполнять «NURBS interpolation». Это может быть полезно для 5-осевых операций, так как значительно сокращается траектория движения инструмента и, соответственно, уменьшается размер управляющей программы для станка с ЧПУ. Но пока это всё остаётся в области науки.
И насколько верно то, что граничное представление на основе NURBS является точным?
В граничном представлении NURBS кривые и поверхности точно проходят по заданным дискретным местам пространства (точкам или кривым), в остальных точках пространства к ним предъявляется требование гладкости и только. Так как исходные данные для построения NURBS объектов являются дискретными, то NURBS кривые и поверхности в граничном представлении считаются точными, потому что они точно соответствуют исходным требованиям. Более того, NURBS объектами можно точно представить форму почти всех аналитических кривых и поверхностей (очень громоздко, но можно). Всё, для чего известны аналитические законы, в граничном представлении описывается другими объектами, например, кривыми и поверхностями второго порядка. Для объектов, которые не поддаются аналитическому описанию, граничное представление использует специальные приёмы. Так, для точного описания кривой пересечения двух кубических NURBS поверхностей применяются итерационные методы: кривая пересечения представляется набором точек, которые служат начальными приближениями для определения положения точки кривой пересечения с требуемой точностью. Таким образом, положение точек кривой пересечения при каждом обращении к кривой насчитывается заново итерационными методами по лежащей в кривой информации.
Если такое сотрудничество интересно, напишите на info@c3dlabs.com.
Закрывать движок в наши планы не входит. Смысл нашей работы и состоит в том, чтобы дать разработчикам САПР удобный и полезный инструмент.
C3D Vision — достаточно молодой компонент в линейке C3D Toolkit. Пока реализована поддержка Windows и Linux. Я думаю, это даже к счастью, что мы еще не реализовали поддержку iOS (с Metal), что позволит нам проанализировать некоторые подходы для дальнейшей его поддержки. В любом случае, нас это не пугает, т.к. C3D Vision имеет модульную основу, что позволяет разработать отдельный плагин для поддержки того или иного отрисовщика, в том числе и Metal, не модифицируя остальные модули движка.
Как я отмечал в ответе на предыдущий комментарий, реализация плагина отрисовщика занимает незначительную часть по отношению ко всему движку, но, естественно, будет необходим потратить определенное время на изучение Metal, т.к. мы с ним не работали, тут никуда не денешься.
«Нет, свою математику мы не писали, т.к. решение OpenGL является стандартом практически для всех ОС и смысла в этом нет.
Обертка — слово неподходящее, это все же движок, со своим функционалом, оптимизацией, а также инструментарием. Что такое “Обертка”? Если говорить простым языком, в большинстве случаев это промежуточный слой между прикладной программой и другой библиотекой или интерфейсом другого API, цель обертки — упростить и сделать более удобной работу конечного пользователя, но есть и др. цели. Тут разработан именно движок, а обертка над стандартной библиотекой OpenGL занимает объем не более 3-6% от всего кода. Поверьте, что и тут достаточно работы, чтобы сделать ориентированный визуализатор в данной области. И самое главное — разработать необходимый набор функционала, которого не ни в OpenGL, ни в DirectX, и вряд ли когда появится.
Для ясности привожу примеры: как и в большинстве движков, разработано представление сцены в виде графа, который не имеет отношение к OpenGL и DirectX. Также много механизмов оптимизации LOD, Frustum culling, …, которые не связаны с этими библиотеками, ну а про привязки, локаторы, манипуляторы и, как следствие, собственную событийную модель или поддержку физических устройств я уже говорить не буду. Тем не менее в данной библиотеке присутствует всего лишь два класса, которые выполняют роль оболочки и реализовывают перевызов нескольких функций из OpenGL. Хочу также отметить, что на создание подобных движков уходят годы работы не одного человека, а целой группы. Короче, все зависит от потребности, если вам не обходимо визуализировать кубик — это одно, если мы говорим о библиотеке с большим множеством решений — это совершенно другой расклад. Спасибо за ваше внимание, мы всегда готовы дать максимально развернутый ответ на ваши вопросы».
Группа компаний АСКОН имеет в своей структуре несколько подразделений (читай — самостоятельных компаний), которые занимаются разработкой и продвижением на рынке различных программных продуктов. Система трехмерного моделирования КОМПАС-3D — одно из флагманских решений, но не единственное. Есть и другое программное обеспечение в портфеле АСКОН.
Как уже было сказано ранее, компания C3D Labs была образована из математической группы разработки КОМПАС-3D в Коломне. Сейчас мы занимаемся созданием программных компонентов C3D Modeler, C3D Solver, C3D Vision и C3D Converter. Эти компоненты используются уже не конечными пользователями, а разработчиками CAx-систем. То есть мы, программисты, делаем продукт для таких же, как мы, программистов.
Геометрическое ядро C3D Modeler, о котором шла речь в статье — это библиотека, которую можно использовать для моделирования и расчетов. При этом мы уже несколько лет разрабатываем собственный движок для визуализации, адаптированный под специфику САПР — C3D Vision. На сегодняшний день он не используется в КОМПАС-3D.
Собственно, с нашей визуализацией может ознакомиться любой желающий, бесплатно скачав приложение C3D Viewer. Для этого необходимо перейти по ссылке, заполнить небольшую форму и на указанный адрес в автоматическом режиме будут высланы данные для скачивания. Приложение умеет читать форматы STEP, IGES, X_T (X_B), SAT, STL, VRML, C3D и может сохранять модели в C3D. Кстати, именно с его помощью было сделано изображение велосипеда, спроектированного в КОМПАС-3D.
То есть в кривой пересечения лежит некоторая информация (это не обязательно множество точек; могут лежать пересекаемые поверхности и некоторые данные о параметре кривой), которая позволяет рассчитать точку на пересечении поверхностей с максимальной машинной точностью, выше которой не имеет смысла уточнять.
Никаких кусочно-линейных представлений, кубических кривых, аппроксимационных кривых в кривой пересечения нет. Кривая пересечения поверхностей — это объект, который для указанного параметра выдает точку в пространстве (как и все другие кривые).
Надеемся, это пояснение ответит вопрос о точности кривой пересечения.
«Масштабируемость» означает, что при любом масштабе изображение будет настолько гладким, насколько гладкая сама модель. Круглое всегда остаётся круглым, угол — углом. Под «дефектом» же подразумевается нарушение изложенного принципа.
Информация о форме геометрической модели в граничном представлении задаётся аналитически. Точность её отображения на экране определяется на уровне приложения и расчёт мешей производится таким образом, чтобы модель визуально казалась гладкой. Если мы возьмём исходную полигональную модель, то, вне зависимости от выбранной САПР, при увеличении масштаба мы сперва увидим увеличивающиеся треугольники, а затем модель станет угловатой. Ограничение в этом случае задаётся на уровне 3D-модели — с какой точностью изначально был рассчитан меш, например при записи STL, с такой точностью нам и придется работать дальше.
Рассмотрим куб. При проецировании его граничного представления на плоскость получаем квадрат. В случае с полигональным представлением мы увидим при проецировании квадрат с диагональю. Теперь представьте проецирование цилиндра в чертёж. Диагоналей будет гораздо больше. Они и образуют ту визуальную грязь, о которой упоминалось выше:
Кстати, обратите внимание на автоматически проставляемый размер в КОМПАС-3D, который для шара в полигональном формате STL (проекция слева) отобразился с погрешностью.
КОМПАС-3D при экспорте кривых в векторные форматы (в том числе при экспорте чертежей) в общем случае передает именно NURBS, а не кусочно-линейное представление.
Речь идёт о том, что при наличии граничного представления модели, при желании, можно построить более точную траекторию режущего инструмента. При полигональном представлении модели этого сделать нельзя, так как исходная информация о форме изготавливаемого объекта отсутствует и заменена приближенной.
Если говорить о технической стороне разработки программ, то наши друзья из компании DP Technology (разработчики CAM-системы ESPRIT) подсказывают, что им встречались публикации, в которых отдельные энтузиасты предлагали собственные версии G-кода, способного выполнять «NURBS interpolation». Это может быть полезно для 5-осевых операций, так как значительно сокращается траектория движения инструмента и, соответственно, уменьшается размер управляющей программы для станка с ЧПУ. Но пока это всё остаётся в области науки.
В граничном представлении NURBS кривые и поверхности точно проходят по заданным дискретным местам пространства (точкам или кривым), в остальных точках пространства к ним предъявляется требование гладкости и только. Так как исходные данные для построения NURBS объектов являются дискретными, то NURBS кривые и поверхности в граничном представлении считаются точными, потому что они точно соответствуют исходным требованиям. Более того, NURBS объектами можно точно представить форму почти всех аналитических кривых и поверхностей (очень громоздко, но можно). Всё, для чего известны аналитические законы, в граничном представлении описывается другими объектами, например, кривыми и поверхностями второго порядка. Для объектов, которые не поддаются аналитическому описанию, граничное представление использует специальные приёмы. Так, для точного описания кривой пересечения двух кубических NURBS поверхностей применяются итерационные методы: кривая пересечения представляется набором точек, которые служат начальными приближениями для определения положения точки кривой пересечения с требуемой точностью. Таким образом, положение точек кривой пересечения при каждом обращении к кривой насчитывается заново итерационными методами по лежащей в кривой информации.