For those whom have run jme3 android on their phone I’m curious of your performance. All I have to test with is a GS4 and I have found the max objects I can have on a screen while maintaining 50-60fps is 45, and that is using either cubes or quads, all unshaded (so I assume this is the limit since the performance doesn’t change depending on the polys).
How many objects can you get while keeping 50-60fps?
My issue is that I’d like to keep about 50 entities on the screen at the most and being limited to 45 objects means there is no room for anything else if there are lots of entities. This honestly almost puts me at the point of giving up on making anything of value on android as I don’t see how I can deal with object counts lower than 100.
That’s around the limit yes. Android can be very frustative.
A solution is to use batching. You probably have similar (same material) and / or static objects that would benefit from being batched.
As a rule of thumb on android you have to lower your expectation on almost everything.
The way to get best performance out of jME for android is to:
Do not use lighting in your scene at all. If you want to use lighting, only apply it on the character that is going to be dynamic. Or which you see in your scene.
Make use of light maps for all static objects in the scene. apply the light maps on the unshaded materials of those object.
Try to make use of a texture atlas where ever you can. Do not exceed texture sizes of 512x512. If have to you can, but that is going to impact the memory usage.
Don’t batch objects together if they are going to make a big large batched object that is so big it must always render, rather try to batch object by position.
Don’t use too many materials at a time.
Don’t use more than about 50 object at a time in the scene.
What I also do is not to make use of texture compression. In the android MainActivity class I set this: [java]TextureUtil.ENABLE_COMPRESSION = false;[/java]
O yes, and one other important thing I have noticed that the use of too many control classes in the scene has a big impact on the performance. I don’ really know why?
Anyways, these are my most important observations when I developed my android game.
Good luck…
O yes, by the way, I have a Galaxy Note 2 phone and get an average of 40fps. On my galaxy tab it drops significantly. It goes down to about 27fps./
One other note about textures, if you use material.preload as your creating you’re scene (ie. do this right after loading each object or a group of objects), the textures will get sent to the gpu and the android bitmaps will get recycled. This was a huge benefit to us to avoid Out of Memory issues while loading scenes with many or large textures. If you don’t use this, then all textures will get created and then converted and sent to the gpu at the same time. Depending on what device / os version the device has, it can be common to run out of heap before the scene is done getting created.
One other note about textures, if you use material.preload as your creating you’re scene (ie. do this right after loading each object or a group of objects), the textures will get sent to the gpu and the android bitmaps will get recycled.
If I don't load images, but I load models that already have these materials on them, do I still need to call the preload? And if so, how?
Thanks.
@ndebruyn said:
Just a quick question on the comment:
If I don’t load images, but I load models that already have these materials on them, do I still need to call the preload? And if so, how?
Thanks.
The material.preload is useful when you are individually creating the material and setting the textures.
If you are loading a j3o file, use the renderManager.preloadScene(spatial) instead where spatial is the return value of the j3o load. This will go through your spatial and do a material.preload on the individual materials for you.
It has the same effect as long as you don’t run out of memory during the initial load of the j3o file, of course.