編集：リアルタイム描画を行うために、openglとopenclの間の「相互運用性」でjmonkeyengineとjoclのベースであるlwjglの使用を開始し、100k個の粒子をリアルタイムで計算して描画できるようになりました。たぶん、jmonkeyエンジンのマントルバージョンは、このドローコールオーバーヘッドの問題を解決することができます。
数日間、Eclipse（java 64ビット）でjMonkeyエンジン（ver：3.0）を学び、GeometryBatchFactory.optimize(rootNode);コマンドを使用してシーンを最適化する方法を試してきました。
最適化なし（球の位置を変更する機能あり）：
さて、1fpsのみがpci-express帯域幅とjvmオーバーヘッドの両方から発生します。
最適化あり（球の位置を変更する機能なし）：
三角数を増やしても29fpsになりました。
Java3DにはsetCapability()、最適化された形式でもシーンオブジェクトを読み書きできるようにするメソッドがありました。jMonkey engine 3.0はこの主題に対応している必要がありますが、その痕跡は見つかりませんでした（チュートリアルと例を検索しましたが、失敗しました）。
質問： jMonkey 3.0でシーンread/write position/rotation/scaleのノードの機能を設定するにはどうすればよいですか？optimized最初の質問に答えられない場合、最適化コマンドを使用すると三角数が増える理由を教えてください。グラフィックカードにアクセスして変数を自分で変更するための新しいメソッドを作成する必要がありますか（joglかもしれませんか？）？
シーン情報：16kパーティクル（16x16解像度の球）+ 1ポイントライト（およびその4096の解像度のシャドウ）。
pci-expressを介して、ミリ秒で数千のフロート番号を簡単に送信できると確信しています。
- 追加情報：10ミリ秒かかる粒子位置を更新するためにAparapi-kernelsを使用しています（力を計算するために16k * 16kの相互作用）（最適化モードでは何も変更されません:(）aparapiはそれらの最適化されたデータにアクセスできますか？
最適化の場合、batchNode.batch();オブジェクト番号を減らした1fpsを次に示します。
オブジェクト数は数百になりましたが、fpsはまだ1です！
球の位置だけをgpuに送信し、頂点の位置を計算させる方が、cpuで頂点を計算し、さらに巨大なデータをgpuに送信するよりも優れている可能性があります。
誰も助けてくれませんか？すでにbatchNodeを試しましたが、十分に役立ちませんでした。
jMonkeyの人々はすでに車輪の再発明を行っており、現在の状況に満足しているため、3DAPIを変更したくありません。もう少しパフォーマンスを絞り込もうとすると（シャドウをキャンセルすると100％の速度が得られますが、品質も重要です！）。
このJavaプログラムは、LOD（数百万の粒子）を使用したマーチングキューブアルゴリズムを備えた小惑星衝突シーンシミュレーター（小惑星のサイズ、質量、速度、角度の選択があります）になります。
マーチングキューブアルゴリズムは、三角数を大幅に減らします。質問に答えられなかった場合は、Java用のマーチングキューブ（またはO（n）凸包）アルゴリズムが受け入れられます！データ：ソースとしてのx、y、z配列、およびターゲットとしての三角ストリップ配列（等値面メッシュポイント）
ありがとう。
ストリームに関するいくつかのサンプルを次に示します（はるかに低い解像度）。
1）重力による立方体の岩のグループの崩壊：
2）排除力が現れ始めます：
3）排除力+重力により、グループはより滑らかな形状になります。
4）グループは球を形成します（予想通り）：
5）次に、大きな恒星の体が近づきます：
6）触れようとしています：
7）衝撃の瞬間：
Barnes-Huttアルゴリズムと切り捨てられたポテンシャルの助けを借りて、粒子数は10倍（おそらく100倍）多くなります。
マーチングキューブアルゴリズムではなく、nbodyを包むゴーストクロスは、低解像度の船体を与えることができます（BHよりも簡単ですが、より多くの計算が必要です）
ゴーストクロスはnbody（重力+除外）の影響を受けますが、nbodyはそれを包む布の影響を受けません。Nbodyはレンダリングされませんが、クロスメッシュはより少ない三角形の数でレンダリングされます。
MC以上が機能する場合、これにより、プログラムは約200倍多くのパーティクルの包装布をレンダリングできます。