Problem when working with Materials

Troubleshooting General Help
1

My team and I have updated from JMonkeyEngine3Beta to JME3_RC. There is a problem I have observed. I get a “OutOfMemory: DirectBuffer” error when working with the j3m editor. Also the SDK freezes when trying to apply the material to the geometry using the SceneEditor. These are the only two bugs I have noticed so far. Hope this can get resolved in the next update. -DanqueDynasty

2

Can’t reproduce that?

3

Here is a video better demonstrating my problem, the entire SDK freezes when applying the j3m material to the model

http://youtu.be/q0OHUN3XELA



Hope this helps
4

The stack trace from the little warning sign in the bottom right that appears when it fails would help more.

5
@danquedynasty said:
Here is a video better demonstrating my problem, the entire SDK freezes when applying the j3m material to the model
http://youtu.be/q0OHUN3XELA


Hope this helps


Couple things (mostly questions)

1. Does it happen with other materials aside from Lighting?
2. Does this happen if you create the material and apply it via code? Or just through the scene composer?
3. Is that one of the Thunder Cats? Hoooo-oooooo.
4. Is there a reason you use the scene composer to do this?
6
@t0neg0d said:
Couple things (mostly questions)

1. Does it happen with other materials aside from Lighting?
2. Does this happen if you create the material and apply it via code? Or just through the scene composer?
3. Is that one of the Thunder Cats? Hoooo-oooooo.
4. Is there a reason you use the scene composer to do this?


Yes, I can answer these the best I can.

1. This happens to other types of material definitions.
2. I haven't tried via code yet.
3. No he isn't just one of the many characters that will be in the game, currently in a basic visualization mode.
4. I use scene composer for this because I don't much of the programming for this project. My position for the game is graphics and since the programmer and I work at seperate locations, I use the Scene Composer to get the desired look.

This method I am using worked perfectly fine in JMonkeyEngine3beta, so I know this method is proven to work.
7

Please post the stack trace if we’re supposed to help further.

8

Ok, here is the stack trace I got:



java.lang.OutOfMemoryError: Direct buffer memory

at java.nio.Bits.reserveMemory(Bits.java:658)

at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)

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:114)

at com.jme3.texture.plugins.AWTLoader.load(AWTLoader.java:192)

at com.jme3.texture.plugins.AWTLoader.load(AWTLoader.java:201)

at com.jme3.asset.DesktopAssetManager.loadAsset(DesktopAssetManager.java:283)

at com.jme3.asset.DesktopAssetManager.loadTexture(DesktopAssetManager.java:341)

at com.jme3.asset.DesktopAssetManager.loadTexture(DesktopAssetManager.java:351)

at com.jme3.gde.materials.multiview.widgets.TexturePanel.displayPreview(TexturePanel.java:47)

at com.jme3.gde.materials.multiview.widgets.TexturePanel.access$800(TexturePanel.java:29)

at com.jme3.gde.materials.multiview.widgets.TexturePanel$5.run(TexturePanel.java:309)

at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)

at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:701)

at java.awt.EventQueue.access$000(EventQueue.java:102)

at java.awt.EventQueue$3.run(EventQueue.java:662)

at java.awt.EventQueue$3.run(EventQueue.java:660)

at java.security.AccessController.doPrivileged(Native Method)

at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)

at java.awt.EventQueue.dispatchEvent(EventQueue.java:671)

at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:158)

at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:244)

at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:163)

at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)

at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:147)

at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:139)

at java.awt.EventDispatchThread.run(EventDispatchThread.java:97)



Sorry if it isn’t formatted correctly.

1 Like
9

Hm, okay. The texture browser really should only use the assetManager to load the textures when its necessary I guess… Can you try and see if forcing a GC helps with this? You can do that by enabling the “memory” view in the top bar (right-click the bar) and then clicking that. @nehon, do you have the same issue with assigning materials?

10

I have tried to force a GC, but the same problem occurs.

11

Yeah, the direct memory handling has a few quirks at the moment, it might just need more time ^^

12

@normen: since assets are never cached in jMP, that implies that huge direct buffers will be created but not destroyed for a long time, thus relying on the JVM’s cleanup system to clear these buffers would cause the above bugs (similar to what @pspeed experienced with Mythruna). Is this the case?

13
@Momoko_Fan said:
@normen: since assets are never cached in jMP, that implies that huge direct buffers will be created but not destroyed for a long time, thus relying on the JVM's cleanup system to clear these buffers would cause the above bugs (similar to what @pspeed experienced with Mythruna). Is this the case?

Yes, I guess. But as the texture editor really burns direct memory cause it uses it to display every texture it can be made better on that side as well.