Quote from: EgonOlsen on November 03, 2012, 08:02:55 AM
I bet the reason is the same as in the other thread about the array index problem: On some devices/Android versions, you start two threads doing the same thing at the same time, most likely du to multiple calls to on something(). That explains why textures are already there even after flush, it explains the memory problems and also the array index problems. Try to track down this behaviour and fix it in your wallpaper setup code.

You were right, I ended up synchronizing onDrawFrame() and onScreenChanged() on the same object, and now the problems are gone. Too bad I couldn't fix the GLWallpaperService coded by Robert Green, but the code is a mess...

I used your suggestion of calling Texture.defaultToKeepPixels(false) and loading the textures every time the context is lost, but now I'm getting:

java.lang.NullPointerException
at com.threed.jpct.GLRenderer.drawVertexArray(GLRenderer.java:2139)
at com.threed.jpct.World.draw(World.java:1321)
at com.threed.jpct.World.draw(World.java:1083)
at com.threed.jpct.util.SkyBox.render(SkyBox.java:201)
at com.wallpaper.MyRenderer.onDrawFrame(MyRenderer.java:238)
at net.rbgrn.android.glwallpaperservice.GLThread.guardedRun(GLWallpaperService.java:627)
at net.rbgrn.android.glwallpaperservice.GLThread.run(GLWallpaperService.java:492)

and:

java.lang.RuntimeException: [ 1351899406641 ] - ERROR: A texture with the name 'back' has been declared twice!
at com.threed.jpct.Logger.log(Logger.java:189)
at com.threed.jpct.TextureManager.addTexture(TextureManager.java:138)
at com.wallpaper.MyRenderer.onSurfaceChanged(MyRenderer.java:133)
at net.rbgrn.android.glwallpaperservice.GLThread.guardedRun(GLWallpaperService.java:622)
at net.rbgrn.android.glwallpaperservice.GLThread.run(GLWallpaperService.java:492)

or this:

java.lang.RuntimeException: [ 1351899405201 ] - ERROR: Requested texture not found!
at com.threed.jpct.Logger.log(Logger.java:189)
at com.threed.jpct.TextureManager.getTexture(TextureManager.java:403)
at com.threed.jpct.util.SkyBox.(SkyBox.java:72)
at com.threed.jpct.util.SkyBox.(SkyBox.java:38)
at com.wallpaper.MyRenderer.onSurfaceChanged(MyRenderer.java:136)
at net.rbgrn.android.glwallpaperservice.GLThread.guardedRun(GLWallpaperService.java:622)
at net.rbgrn.android.glwallpaperservice.GLThread.run(GLWallpaperService.java:492)


Note that I call .flush() on the TextureManager before loading any texture, so I don't really have a clue about what's going on... and how come the errors are only triggered on some phones.

Here's the code I use in onSurfaceChanged():


    @Override
    public void onSurfaceChanged(GL10 gl, int width, int height) {
    Log.d(TAG, "onSurfaceChanged() called");
    Resources res = mContext.getResources();
   
    // Flush the texture manager
    TextureManager tm = TextureManager.getInstance();
    tm.flush(); // This should clear the references to the textures, shouldn't it ?

    // Framebuffer setup
    if (mFrameBuffer != null) mFrameBuffer.dispose();
mFrameBuffer = new FrameBuffer(gl, width, height);
mWidth = width;
mHeight = height;

// World setup
if (mWorld != null) mWorld.dispose();
mWorld = new World();
mWorld.setAmbientLight(16, 16, 16);

// Sky box setup
String texPrefix = mPreferences.getString("skybox", null);
for (String sufix : mSkyBoxTexSufix) {  // mSkyBoxTexSufix is an array = {left, top, right....}
String name = texPrefix + "_" + sufix;
int id = res.getIdentifier(name, "drawable", mContext.getPackageName());
Log.d(TAG, "Loading new texture " + name);
Texture t = new Texture(res.getDrawable(id));
t.setMipmap(false);
tm.addTexture(sufix, t);
}
if (mSkyBox != null) mSkyBox.dispose();
mSkyBox = new SkyBox(1000);

        ....

        MemoryHelper.compact();
}


Thank you very much Egon, I'll try the beta again and report back as soon as possible.

Quote from: EgonOlsen on November 02, 2012, 02:01:02 PM

Quote from: K24A3 on November 02, 2012, 01:23:13 PM
Are you using multithreading separating the manipulation of 3D objects in one thread and having the render in another?

That's the only idea that i've left too...it might help to see the rest of the stack trace and not just that part after renderScene().

There's not much in the stack frame...

java.lang.ArrayIndexOutOfBoundsException
at com.threed.jpct.CompiledInstance.fill(CompiledInstance.java:1068)
at com.threed.jpct.Object3DCompiler.compile(Object3DCompiler.java:145)
at com.threed.jpct.World.compile(World.java:1928)
at com.threed.jpct.World.renderScene(World.java:1044)
at com.wallpaper.MyRenderer.onDrawFrame(MyRenderer.java:264)
at net.rbgrn.android.glwallpaperservice.GLThread.guardedRun(GLWallpaperService.java:627)
at net.rbgrn.android.glwallpaperservice.GLThread.run(GLWallpaperService.java:492)


And yes, as you can see the wallpaperservice creates a thread, but it takes care of the setup. I initialize all JPCT code in onSurfaceChanged() and manipulate it in onDrawFrame() so I don't see how that might be causing the error... In fact, I have coded three wallpapers with Rajawali (which internally uses the GLWallpaperService by Robert Green) and never had any issues.

Hi Egon,

Unfortunately I don't have access to any of those devices. I own a couple of devices, and the code works fine on them.

I don't set any texture on the mesh, I just light it with some color, like this:

mKeyLight = new Light(mWorld);
mKeyLight.setIntensity(Color.red(meshColor), Color.green(meshColor), Color.blue(meshColor));
SimpleVector sv = new SimpleVector(mMesh.getTransformedCenter());
sv.y -= 100;
sv.z -= 100;
sv.rotateY((float)(-Math.PI / 8.0f));
mKeyLight.setPosition(sv);


Note that I use two more lights, a fill light and a rim light, but I don't think that really matters. The only other mesh I have in the scene beside the main mesh, is a simple billboarded plane with a 256x256 texture.

In total, there are 6 512x512 textures for the skybox and 1 256x256 texture for the billboarded plane (and I'm still getting OOM errors on some devices [mostly mdpi 320x480 devices]). Since you asked for it, here's the code that assigns a texture to the billboarded plane:


String sunName = "sun" + sufix;
int id = res.getIdentifier(sunName, "drawable", mContext.getPackageName());
Log.d(TAG, "Loading new texture " + sunName);
tm.addTexture("light", new Texture(res.getDrawable(id), true));

// Create sun billboarded plane
Object3D sun = Primitives.getPlane(1, 3.0f);
sun.setBillboarding(true);
sun.translate(1.0f, -2.5f, -3.5f);
sun.setTexture("light");
sun.setTransparency(1000);
sun.setLighting(Object3D.LIGHTING_NO_LIGHTS);
sun.setAdditionalColor(RGBColor.WHITE);
sun.build();
mWorld.addObject(sun);


Maybe it has something to do with the number of polygons in the main mesh ? It has 6432 triangles, 3218 vertices... but please notice that I just use one mesh in the scene besides the simple billboarded plane.

P.D: I serialize the mesh with this code:


Object3D[] objs = Loader.loadOBJ(inputFileName, null, 1.0f);
for (Object3D obj : objs) {
obj.build();
}
String outputFileName = inputFileName.substring(0, inputFileName.lastIndexOf('.')) + ".ser";
new DeSerializer().serializeArray(objs, new FileOutputStream(outputFileName), true);


Thank you for your support.

Quote from: EgonOlsen on November 01, 2012, 11:15:29 PM
Are you by any chance doing a call like  object3D.compile(false, true); in your code? If so, do you have to? Are you really changing the uv-coordinates on the fly?

Nope, I'm not calling compile(), just build(). Here's the code I use to load the mesh:

String meshName = mPreferences.getString("mesh", null);
int id = res.getIdentifier(meshName, "raw", mContext.getPackageName());
InputStream is = res.openRawResource(id);
mMesh = Loader.loadSerializedObjectArray(is)[0];
mMesh.rotateX((float)(Math.PI / 2.0f));
mMesh.rotateMesh();
mMesh.setSpecularLighting(true);
mMesh.build();
mWorld.addObject(mMesh);

I suspect it has something to do with short vs int buffers... since I use both Rajawali and your engine, and the author of Rajawali had a similar issue: https://github.com/MasDennis/Rajawali/issues/20

Also, it seems that not all devices support int buffer as shown here: https://github.com/MasDennis/Rajawali/issues/28

Egon, the error is still there with the latest beta:

java.lang.ArrayIndexOutOfBoundsException
at com.threed.jpct.CompiledInstance.fill(CompiledInstance.java:1068)
at com.threed.jpct.Object3DCompiler.compile(Object3DCompiler.java:145)
at com.threed.jpct.World.compile(World.java:1928)
at com.threed.jpct.World.renderScene(World.java:1044)
...

This time the device that triggered the error is this one: http://pdadb.net/index.php?m=specs&id=2751&c=samsung_gt-s5660_galaxy_gio  (but running Android 2.3.6 instead of 2.2).

Quote from: EgonOlsen on October 29, 2012, 12:20:37 PM
I fail to see any relation to the hardware or the Android version ATM...can you please give the latest beta a try: http://jpct.de/download/beta/jpct_ae.jar?

I'm going to give the beta a try and report back. Thanks.

Quote from: EgonOlsen on October 29, 2012, 07:22:09 AM
Any chance that you've played around with this setting http://www.jpct.net/jpct-ae/doc/com/threed/jpct/Config.html#vertexBufferSize? If so, don't do that...

Hi Egon. No, I've not changed that setting. Since I'm using Bugsense, I know exactly which devices the failure happened on:

- LGL35G (Low end, small screen 240x320).
- LG-E400 (Low end, small screen 240x320).
- XT557 (Motorola, 512MB RAM, 1Ghz Processor, 854x480 screen). This has the same features than my test phone (Xperia Neo V).
- WT19a (CPU Scorpion at 1 GHz, GPU Adreno 205, chipset Qualcomm MSM8255 Snapdragon).
- GT-I9003 (Samsung Galaxy S).

All devices are running Android Gingerbread, and I'm using latest JPCT-AE (1.25).

Quote from: Thomas. on October 25, 2012, 06:47:37 PM
or you can use Texture.defaultToKeepPixels(false) and Virtualizer

@Thomas, If I use Texture.defaultToKeepPixels(false) and I reload all textures when the context is lost, then there is no need to use the Virtualizer right ?

@Egon, Unfortunately I tried to compress the textures but it takes too much time to load the skybox (from 2 to 8 seconds), which is unacceptable for a live wallpaper.

Hi there, I got this report today from a couple of users. Stacktrace follows:

java.lang.ArrayIndexOutOfBoundsException
at com.threed.jpct.CompiledInstance.fill(CompiledInstance.java:1017)
at com.threed.jpct.Object3DCompiler.compile(Object3DCompiler.java:145)
at com.threed.jpct.World.compile(World.java:1911)
at com.threed.jpct.World.renderScene(World.java:1035)

The full code that triggers this crash is the following:

mFrameBuffer.clear();
mSkyBox.render(mWorld, mFrameBuffer);
mWorld.renderScene(mFrameBuffer);    <----- This is the culprit
mWorld.draw(mFrameBuffer);
mFrameBuffer.display();

Well, I disabled the mipmap for the skybox textures but I'm still getting crash reports 

Since I need 32 bit textures, the only other thing left to do seems to "Compress the in-memory copy of the texture data". Do you think this will help Egon ?

Also, the odd thing is that the crashes happen in the render method of the Skybox object, not while loading the Skybox textures...

I see. So do I really need mipmap generation if I'm just rotating the camera around the scene ? How do I disable it for the SkyBox ?

Quote from: EgonOlsen on October 24, 2012, 11:16:14 AM
Textures too large...most likely. Consider some of these tips: http://www.jpct.net/wiki/index.php/Reducing_memory_usage#Reduce_texture_memory_usage

1 RGBA texture = 512x512x4 = 1048576 (1MB)
6 textures = 6MB

Is this really the reason ? The scene is very simple, it's just composed of a billboarded plane with a 256x256 texture, and a single mesh.

Any idea why this happens ?

java.lang.OutOfMemoryError
at com.threed.jpct.GLRenderer.convertTexture(GLRenderer.java:845)
at com.threed.jpct.GLRenderer.setTextures(GLRenderer.java:2270)
at com.threed.jpct.GLRenderer.drawVertexArray(GLRenderer.java:2195)
at com.threed.jpct.World.draw(World.java:1307)
at com.threed.jpct.World.draw(World.java:1074)
at com.threed.jpct.util.SkyBox.render(SkyBox.java:201)
at com.example.MyRenderer.onDrawFrame(MyRenderer.java:254)

It happened to a single user out of 300 who have installed the application.