optimisation jMonkey similaire à Java3D

Edit: pour avoir un dessin en temps réel, a commencé à utiliser lwjgl qui est la base de jmonkeyengine et jocl dans une" interopérabilité " entre opengl et opencl, peut maintenant calculer et dessiner des particules 100k en temps réel. Peut-être que la version mantle de jmonkey engine peut guérir ce problème de surcharge drawcall.

Depuis plusieurs jours, j'apprends jmonkey engine (ver:3.0) dans Eclipse (java 64 bits)et j'essaie d'optimiser une scène en utilisant la commande GeometryBatchFactory.optimize(rootNode);.

Sans optimisation (avec possibilité de changer les positions des sphères):

D'accord, seulement 1-fps provient à la fois de la bande passante PCI-express et de la surcharge jvm.

Avec optimisation (sans possibilité de changer les positions des sphères):

Maintenant, il est de 29 fps même avec un nombre de triangle accru.

Java3D avait une méthode setCapability() qui permet à un objet scène d'être lu / écrit même sous une forme optimisée. jmonkey engine 3.0 doit être capable de ce sujet mais je n'ai trouvé aucune trace de celui-ci(tutoriels et exemples recherchés, échoué).

Question: Comment puis-je régler read/write position/rotation/scale capacités de optimized nœuds d'une scène dans jMonkey 3.0? Si vous ne pouvez pas donner une réponse à la première question, Pouvez-vous me dire pourquoi les nombres de triangle augmentent lorsque j'utilise la commande d'optimisation? Dois-je créer une nouvelle méthode pour accéder à la carte graphique et changer les variables moi-même (jogl peut-être?)?

Scène informations: 16 K particules (sphères de 16x16 res) + 1 point de lumière(et son 4096 resolutioned ombre).

Je suis sûr que nous pouvons envoyer plusieurs milliers de nombres flottants en une milliseconde via pci-express avec facilité.

• informations supplémentaires: J'utilise Aparapi-kernels pour mettre à jour particle positions qui prend 10 millisecondes (interactions 16k * 16k pour calculer les forces).(ne change rien en mode optimisé :( ) Aparapi peut-il Accéder à ces données optimisées?

Pour le cas de l'optimisation batchNode.batch();, Voici 1 fps encore une fois avec des nombres d'objets réduits:

Le nombre D'objets n'est plus que de plusieurs centaines mais fps est toujours à 1!

Envoyer juste des positions de sphère au gpu et le laisser calculer les positions de sommet pourrait être mieux que de calculer des sommets sur le cpu plus d'envoyer des données énormes au gpu.

Personne ici pour aider? Déjà essayé batchNode mais n'a pas aidé assez.

Je ne veux pas changer l'api 3d car les gens de jMonkey ont déjà réinventé la roue et je suis heureux avec situation actuelle. Juste essayer de presser un peu plus de performance (annuler les ombres donne % 100 vitesse mais la qualité est importante aussi!).

Ce programme java deviendra un simulateur de scène d'impact d'astéroïdes (il y aura le choix de la taille de l'astéroïde, la masse, la vitesse, l'angle) avec l'algorithme marching-cubes avec LOD(sera des millions de particules).

L'algorithme Marching-cubes diminuerait considérablement les nombres de triangle. Si vous ne pouviez pas donner de réponse à la question, des cubes de marche (ou tout O (N) coque convexe) algorithme pour java sera accepté! Données: X, Y, Z tableaux comme source et triangle-strip-array comme cible (iso-surface mesh points)

Merci.

Voici quelques exemples sur le flux (avec une résolution beaucoup plus faible):

1) effondrement d'un groupe de roches en forme de cube par gravitation:

2) La Force D'Exclusion commence à se montrer:

3) Force D'Exclusion + gravitation rend le groupe forme une forme plus lisse:

4) Groupe forme une sphère(comme prévu):

5) ensuite, un grand corps stellaire s'approche:

6) sur le point de toucher:

7) le moment de l'impact:

Avec l'aide de l'algorithme Barnes-Hutt et d'un potentiel tronqué, le nombre de particules sera 10x(peut-être 100x) de plus.

Plutôt que l'algorithme Marching-Cubes, un tissu fantôme qui enveloppe le nbody peut donner une coque à faible résolution (plus facile que BH mais nécessite plus de calcul)

Fantôme tissu sera affectée par nbody (gravité + exclusion) mais nbody ne sera pas affecté par le tissu qui l'enveloppe. Nbody ne sera pas rendu mais la maille de tissu sera rendue avec un nombre de trianges inférieur.

Si MC ou ci-dessus fonctionne, cela permettra au programme de rendre un chiffon d'emballage pour ~200X plus de particules.