Блог

Это то, что я должен сделать:

Создать приложение, подобное CAD, которое загружает облако точек (т. Е. тысячи 3D-точек, представляющих 3D-объект) из файла, позволяет пользователям манипулировать точками (т. Е. изменять форму, перемещая точки), выполнять множество вычислений точек по точкам (например, находить точки пересечения между линиями и поверхностями, определять, находится ли точка над или под поверхностью и т.д., измерять расстояния между точками или точки на поверхности и т.д.), А затем сохранять измененные точки в файл.

Он также предоставляет базовые функции пользовательского интерфейса, подобные CAD, такие как увеличение / уменьшение масштаба, панорамирование вида, поворот камеры и т.д.

Скорость является основной проблемой.

Вместо того, чтобы писать свои собственные функции для работы с матрицами и определять свои собственные классы точек / линий / поверхностей, я хотел бы использовать существующие библиотеки / API для выполнения этой работы.

Я знаю, что WPF, XNA и SlimDX предоставляют API для выполнения трехмерных геометрических вычислений, и все они, наконец, вызывают DirectX, но я просто новичок во всех из них. Мне интересно:

1. Какое из них (или какое-либо другое предложение) могло бы обеспечить лучшую производительность по скорости.

2. Насколько я понимаю, 3D-функции DirectX в основном связаны с игровой графикой / выводом на экран, подходит ли он также для вычислений на уровне данных (т. Е. используйте 3D-функции для манипулирования данными о точках, вычисления расстояний и т.д., Но не для вывода их на экран)? Под подходящим я подразумеваю, что если я создам тысячи вершин DirectX и выполню их mainpulse, будет ли это намного медленнее, чем использование моих собственных типов данных и структур? Пожалуйста, поправьте меня, если я неправильно понимаю.

3. Если я использую WPF, нужно ли мне также использовать XNA? Я как бы смешиваю эти две вещи.

4. Предполагается, что приложение должно запускаться на ПК исследовательской лаборатории, на котором нет мощной игровой карты отображения, значит ли это, что XNA не является предпочтительным?

5. Есть предложения по поводу технологий, которые следует использовать для этого приложения?

Спасибо!!

========обновить

Чтобы было понятнее, приложение загрузит ~ 108 000 точек в 3D, и каждая точка будет образовывать поверхности с другими смежными точками, так что задействовано примерно одинаковое количество 3D-поверхностей (я не создаю их одновременно). Я буду выполнять множество трехмерных геометрических и матричных вычислений с точками и поверхностями, таких как пересечение, интерполяция, преобразование и т.д., Поэтому скорость «вычислений» является моей главной заботой. Большую часть времени я буду выводить на экран только конечный результат, а рисунок в основном состоит из линий и точек, скорость «рисования» не вызывает большого беспокойства. таким образом, на самом деле это приложение, требующее большого количества графики, а приложение, требующее большого количества геометрических вычислений.

После прочтения ответа и комментариев я думаю о двух вариантах:

1. храните и вычисляйте данные с помощью примитивных типов данных и преобразуйте данные в структуры данных WPF / XNA / SlimDX при рисовании их на экране, или

2. используйте структуры данных этих API для хранения, вычисления и рисования всех этих точек.

какое из них лучше?

1. Честно говоря, если производительность является вашей главной заботой, я бы выбрал API, который максимально приближает вас к оборудованию. Меньше запутывания = больше скорости. В таком случае из предложенных вами вариантов лучшим является SlimDX, за которым следует XNA и, наконец, WPF.
2. Нет, DirectX должен использовать эффективные структуры данных и алгоритмы. Подумайте об этом — могли бы игры, использующие DirectX, запускаться с подходящей частотой кадров, если бы все вычисления DirectX были изначально медленными?
3. Нет, WPF и XNA являются взаимоисключающими. WPF — это платформа для создания отзывчивых и интуитивно понятных пользовательских интерфейсов. XNA, с другой стороны, является фреймворком для создания игр.
4. Не обязательно. На самом деле это означает, что WPF не является предпочтительным, поскольку WPF перенесет много работы на совместимые видеокарты. Если WPF не сможет найти подходящую видеокарту, процессор возьмет эту работу на себя, что приведет к снижению производительности.
5. Как я уже говорил ранее, для приложения с интенсивным использованием графики, такого как описанное вами, чем ближе вы сможете подобраться к аппаратному обеспечению, тем лучше. Native DirectX или SlimDX — хорошие варианты.

Рассматривали ли вы возможность разработки своей функциональности в качестве плагина для существующей среды CAD? AutoCAD, например, имеет очень мощный c sdk (ObjectARX), он также предоставляет управляемый .NET API. Вы можете использовать c # и WPF для разработки своих расширений. В нем есть существующие библиотеки геометрии, которые вы можете использовать повторно. Конечно, у AutoCAD есть своя цена, но есть альтернативы. Например, BricsCAD. Я не уверен, предоставляет ли BricsCAD .NET api, хотя.

Разработка приложения с нуля заняла бы недели, если не месяцы. Если бы я разрабатывал вашу функциональность как плагин AutoCAD, у меня бы ушел день.

Подумайте, действительно ли вам нужно развернуть собственную среду «CAD».

Несколько недель назад я проверил ограничения XNA. Я хочу знать, с каким количеством рекламных щитов (ускоренных графическим процессором) движок способен справиться. Результат: чистый XNA: 350 тыс. рекламных щитов XNA в качестве контекста рендеринга в WPF: 100 тыс. рекламных щитов

Я действительно не знаю, почему движок замедляется при рендеринге в элемент управления WinFormHost. Некоторая отладка показывает, что GraphcisDevice.Присутствует ()