Оптимизация jMonkey похожа на Java3D

Изменить: для рисования в реальном времени, начал использовать lwjgl, который является базой jmonkeyengine и jocl в "интероперабельности" между opengl и opencl, теперь может вычислять и рисовать 100k частиц в реальном времени. Возможно, мантийная версия движка jmonkey может вылечить эту проблему накладной drawcall.

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

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

Хорошо, только 1-fps возникает из-за полосы пропускания pci-express + jvm.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо.

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

1) Свертывание кубической рок-группы гравитацией:

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

3) Сила исключения + гравитация заставляет группу образовывать более гладкую форму:

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

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

6) О прикосновении:

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

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

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

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

<Т411 >

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

Ответы

Ответ 1

Так жаль....

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

Пакетирование означает, что все геометрии с одним и тем же материалом объединены в одну сетку. Эта оптимизация действует только в том случае, если вы используете только несколько (примерно до 32) материалов. Окупаемость заключается в том, что дозатор получает дополнительное время, когда игра инициализируется

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

Возможно, попробуйте другой метод оптимизации.

Удачи, немного не использовали JMonkey, но рад видеть, что другие делают и продолжают расти!

ИЗМЕНИТЬ

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

Возможно, попробуйте 2d-форму как поверхность удара, хотя я знаю, что это не ваш лучший выбор, это может дать вам представление о том, как количество фигур может повлиять и насколько велико. Если это так, то проспект может состоять в том, чтобы рассмотреть, как удалить некоторые из частиц, если это вам не нужно беспокоиться. Я почти уверен, что это будет.

Наконец:

Возможно, в реальном времени не отображается? Потратьте минутку, чтобы нарисовать кадры в буфер, а затем сыграйте, к тому времени, когда вы сыграете, у вас будет еще 40 кадров и т.д.... и, возможно, около 30 секунд стоит все, что вам нужно.

Ответ 2

В вики JMonkeyEngine имеется довольно солидный набор документации, в котором довольно много говорится о том, как использовать преобразования, о которых вы говорите, которые можно найти здесь: Продвинутые пространственные концепции.

Кроме того, имеется довольно немного информации о сетках и их рендеринге, которые вы можете посмотреть здесь: Полигонные сетки.