Loading many texutres - OutOfMemoryError

[icarusfactor]

I/jPCT-AE ( 6345): Object 'object444' uses one texture set!
-----
more stuff
-----
E/dalvikvm-heap( 6345): 28800-byte external allocation too large for this process.
W/OSMemory( 6345): External allocation of 28800 bytes was rejected
-----
more stuff
-----
E/AndroidRuntime( 6345): java.lang.OutOfMemoryError
-----
no more stuff
------


After loading around 300 objects (the debug says 444 which may be the case) in the loop, I get an out of memory error. All the textures have been created (Just RGB color Texture) All the data on the object I am trying to create is loaded. Its just on adding it to the 3D world where it nose dives.

It keeps saying loading texture over and over again, object 1-2-444 etc.. but many of the objects use the same texture. Is it loading an individual texture for each object.(that is what seems to be the case , not for sure though) If so, how can I consolidate the usage of textures to just the amount used and no duplication. I would like to keep all my objects separate, since I wish to do animation as a later addition. But.. may be an option, where I can join and break objects. Not for sure , but looking for some tips on reducing memory footprint to fit the Dalvik limits.

[EgonOlsen]

Could you please post the log while loading objects/creating textures?

[icarusfactor]

Here is a pastebin of the a longer run of the errors before it dies with the out of memory error. If you need more of logs I will post them.

http://pastebin.com/fK7hQn01
Here is the part of the code that it is looping through.

Code Select Expand



                   Log.d(TAG, "buildAtom" );
                   //This section will be looped for stick and balls of atomic data   BEGIN
                   //insert ATOM lines into world
                   float sizeofatom=0.0f;
                   for(int n=0; n<index_table.ATOM; ++n ) {                                   
                      //Log.d(TAG,"Textures/Atoms Loading "+ atom_table[n].name);
                      Log.d(TAG,"Atoms ID "+matchatom( atom_table[n].name ) );
                      sizeofatom = periodic_table.covalent_size[ matchatom( atom_table[n].name ) ];
                      sizeofatom = sizeofatom /100;
                      world_table.atom[n] = Primitives.getSphere( sizeofatom ); //default size 0.25f
                      world_table.atom[n].calcTextureWrapSpherical();

                      world_table.atom[n].setTexture(atom_table[n].name);

                      world_table.atom[n].strip();
      world_table.atom[n].build();
                      world_table.world.addObject(world_table.atom[n]);
      world_table.atom[n].setCollisionMode(Object3D.COLLISION_CHECK_OTHERS);
                      world_table.atom[n].translate( atom_table[n].x , atom_table[n].y , atom_table[n].z );
                      world_table.atom[n].setRotationPivot( world_table.sv_center   );
      world_table.atom[n].setTransparency(8);
      world_table.atom[n].setSpecularLighting(true);
                      } //end of atom for loop


[EgonOlsen]

Doesn't seem to be a problem with textures but with polygon count/object size. Try the following:

Create a kind of SphereFactory that returns spheres based on the size needed instead of creating a new sphere each time. Inside that factory, store one sphere blueprint for each size. If a new sphere of size x is requested, take that blueprint and do:

Code Select Expand


Object sphere=new Object3D(blueprint, true);
setTexture("whatever");
shareCompiledData(blueprint);
build();
strip();


If it still doesn't help, try to add call to Object3D.compile() for each new sphere after the build instead of relying on the automatic compilation at render time.

That way, all new spheres will share data with the blueprint in main memory and on the gpu. That should help to save a huge amount of memory unless the size x is always different, but i gues it isn't!?

[icarusfactor]

Sounds like a great fix , load all the unique atoms and then reference the actual creation of the render from it.

[icarusfactor]

leaving some feedback on the "outofmemory" issue. This method worked great, I did keep it all object3D elements instead of the object data you had posted, but that cleared up my memory problem to where I now have to worry about speeding up the program I can load so many atoms, Thanks.