jMonkey优化类似于Java3D的 [英] jMonkey optimization similar to Java3D's

问题描述

为了进行实时绘制，开始使用lwjgl(它是jmonkeyengine和jocl的基础)在opengl和opencl之间的互操作性"中，现在可以实时计算和绘制100k粒子.也许jmonkey引擎的mantle版本可以解决这个drawcall开销问题.

几天来，我一直在学习Eclipse(java 64位)中的jMonkey引擎(版本:3.0)，并尝试如何使用GeometryBatchFactory.optimize(rootNode);命令优化场景.

For several days, I have been learning jMonkey engine(ver:3.0) in Eclipse(java 64 bit) and trying how to optimize a scene with using GeometryBatchFactory.optimize(rootNode); command.

未经优化(具有更改球体位置的功能):

好吧，pci-express带宽+ jvm开销仅产生1-fps.

Okay, only 1-fps is originated from both pci-express bandwidth+jvm overhead.

具有优化功能(无法更改球体的位置):

现在，即使三角形数增加，也为29 fps.

Now it is 29 fps even with increased triangle number.

Java3D具有setCapability()方法，该方法即使以优化的形式也可以读取/写入场景对象. jMonkey引擎3.0必须具备此主题的功能，但是我找不到它的任何痕迹(搜索过的教程和示例，都失败了.)

Java3D had a setCapability() method which makes a scene object be able to be read/written even in an optimized form. jMonkey engine 3.0 must be capable of this subject but I couldn't find any trace of it(searched tutorials and examples, failed).

问题::如何在jMonkey 3.0中设置场景的optimized节点的read/write position/rotation/scale功能?如果您不能回答第一个问题，您能告诉我为什么使用优化命令时三角形数会增加吗?我是否必须创建一种新方法来访问图形卡并自己更改变量(可能是jogl?)?

Question: How can I set read/write position/rotation/scale capabilities of optimized nodes of a scene in jMonkey 3.0? If you cannot give an answer to first question, can you tell me why triangle numbers increase when I use optimization command? Do I have to create a new method to access the graphics card and change the variables myself(jogl maybe?)?

场景信息:16k粒子(球体尺寸为16x16 res)+1点光(及其4096分辨率阴影).

Scene information: 16k particles(spheres of 16x16 res) + 1 point light(and its 4096 resolutioned shadow).

我确信我们可以轻松地通过pci-express发送几千个浮点数.

I'm sure we can send several thousands of float numbers in a millisecond through pci-express with ease.

• 其他信息:我正在使用Aparapi内核来更新粒子 位置需要10毫秒(16k * 16k互动到 计算力).(在优化模式下不做任何更改:() aparapi可以访问那些优化的数据吗?

• Additional info: I'm using Aparapi-kernels to update particle positions which takes 10 milliseconds(16k * 16k interactions to calculate forces).(does not change anything in optimized mode :( ) Can aparapi access those optimized data?

对于batchNode.batch();优化的情况，这又是1 fps，但对象编号减少了:

For the case of batchNode.batch(); optimization, here is 1 fps again with lessened object-numbers:

对象数现在只有几百个，但fps仍为1！

Object number is now only several hundreds but fps is still at 1!

仅将球体位置发送到gpu并让其计算顶点位置可能比在cpu上计算顶点并向gpu发送大量数据要好.

Sending just sphere positions to gpu and letting it calculate the vertex positions could be better than calculating vertexes on cpu plus sending huge data to gpu.

没有人在这里帮助您吗?已经尝试了batchNode，但没有提供足够的帮助.

No-one here to help? Already tried batchNode but did not help enough.

我不想更改3d api，因为jMonkey人们已经重新发明了轮子，并且我对当前的状况感到满意.只是试图提高性能(取消阴影可以提高100％的速度，但是质量也很重要！).

I dont want to change 3d api because jMonkey people already reinvented the wheel and I'm happy with current situation. Just trying to squeeze a little more performance(canceling shadows gives %100 speed but quality is important too!).

此Java程序将通过具有LOD(将是数百万个粒子)的行进立方体算法，成为一个影响小行星的场景模拟器(可以选择小行星的大小，质量，速度，角度).

This java program will become an asteroid-impact scene simulator(there will be choice of asteroid size,mass,speed,angle) with marching-cubes algorithm with LOD(will be millions of particles).

Marching-cubes算法将大大减少三角形数.如果您不能给出任何答案，那么将接受Java的任何Marching-Cubes(或任何O(n)凸包)算法！数据:以x，y，z数组为源，以三角形条纹数组为目标(等值面网格点)

谢谢.

以下是有关流的一些示例(分辨率要低得多):

Here are some samples about the stream(with a much lower resolution):

1)通过重力使立方体形岩石群塌陷:

1)Collapsing of a cube-shaped rock-group by gravitation:

2)排斥力开始显现:

2)Exclusion force starts to show itself:

3)排斥力+引力使该组形成更平滑的形状:

3)Exclusion force + gravitation makes the group form a more smooth shape:

4)组形成一个球体(如预期的那样):

4)Group forms a sphere(as expected):

5)然后，一个大的恒星体接近:

5)Then, a big stellar body approaches:

6)即将触摸:

7)影响时刻:

借助Barnes-Hutt算法和被截断的电势，粒子数将增加10倍(也许是100倍).

With help of Barnes-Hutt algorithm and a truncated potential, particle numbers will be 10x(maybe 100x) more.

而不是Marching-Cubes算法，包裹nbody的幽灵布可以提供低分辨率的船体(比BH更容易，但需要更多的计算)

Rather than Marching-Cubes algorithm, a ghost cloth which wraps the nbody can give a low-resolutioned hull(more easier than BH but need more computation)

鬼魂布会受到nbody(重力+排斥)的影响，但nbody不会受到包裹它的布的影响. Nbody不会被渲染，但是布料网格将以较低的三角形数量进行渲染.

Ghost cloth will be affected by nbody(gravity + exclusion) but nbody will not be affected by cloth which wraps it. Nbody wont be rendered but cloth mesh will be rendered with lower triange count.

如果MC或更高版本可以工作，这将使程序呈现出一个包裹布，可以容纳200倍以上的粒子.

If MC or above works, this will let the program render a wrapping-cloth for ~200x more particles.

推荐答案

对不起....

您可以在保持静态的场景(或子节点)中批处理所有几何.

You can batch all Geometries in a scene (or a subnode) that remains static.

批处理是指将具有相同材质"的所有几何图形合并为一个网格.仅当您总共仅使用了很少(大约32种)材料时，此优化才有效.值得庆幸的是，在初始化游戏时批处理会花费额外的时间

Batching means that all Geometries with the same Material are combined into one mesh. This optimization only has an effect if you use only few (roughly up to 32) Materials total. The pay-off is that batching takes extra time when the game is initialized

因此，三角形的变化是因为它们都已组装成一个网格....如果有必要，唯一的建议是尝试获取网格并更改其上的点，但是在那一点上我不知道认为这是有道理的.

The change in triangles therefore is because they have been all assembled into one mesh.... The only suggestion if this is necessary, is trying to get the mesh and altering points on it, but at that point I don't think it makes sense.

也许尝试使用其他优化方法.

Perhaps try a different optimization method.

祝您好运，一点儿也没用过JMonkey，但很高兴看到其他人也使用了它，并且它的持续发展！

Good luck, haven't used JMonkey in a bit, but glad to see others do and its continued growth!

编辑

顺便说一句，使数学最小化的一种方法可能是使用半个立方体的球体，对地球的影响可能不会影响另一侧(除非该球体不是地球，但已经是地球的一小部分样品了)地球作为一个球体)...

BTW, a way to minimize the math might be to use half a sphere of cubes, an impact on the earth likely wouldn't affect the other side (unless the sphere isn't the earth but already a small sample of the earth taken as a sphere)...

也许尝试将2D形状用作冲击表面，尽管我知道这不是您的最佳选择，但它可能会让您了解形状的数量可能会产生怎样的影响以及影响程度如何.如果这样做的话，一条途径可能是考虑如何去除一些颗粒，如果没有，您不必担心.我几乎可以肯定.

Perhaps try a 2d shape as the impact surface, though I know this won't be your best choice, it might give you an idea of how the number of shapes might have an affect and how grand. If it does then an avenue might be to consider how to remove some of the particles, if it doesn't you need not worry. I am almost sure it will.

最后:

也许不实时渲染?花一分钟时间将帧绘制到缓冲区中，然后播放，到播放时，您将再获得40帧左右的帧，等等……您可能只需要花费大约30秒的时间.

Perhaps don't render in real time? Take a minute to draw the frames to a buffer then play, by the time your playing you will have another 40 or so frames etc... and maybe approx 30 secs worth is all you will need.

这篇关于jMonkey优化类似于Java3D的的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！