Why an OOM as I just changed the textures of my model?


I get an OOM error trying to convert my model
the only thing I changed are the textures (bigger for better resolution)

what really bugs me is that they are external to the model, why does the assetloader does need to load the texture files ?
they are not even stored in j3o files anyway, this is really a pain, if one wants to achieve decent games quality

    at sun.misc.Unsafe.allocateMemory(Native Method)
    at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:127)
    at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:306)
    at com.jme3.util.BufferUtils.createByteBuffer(BufferUtils.java:956)
    at com.jme3.texture.plugins.AWTLoader.load(AWTLoader.java:113)
    at com.jme3.texture.plugins.AWTLoader.load(AWTLoader.java:191)
    at com.jme3.texture.plugins.AWTLoader.load(AWTLoader.java:200)
    at com.jme3.asset.DesktopAssetManager.loadAsset(DesktopAssetManager.java:288)
    at com.jme3.asset.DesktopAssetManager.loadTexture(DesktopAssetManager.java:346)
    at com.jme3.scene.plugins.blender.textures.TextureHelper.loadImageFromFile(TextureHelper.java:743)
    at com.jme3.scene.plugins.blender.textures.TextureHelper.loadTexture(TextureHelper.java:505)
    at com.jme3.scene.plugins.blender.textures.TextureHelper.getTexture(TextureHelper.java:145)
    at com.jme3.scene.plugins.blender.materials.MaterialContext.<init>(MaterialContext.java:140)
    at com.jme3.scene.plugins.blender.materials.MaterialHelper.toMaterialContext(MaterialHelper.java:171)
    at com.jme3.scene.plugins.blender.materials.MaterialHelper.getMaterials(MaterialHelper.java:251)
    at com.jme3.scene.plugins.blender.meshes.MeshHelper.toMesh(MeshHelper.java:117)
    at com.jme3.scene.plugins.blender.objects.ObjectHelper.toObject(ObjectHelper.java:160)
    at com.jme3.scene.plugins.blender.AbstractBlenderLoader.toObject(AbstractBlenderLoader.java:137)
    at com.jme3.scene.plugins.blender.BlenderLoader.toObject(BlenderLoader.java:71)
    at com.jme3.scene.plugins.blender.BlenderModelLoader.load(BlenderModelLoader.java:66)
    at com.jme3.scene.plugins.blender.BlenderModelLoader.load(BlenderModelLoader.java:52)
    at com.jme3.asset.DesktopAssetManager.loadAsset(DesktopAssetManager.java:288)
    at com.jme3.asset.DesktopAssetManager.loadModel(DesktopAssetManager.java:374)
    at com.jme3.gde.core.assets.SpatialAssetDataObject.loadAsset(SpatialAssetDataObject.java:94)
    at com.jme3.gde.core.assets.actions.ConvertModel$1.run(ConvertModel.java:60)
    at java.lang.Thread.run(Thread.java:744)

I tried adding memeory to the ide icon , but then it fails to load at all

any help would be appreciated


The loader doesn’t know that you won’t be using the model and so has to load the textures.

How big is the texture and what are your SDK memory settings? (Note: the default settings are large enough that they are often ignored thus setting things back to default small settings… best to set them to 1 gig instead.)

but it is at conversion (inside the IDE), it does not need to load the textures

that’s what I did ,1gb, but the textures are huge (4096x4096)
also I assumed it would work as people often create huge texture atlas

I thought there could be an option not to load the textures when converting

(I modded some Borderlands stuffs, that thing load form 3000 to 4000 textures (up to 1024x1024) in-game)

[edit : I made a test loading 6 etxtures (they should be 64mb each in memeory) It works for an application
but the ide crash when I add -XX:MaxDirectMemorySize=512m to the launch icon properties]

What you call conversion is actually loading the model in one format and saving it in another. That avoids having to write n-number of format X to format Y conversion routines.

Is the source model a blender model? Those seem to be extra memory intensive for some reason.

It wasn’t clear from your post but your direct memory should absolutely be 1 gig… 512m is always too small for direct memory.

Edit: also, where are you modifying the SDK settings?

by adding -XX:MaxDirectMemorySize=512m to the launch icon

i found a solution, by converting the file in a separate test project (added -XX:MaxDirectMemorySize=512m option in the VM params)

and yep, I know what conversion means, it is just that the IDE itself seems to take a lot of direct memory

  Spatial temp = assetManager.loadModel("Models/"+libName);
  BinaryExporter.getInstance().save(temp, new File("assets/Models/"+filename));

I guess you are on a Mac? On other platforms, setting the memory in the SDK is done differently in a config file.

Note: there should be no reason to have direct memory set any smaller than 1024m. It doesn’t factor into GC so there should be no issue setting it large and 1024m should work on all platforms without reverting back to defaults.

…regular heap you have to be careful about because it does affect when the GC runs. A good rule of thumb is to have your direct heap twice as big as your regular heap to avoid running out of memory when you still really do have memory. (since direct memory exhaustion won’t cause GC)

And yeah, the SDK is a memory pig for some reason… and often doesn’t let go of it. I’ve had cases where I run out of memory loading a model that loads fine when I restart the SDK. (shrug)

no, win7

I found the config file, set it to 3072mb instead of 2048mb, still the same issue and 2gb is already something anyway

my (humble) suggestion would be to add a “boolean loadTextures” to the LoadModel function so, in the case of IDE conversion, textures loading are not needed, and one would avoid that issue, until the memory leaks/huge consuption are fixed

just saying :smile:

Now we are back to my original point… set it to 1024… not bigger. Because if it’s too big for the JVM then it will be silently ignored. I speak from experience because I had a ton of models that wouldn’t load until I set it smaller.

As per the troubleshooting section, theres a config file for the SDK to set the memory settings.

an engine should not limit the texture size
beside it is considered best practice to conglomerate texture to atlases, doing so, using large textures

Jme is not limiting it, your understanding of the memory model is. I had multiple 8k textures in jme with no problem.
Then there is the second possibility that there actually is not enough memory for those textures.

I have no idea what you are even talking about in response to my post.

I told you how to get the JVM not to ignore your settings. It has nothing to do with JME.

Java. That thing written by Sun. Taken over by Oracle. The thing none of us have an ounce of control over. It will SILENTLY IGNORE memory options it doesn’t like. By silently I mean present no error. By ignore, I mean continue to use whatever tiny defaults it originally wanted to use. Meaning that setting it to 3 gig very well could be Exactly the same as setting it to 256 meg.

Where on earth does “the engine” come into this?

ok, sorry for the confusion