Out of memory with 3 textures

Hello, I hope this isn’t in the wrong place, this is my first post here.

I’ve got a custom mesh with a single 512x512 texture, and all works well. I scale up to 20 or 30 meshes, all sharing the same texture and material (from assetManager during init), and I get out of memory (gl error 1285) on my tablet (main machine is fine).

If however I batch them into a single mesh, then all is well with memory - I can load hundreds of them, so it seems to me that my single texture must be getting loaded for each node/mesh. Sadly, I cannot continue to bulk them up, for several reasons - I need to regenerate each mesh quite often, and my short index buffers fail with large vertex arrays (my devices insist on short buffers).

I’ve read a lot of posts already, and it seems to me that the texture should already be shared, but my experience tells me otherwise. I’d like a way of keeping my meshes distinct, and yet making sure they use the same copy of the texture in the GPU… anyone any ideas?

That’s strange the texture should be shared.
What texture count do you have in the statview?
Does it behave the same on desktop and on android?

Hi, thanks. Stats view shows only 3 textures, and only a few k vertices. Desktop is fine, but it’s a more powerful machine.
The texture is shared, from a java perspective, but I reckon it’s pushed into the GPU by each custom mesh?
I can’t see why else it would run fine as one mesh, but not as several.

Looks similar to this, but it’s an old and apparently fixed issue :
He was using gDEbugger… I haven’t got to that level yet… was hoping someone could shed some light!

Unfortunately, gDEbugger is not working anymore with current Nvidia drivers. I haven’t found a reasonable replacement yet.

Well, some progress; I used the debug wireframe SceneProcessor from here : https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:advanced:debugging
to force the texture, i.e. :
wireMaterial = new Material(assetManager, “/Common/MatDefs/Misc/Unshaded.j3md”);
Texture tex = assetManager.loadTexture(“Textures/mytexmap.png”);
wireMaterial.setTexture(“ColorMap”, tex);
and again, everything is fine… I can load 100’s of meshs, and I don’t have the batching delay now as I move around. Sadly, the text and other stuff now looks… interesting.
It looks like other people have had problems too, e.g.

UPDATE : Ok, it still does break, with the force texture option, it just lasts longer. I made a minimal test case, loading the same texture for the default cube 100 times, and it does not break. Another, using 100+ Mesh, and it still doesn’t break… so, it looks like it’s something I’m doing, perhaps the background threading. Thanks for responses anyhow… I’ll work upward from my test case and see what happens.

Could you post the failing code?

I think I may have fixed it…
I was adding a lot of meshs with allocated but zero-length buffers; avoiding this seems to have moved me on… to 1281, invalid value… much better.

Here’s an example - this fails immediately with 1285 on my tablet, though it runs fine on the desktop.

public void simpleInitApp() {
Texture tex_ml = assetManager.loadTexture(“Textures/mytexmap.png”);
for (int i = 0; i < 10; i++ ) {
Mesh mesh = new Mesh();
FloatBuffer vb = ByteBuffer.allocateDirect(0).order(ByteOrder.nativeOrder()).asFloatBuffer();
FloatBuffer tb = ByteBuffer.allocateDirect(0).order(ByteOrder.nativeOrder()).asFloatBuffer();
ShortBuffer ib = ByteBuffer.allocateDirect(0).order(ByteOrder.nativeOrder()).asShortBuffer();
FloatBuffer nb = ByteBuffer.allocateDirect(0).order(ByteOrder.nativeOrder()).asFloatBuffer();
mesh.setBuffer(VertexBuffer.Type.Position, 3, vb);
mesh.setBuffer(VertexBuffer.Type.TexCoord, 2, tb);
mesh.setBuffer(VertexBuffer.Type.Index, 3, ib);
mesh.setBuffer(VertexBuffer.Type.Normal, 3, nb);
mesh.updateBound(); // NB This destroys the buffer mark, as does updateModelBound().
Geometry geom = new Geometry(“Mesh”, mesh);
Material mat = new Material(assetManager, “Common/MatDefs/Misc/Unshaded.j3md”);
mat.setTexture(“ColorMap”, tex_ml);

04-07 00:28:16.659 E/AndroidHarness( 5274): com.jme3.renderer.RendererException: OpenGL Error 1285. Enable error checking for more info.
04-07 00:28:16.659 E/AndroidHarness( 5274): at com.jme3.renderer.android.OGLESShaderRenderer.onFrame(OGLESShaderRenderer.java:559)
04-07 00:28:16.659 E/AndroidHarness( 5274): at com.jme3.system.android.OGLESContext.onDrawFrame(OGLESContext.java:334)
04-07 00:28:16.659 E/AndroidHarness( 5274): at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1462)
04-07 00:28:16.659 E/AndroidHarness( 5274): at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1216)

If there’s data in the buffers, then all is well.
I guess batching them up removed this issue, as the empty meshs would not be rendered.
Might be good for Mesh to check for empty buffers before rendering? I can imagine this could cause headaches…

I think this is the same issue people see with empty BitmapText on some Android devices.