3 simple questions

  1. What means the unifrom variable in the default gui?


  2. What does GeometryBatchFactory do? This code in the doc [java]jme3tools.optimize.GeometryBatchFactory.optimize(rootNode);[/java]


  3. Is the rate of calling simpleUpdate, is it equals to fps of the game?
  1. GeometryBatchFactory makes your game faster. However it can be used only in immobile nodes e.g static scenery.
  2. if you game has 60 fps, simple update will be called 60 times in 1 sec.
1 Like
  1. it’s the number of uniforms currently used in the scene. Uniform are variables sent to the shaders
  2. It merges all geometries that have the same material into one big geometry (and one mesh). It usually makes your scene faster, because instead of sending a lot of objects to the GPU you only send a big one. But it comes with a cost, once it’s done you can’t move individual objects anymore (at least with the spatial API), you really have one big objects for each material in your scene.
  3. tralala is right.
1 Like

@nehon so, I can/should always use GeometryBatchFactory on static object like terrain?



Does uniform numbers indicated performance of the running game in anyway?

GeometryBatchFactory can however only be used to combine Geometries with the same(exact same(texture,floats eg)) material’s as far as I know.

iamcreasy said:
@nehon so, I can/should always use GeometryBatchFactory on static object like terrain?

you mean a JME terrain? I don't know i guess it's gonna mess the LOD feature of the terrain.
You should batch any non-animated objects that have the same material

iamcreasy said:
Does uniform numbers indicated performance of the running game in anyway?

Not really, it's more a debug information

The terrain classes in jME3 already optimize themselves. GeometryBatchFactory is useful on scenes generated from a modelling tool for example

And, if used carelessly, GeometryBatchFactory can have negative consequences to performance as well.



Imagine you are surrounded by a forest of clumps of trees and blindly batch them all together. Where you once had frustum culling helping draw only the batches of trees that were in view, now you draw all of the trees all the time… even the ones behind you. Where you were doing work on the CPU now you are pushing more data to the GPU and making it work harder. Depending on the number of trees, performance might actually go down significantly.



In that case, spatially organizing the trees and batching them in sub-groups would have been better.



Note: the above is example is meant as an illustration and could easily be nitpicked to death. Hopefully the point it still clear… careless batching can cause worse performance in some cases.

2 Likes
In that case, spatially organizing the trees and batching them in sub-groups would have been better.

@pspeed What kind of organization?

@Momoko_Fan If what pspeed saying is correct then how to use GeometryBatchFactory for, say a City. I thought all the static building are going to be pumped into the factory. But, this will cause the whole city to render at the same time!

Spatial organization largely depends on how your data is chunked up. The easiest it some kind of fixed size grid.