0

Out-of-memory when loading 3D OBJ model of 5M size. debug shows the dalvik has 50M memory limit, either on emulator or device. I don't see why this.

mIndicesInt = ByteBuffer.allocateDirect(indices.length * INT_SIZE_BYTES).order(ByteOrder.nativeOrder()).asIntBuffer();
mIndicesInt.put(indices).position(0);

I even increased AVD RAM to 2048M and heap to 1024M, it doesnot help. it always stop with the same numbers:

D/setIndices(2270): Memory: Pss=67.88 MB, Private=66.09 MB, Shared=13.30 MB D/setIndices(2270): maxMem=50331648 D/setIndices(2270): totalMem=50208736 D/setIndices(2270): freeMem=1963736

The OBJ model contains more than 20 objects. I removed several objects then out-of-memory issue disappears, so this is a memory hard limit issue per process?

Any suggestion on handling it? Also AVD optioins to increase RAM and heap size has no effect, why?

Michael SM
  • 715
  • 3
  • 11
  • 25
  • Looks similar to http://stackoverflow.com/questions/3078301/dalvik-memory-allocation-how-to-change-the-default-limits I'm not saying it's actually a duplicate. Just that you might get some good information from there. For one thing, it seems the memory limit is "hard-coded" and can't be changed without rooting the phone. – Patrick M Jan 26 '13 at 11:13
  • thanks for pointing that. I did a search with out-of-memory but not hitting that thread. – Michael SM Jan 26 '13 at 11:44
  • Have you tried to do the allocation in JNI/native code and sending references to the java code? As far as I know, the native heap can grow very large. Another option is to memory map the files as apparently this won't count towards your heap limit: https://groups.google.com/forum/?fromgroups=#!topic/android-ndk/lcnwzszrESo, MMapp IO link: http://developer.android.com/reference/java/nio/channels/FileChannel.html specifically look at the map(...) method. When you open the file (e.g. with fileInputStream) use method .getChannel() to get a reference to a FileChannel you'll need for .map(...). – paulczak Jan 26 '13 at 20:51
  • Thanks for pointing those. I'll take a look at those links. – Michael SM Jan 26 '13 at 21:41
  • I believe you should reconsider your strategy. Depending on device, Android heap size can be as small as 32 or even 24 MB. I've implemented all OBJ parsing in separate PC utility application which produces binary data ready for uploading to GPU. Millions times faster and doesn't consume memory. I've just migrated code which works with OBJ from Android app to console Java application. – keaukraine Jan 28 '13 at 09:05
  • That's what I am doing now. – Michael SM Jan 29 '13 at 09:40

1 Answers1

0

5M of vertex data is quite a lot for a mobile environment. If you are also loading textures, consider loading only compressed textures. You can also free some resources once they have been moved to the GPU driver. I would prepare your vertex data offline and only load the required data during runtime. Another option is to compute part of the data, or expand it directly at the vertex/fragment shaders (for example generate bitangents at GPU side).

Trax
  • 1,890
  • 12
  • 15
  • you seems and expert on this topic. I don't know what bitangents are used for. ALso can you show a snippet on how to load and use compressed textures? my textures pretty large. – Michael SM Jan 29 '13 at 19:56
  • If you don't know about bitangents, don't worry about it. It's an advanced topic. About loading compressed textures, you may find more information here: http://stackoverflow.com/questions/9148795/android-opengl-texture-compression – Trax Jan 29 '13 at 20:24