Как ускорить марширование кубиков?


Я использую Этот марширующий кубический алгоритм для рисования 3D-изоповерхностей (перенесенных в C#, выводящих MeshGeomtry3D s, но в остальном то же самое). Полученные поверхности выглядят великолепно, но на их расчет уходит много времени.

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

Я рассматриваю двухпроходную систему, где образцы первого прохода пространство гораздо грубее, исключая объемы, где напряженность поля значительно ниже моего уровня изоляции. Разумно ли это? В чем заключаются подводные камни?

Edit: код был профилирован, и основная часть процессорного времени разделена между самой процедурой марширующих кубов и расчетом напряженности поля для каждого угла ячейки сетки. Полевые вычисления находятся вне моего контроля, поэтому ускорение процедуры кубов-мой единственный вариант...

Меня все еще тянет к идее попытаться устранить мертвых. пространство, так как это значительно уменьшило бы количество вызовов к обеим системам.

4 7

4 ответа:

Я знаю, что это немного устарело, но я недавно реализовал марширующие Кубы, основанные на том же самом источнике. Здесь очень много неэффективности. Как минимум, если вы делали что-то вроде

for (int x=0; x<densityArrayWidth; x++)
  for (int z=0; z<densityArrayLength; z++)
    for (int y=0; y<densityArrayHeight; y++)
      Polygonize(Gridcell, isolevel, Triangles)

Посмотрите, сколько раз вы будете перераспределять edgeTable и Tritable! Те сразу же должны перейти в общий класс. Я также выбросил объект gridCell, перейдя непосредственно от точек/значений к треугольникам.

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

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

Ускорение оценки базового поля (с тяжелой мемуаризацией), казалось, в основном решало проблемы производительности.

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

Каждый куб имеет 12 ребер, если вы проходите через каждый куб и находите 12 точек пересечения, вы делаете в 4 раза больше вычислений для точек пересечения - вы должны использовать только 3 ребра в левом нижнем углу каждого куба, с дополнительной строкой в правом верхнем углу зоны, а затем использовать специальное обновление для доступа ко всем найденным значениям. Я собираюсь сделать тему на эту тему, потому что это нужно обсудить, и это сложно.

Также, тестирование для областей в пространстве, которые нужны полигоны, оценивая уровень ISO с помощью Octree, и пропуская области, далекие от уровня ISO.

Я посмотрел на распространение, но оно не настолько надежно и эффективно.