Some precisions needed about Android rendering

I did documente myself on Android rendering, but there is still something I don’t understand well.

Before, when using OGLES 1. (without shaders, so), we usually sended each frames the animated objects buffers.through VA list or buffers, and used vbo for static meshes, for instance.

What happens with OGLES 2.0 ? My problem is about displaying some rotating objects. How jme3 Android handles this ? I mean, can I send once them true VBO and animate them trough shader ? It would dramatically improve performances. As far as I understand, I would only have to pass a rotate vector to the shader instead of sending the whole buffers each frames. Is it feasible , is it already implemented ?

Any help ?

Thanks in advance :slight_smile: ,


oO Did you read any of our documentation at all?

Normen:I assume you mean JME3 documentation.

If anyone could help, it’s more a matter of general shader usage than JME3 relative

Normen: could you point out to your staff that the skybox from skybox example doesn’t seem to work on some phones (tested the samples on a Samsung Galaxy S)

Thanks by advance


For anyone to help you you will have to lay out the specifics of what you are doing, what is not working or working below your expectations performance-wise.

All mesh and texture data is available to the shaders and depending on the phone they might be stored as VBO or otherwise. For general info on what you can do in shaders, theres lots of info on the web or in our examples. Geometry shaders are not fully supported through OpenGL2 afaik, so I doubt they work on OpenGLES 2.1. At any instance all of what you are suggesting is happening on a lower level than what you do in the jME3 scenegraph. Because of the geometry shader limitations actual mesh animation is done in java by modifying the mesh buffer, moving an object doesn’t affect the mesh data at all though.

Thank you very much Normen !

I needed this precision, due to the fact I’m using vbo and that I would simply have to rotate. i’ll probably do this through a shader so that I don’t have to modify the mesh buffer each frame.


btw: Great work JME3 team !

@kine said:
I mean, can I send once them true VBO and animate them trough shader ? It would dramatically improve performances.

I wouldn't count on that IMO, The bottleneck on most android devices is clearly the GPU power.
However the CPU is quite powerful, so i think it's better keeping software animation rather than hardware.

Jme3 does use VBOs (at least when it's supported on the device, else there is a vertexArray fallback) but animation is done on the CPU.
But what are you looking for here? You want to know how Jme does it to do the same for your hand made engine? or you want to know about Jme3 to use it.

In the first case , i'd say go ahead and look at Jme's code, it's open source.
In the second case i'd say, forget about this, the engine handles it, you don't have to bother with opengl stuffs to make things work.

For the skybox problem it's that dds format is not supported on android (afaik in 2.2 at least), you have to use 6 images to have a working skybox on android.