programacion - Optimización de jMonkey similar a Java3D
juegos hechos en java codigo (2)
Editar: para tener un dibujo en tiempo real, comenzó a usar lwjgl, que es la base de jmonkeyengine y jocl en una "interoperabilidad" entre opengl y opencl, ahora puede calcular y dibujar 100k de partículas en tiempo real. Tal vez la versión de manto del motor jmonkey puede curar este problema de sobrecarga de drawcall.
Durante varios días, he estado aprendiendo el motor jMonkey (ver: 3.0) en Eclipse (java 64 bit) y tratando de optimizar una escena usando GeometryBatchFactory.optimize(rootNode); mando.
Sin optimización (con capacidad de cambiar posiciones de esferas):
Bien, solo 1-fps tiene su origen tanto en el ancho de banda de pci-express como en la sobrecarga de jvm.
Con optimización (sin capacidad para cambiar las posiciones de las esferas):
Ahora es 29 fps incluso con un número de triángulo aumentado.
Java3D tenía un método setCapability() que hace que un objeto de escena pueda leerse / escribirse incluso en forma optimizada. jMonkey engine 3.0 debe ser capaz de este tema, pero no pude encontrar ningún rastro del mismo (los tutoriales y ejemplos buscados fallaron).
Pregunta: ¿Cómo puedo configurar las capacidades de read/write position/rotation/scale de los nodos optimized de una escena en jMonkey 3.0? Si no puede dar una respuesta a la primera pregunta, ¿puede decirme por qué el número de triángulos aumenta cuando uso el comando de optimización? ¿Tengo que crear un nuevo método para acceder a la tarjeta gráfica y cambiar las variables por mí mismo (quizás jog?)?
Información de escena: 16k partículas (esferas de 16x16 res) + 1 punto de luz (y su sombra de resolución 4096).
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, lo que toma 10 milisegundos (16k * 16k interacciones para calcular fuerzas). (No cambia nada en modo optimizado :() ¿Puede aparapi acceder a esos datos optimizados?
Para el caso de batchNode.batch(); optimización, aquí hay 1 fps de nuevo con números de objetos disminuidos:
El número de objeto ahora es solo varios cientos, ¡pero fps aún está en 1!
Enviar solo posiciones esféricas a GPU y dejar que calcule las posiciones de los vértices podría ser mejor que calcular los vértices en la CPU y enviar datos enormes a GPU.
¿Nadie aquí para ayudar? Ya probé batchNode pero no ayudó lo suficiente.
No quiero cambiar la api en 3D porque la gente de jMonkey ya reinventó la rueda y estoy contento con la situación actual. Solo trato de exprimir un poco más el rendimiento (cancelar sombras da% 100 de velocidad pero la calidad también es importante).
Este programa java se convertirá en un simulador de escena de impacto de asteroides (habrá elección de tamaño de asteroide, masa, velocidad, ángulo) con el algoritmo de marcha-cubos con LOD (serán millones de partículas).
El algoritmo de los cubos de marcha disminuiría en gran medida los números del triángulo. Si no puede responder a la pregunta, se aceptará cualquier algoritmo de marcha-cubos (o cualquier casco O (n) convexo) para Java. Datos: matrices x, y, z como fuente y matriz de bandas triangulares como objetivo (puntos de malla iso-superficie)
Gracias.
Aquí hay algunas muestras sobre la transmisión (con una resolución mucho más baja):
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 tenga una forma más suave:
4) El grupo forma una esfera (como se esperaba):
5) Entonces, un gran cuerpo estelar se acerca:
6) Acerca de tocar:
7) El momento del impacto:
Con la ayuda del algoritmo Barnes-Hutt y un potencial truncado, los números de partículas serán 10x (tal vez 100x) más.
En lugar del algoritmo de Marching-Cubes, un paño fantasma que envuelve al nbody 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á afectado por la tela que la envuelva. Nbody no se representará, pero la malla de tela se representará con un recuento de triange inferior.
Si MC o superior funciona, esto permitirá que el programa renderice un paño de envoltura para ~ 200x más partículas.
Existe un conjunto bastante sólido de documentación dentro de la wiki de JMonkeyEngine que habla bastante sobre cómo utilizar las transformaciones a las que se refiere, que se pueden encontrar aquí: Conceptos Espaciales Avanzados .
Además, hay bastante información sobre las mallas y su representación que puede ver aquí: Polígono Mallas .
Lo siento mucho....
Puede agrupar todas las Geometrías en una escena (o un subnodo) que permanezca estática .
El procesamiento por lotes significa que todas las geometrías con el mismo material se combinan en una malla. Esta optimización solo tiene un efecto si usa solo unos pocos (aproximadamente hasta 32) Materiales en total. El resultado es que el procesamiento por lotes tarda más tiempo cuando se inicializa el juego
El cambio en los triángulos, por lo tanto, se debe a que se han ensamblado todos en una sola malla ... La única sugerencia, si es necesaria, es tratar de obtener la malla y alterar los puntos sobre ella, pero en ese momento no creo que haga sentido.
Tal vez intente con un método de optimización diferente.
¡Buena suerte, no han usado JMonkey en un momento, pero están contentos de ver a otros hacer y su continuo crecimiento!
EDITAR
Por cierto, una forma de minimizar las matemáticas podría ser usar media esfera de cubos, un impacto en la tierra probablemente no afectaría al otro lado (a menos que la esfera no sea la tierra sino una pequeña muestra de la tierra tomada como una esfera)...
Tal vez intente una forma 2d como superficie de impacto, aunque sé que esta no será su mejor opción, podría darle una idea de cómo el número de formas puede tener un efecto y qué tan grande. Si lo hace, entonces podría ser una manera de considerar cómo eliminar algunas de las partículas, si no es así no necesita preocuparse. Estoy casi seguro de que lo hará.
Finalmente:
Tal vez no se rinden en tiempo real? Tómese un minuto para dibujar los cuadros en un búfer y luego juegue, para cuando juegue tendrá otros 40 marcos, etc. ... y tal vez lo que necesite sean aproximadamente 30 segundos.