Изменить: Для того, чтобы иметь рисование в реальном времени, начал использовать lwjgl, который является основой jmonkeyengine и jocl в «совместимости» между opengl и opencl, теперь может рассчитывать и рисовать 100 000 частиц в режиме реального времени. Возможно, мантийная версия движка jmonkey может решить эту проблему, связанную с дополнительными вызовами.

В течение нескольких дней я изучал движок jMonkey (версия: 3.0) в Eclipse (64-битная версия Java) и пытался оптимизировать сцену с помощьюGeometryBatchFactory.optimize(rootNode); команда.

Без оптимизации (с возможностью изменения положения сфер):

Ладно, только 1-fps происходит из-за пропускной способности pci-express + издержек jvm.

С оптимизацией (без возможности менять позиции шаров):

Теперь это 29 кадров в секунду даже с увеличенным числом треугольников.

Java3D имелsetCapability() метод, который делает объект сцены доступным для чтения / записи даже в оптимизированной форме. JMonkey Engine 3.0 должен быть способен к этой теме, но я не мог найти его след (поиск учебников и примеров, не удалось).

Вопрос: Как я могу установитьread/write position/rotation/scale возможностиoptimized узлы сцены в jMonkey 3.0? Если вы не можете дать ответ на первый вопрос, можете ли вы сказать мне, почему числа треугольников увеличиваются, когда я использую команду оптимизации? Нужно ли создавать новый метод для доступа к видеокарте и изменения переменных самостоятельно (возможно, jogl?)?

Информация о сцене: 16k частиц (сферы размером 16x16) + 1 точечный свет (и разрешенная тень 4096).

Я уверен, что мы можем с легкостью отправить несколько тысяч чисел с плавающей запятой за миллисекунду через pci-express.

Дополнительная информация: Я использую Aparapi-kernels для обновления позиций частиц, что занимает 10 миллисекунд (16k * 16k взаимодействий для расчета сил). (Ничего не меняет в оптимизированном режиме :() Может ли aparapi получить доступ к этим оптимизированным данным?

Для случаяbatchNode.batch(); Оптимизация, здесь снова 1 кадр в секунду с уменьшенными номерами объектов:

Номер объекта теперь только несколько сотен, но fps по-прежнему равен 1!

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

Никто здесь не поможет? Уже пробовал batchNode, но не помогло достаточно.

Я не хочу менять 3d api, потому что jMonkey люди уже заново изобрели колесо, и я доволен текущей ситуацией. Просто пытаюсь немного увеличить производительность (отмена теней дает 100% скорости, но качество тоже важно!).

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

Алгоритм марширующих кубов значительно уменьшит число треугольников. Если вы не смогли дать ответ на вопрос, то для java будут приняты любые алгоритмы марширующих кубов (или любой O (n) выпуклой оболочки)! Данные: массивы x, y, z в качестве источника и массив треугольных полос в качестве цели (точки сетки изоповерхности)

Благодарю.

Вот несколько примеров потока (с гораздо более низким разрешением):

1) Разрушение горной группы в форме куба под действием силы тяжести:

2) Сила отчуждения начинает проявляться:

3) Сила отчуждения + гравитация делают группу более гладкой:

4) Группа образует сферу (как и ожидалось):

5) Затем приближается большое звездное тело:

6) Прикоснуться к:

7) Момент удара:

С помощью алгоритма Барнса-Хатта и усеченного потенциала число частиц будет в 10 раз (может быть, в 100 раз) больше.

Вместо алгоритма Marching-Cubes, призрачная ткань, которая оборачивает nbody, может дать оболочку с низким разрешением (проще, чем BH, но требует большего количества вычислений)

На призрачную ткань будет воздействовать nbody (сила тяжести + исключение), но на nbody не будет влиять ткань, которая ее оборачивает. Никто не будет визуализирован, но сетка будет отображаться с меньшим количеством треугольников.

Если MC или выше работает, это позволит программе визуализировать упаковочную ткань для ~ 200x больше частиц.