Edición: para tener un dibujo en tiempo real, comencé a usar lwjgl que es la base de jmonkeyengine y jocl en una "interoperabilidad" entre opengl y opencl, ahora puede calcular y dibujar 100k partículas en tiempo real. Tal vez la versión de manto del motor jmonkey puede curar este problema general.

Durante varios días, he estado aprendiendo jMonkey engine (ver: 3.0) en Eclipse (java 64 bit) y tratando de optimizar una escena usandoGeometryBatchFactory.optimize(rootNode); mando.

Sin optimización (con capacidad de cambiar posiciones de esferas):

De acuerdo, solo 1-fps se origina tanto en el ancho de banda pci-express como en la sobrecarga de jvm.

Con optimización (sin posibilidad de cambiar posiciones de esferas):

Ahora es de 29 fps, incluso con un mayor número de triángulo.

Java3D tenía unsetCapability() Método que permite que un objeto de escena se pueda leer / escribir incluso en una forma optimizada. El motor jMonkey 3.0 debe ser capaz de este tema, pero no pude encontrar ningún rastro de él (tutoriales y ejemplos buscados, fallidos).

Pregunta: Como puedo configurarread/write position/rotation/scale capacidades deoptimized Los nodos de una escena en jMonkey 3.0? Si no puede responder a la primera pregunta, ¿puede decirme por qué aumentan los números de triángulos cuando utilizo el comando de optimización? ¿Tengo que crear un nuevo método para acceder a la tarjeta gráfica y cambiar las variables yo mismo (jogl quizás?)?

Información de la escena: 16k partículas (esferas de 16x16 res) + 1 punto de luz (y su 4096 sombras con resolución).

Estoy seguro de que podemos enviar varios miles de números flotantes en un milisegundo a través de pci-express con facilidad.

Información adicional: Estoy usando Aparapi-kernels para actualizar las posiciones de las partículas que demoran 10 milisegundos (16k * 16k interacciones para calcular fuerzas). (No cambia nada en modo optimizado :() ¿Puede aparapi acceder a esos datos optimizados?

Para el caso debatchNode.batch(); optimización, aquí hay 1 fps de nuevo con números de objeto reducidos:

El número de objeto ahora es solo de varios cientos, ¡pero fps aún está en 1!

Enviar solo posiciones de esfera a gpu y dejar que calcule las posiciones de los vértices podría ser mejor que calcular los vértices en la CPU, además de enviar datos enormes a gpu.

¿Nadie aquí para ayudar? Ya probé batchNode pero no ayudó lo suficiente.

No quiero cambiar la API 3D porque la gente de jMonkey ya reinventó la rueda y estoy feliz con la situación actual. Solo trato de exprimir un poco más el rendimiento (la cancelación de las sombras proporciona una velocidad de 100%, pero la calidad también es importante).

Este programa Java se convertirá en un simulador de escena de impacto de asteroides (habrá elección del tamaño, masa, velocidad, ángulo del asteroide) con algoritmo de cubos de marcha con LOD (habrá millones de partículas).

El algoritmo de cubos de marcha disminuiría considerablemente los números de triángulos. Si no puede responder la pregunta, ¡se aceptará cualquier algoritmo de cubos de marcha (o cualquier casco convexo O (n)) para Java! Datos: arrays x, y, z como origen y array-triángulo-tira como objetivo (puntos de malla iso-superficie)

Gracias.

Aquí hay algunos ejemplos sobre la transmisión (con una resolución mucho menor):

1) Colapso de un grupo de rocas en forma de cubo por gravitación:

2) La fuerza de exclusión comienza a mostrarse:

3) La fuerza de exclusión + gravitación hace que el grupo forme una forma más suave:

4) El grupo forma una esfera (como se espera):

5) Entonces, un gran cuerpo estelar se acerca:

6) A punto de tocar:

7) El momento de impacto:

Con la ayuda del algoritmo de Barnes-Hutt y un potencial truncado, los números de partículas serán 10x (quizás 100x) más.

En lugar del algoritmo de Marching-Cubes, una tela fantasma que envuelve al cuerpo puede dar un casco de baja resolución (más fácil que BH pero necesita más cálculos)

La tela fantasma se verá afectada por nbody (gravedad + exclusión), pero nadie se verá afectada por la tela que la envuelve. Nbody no se procesará, pero la malla de tela se renderizará con un recuento de triange inferior.

Si el MC o superior funciona, esto permitirá que el programa genere un envoltorio para ~ 200x más partículas.