vitaly_l писал(а):У вас есть BGRA - они используют процессор, поэтому медленно. OpenGL - понятно. А что есть третий вариант в чём секрет?
У BGRA очень плохое программирование, ресурсоёмкое. Как таковой оптимизации алгоритмов практически нет, в основном всё реашется в лоб. Кругом вещественная арифметика. При этом нет поддержки многопоточности, поэтому весь рендер изображения идёт на одном ядре процессора. Поэтому медленно.
OpenGL для вывода на экран сейчас фактически вне конкуренции, поскольку позволяет в полной мере задействовать аппаратные возможности видеокарты для построения изображения. Поэтому вывод на экран будем делать именно через него. Варианты типа DirectX и тому подобных, которые работают только на MS Windows не рассматриваются в виду того, что изначально ставится условие кроссплатформенности. Кстати, с точки зрения переноса кода между платформами Lazarus оказался очень хорошо. У нас был до этого опыт разработки приложений на Qt/С++, но там при переносе между платформами приходилось весьма много править под каждую платформу. А у Lazarus'а достаточно было поставить оболочку и необходимые библиотеки, после чего все наши тестовые проекты, в том числе с выводом 3Д графики, собрались и заработали без какой-либо дополнительной доработки.
Что касается третьего варианта, то нам необходим рендер с поддержкой прозрачности и сглаживания для вывода на печать или в растр изображений большого формата. OpenGL для этого, к сожалению, не очень подходит. То есть, теоретически с его помощью можно провести рендер в произвольный битмап, а не на экран, но там есть определённые ограничения и проблемы, типа невозможности задействовать графический ускоритель для растров, размер которых больше максимально поддерживаемого разрешения экрана. А у нас бывают чертежи размером в несколько метров, для которых необходимо обеспечить разрешение не ниже 300 dpi. Поэтому на данный момент предполагается сделать свой рендер для внутреннего метафайла, по логике работы напоминающий BGRA, но использующий многопоточность и более эффективные алгоритмы построения примитивов и сглаживания через целочисленную арифметику с фиксированной точкой. В связи с тем, что набор базовых примитивов у внутреннего метафайла не очень большой, то работа не такая уж сложная. Но мы ей планируем заниматься не прямо сейчас, а когда нам потребуется делать вывод на печать, то есть где-то через полгода.
vitaly_l писал(а):Я не нашёл там использование шейдеров видео карты силами OpenGl - это там есть?
А для чего в ZCad может потребоваться использование шейдеров?
veb86 писал(а):Когда человек работает в компании то понятно что все решения опираются на созданные ранее разработки, но когда люди в силу не желания разобраться с уже готовым кодом и влиться в команду, начинают переписывать все с нуля - это странно. Главное если проект провалится выложите исходники на изучение молодым. А так удачи в развитии BIM, жду отечественный ответ на возможности Revit.
Мы вполне отдаём себе отчёт в том, что имеющими силами нам Autodesk с их Revit'ом по функциональности не переплюнуть. Поэтому мы такую задачу себе и не ставили.
Что касается возможностей разобраться с готовым кодом, то я вас уверяю, что у нас достаточно квалификации, чтобы разобраться с любым кодом. Мне лично приходилось несколько раз участвовать в рефактоинге уже готовых чужих проектов для выпуска новой версии. И мы не переписываем всё с нуля. У нас есть масса собственных наработок, которые мы активно используем в своём проекте. Поэтому вопрос стоял не о том, чтобы написать всё с нуля, а в том, тратить ли время на изучение чужого кода, либо развивать свой до необходимого уровня. При этом мы и так на изучение имеющихся библиотек и проектов, включая упомянутый ZCad, потратили больше двух месяцев.