So I'm getting a crash on my app after pressing home and going back into it,

06-05 21:23:37.915: E/AndroidRuntime(28038): FATAL EXCEPTION: GLThread 43544
06-05 21:23:37.915: E/AndroidRuntime(28038): java.lang.NullPointerException
06-05 21:23:37.915: E/AndroidRuntime(28038): at com.threed.jpct.GLRenderer.drawVertexArray(GLRenderer.java:2157)
06-05 21:23:37.915: E/AndroidRuntime(28038): at com.threed.jpct.World.draw(World.java:1344)
06-05 21:23:37.915: E/AndroidRuntime(28038): at com.threed.jpct.World.draw(World.java:1085)

I've been searching but haven't found what I have to do exactly to manage gl context changes. Is the solution to load all the models from the files (serialized) again? and same goes for the textures? I thought the engine would manage re-upload of vbos and textures to the gpu, but now I don't really know, the info is a bit confusing to me.



Thank you.

I'm not a fan of rendering the sky as a first object, I prefer leaving it to the last object. That it because if you draw the sky first without z test, you draw ALL the fragments of the sky, and probably many of them are going to be overwritten by other geometry, making some fragment rendering useless (and expensive if your sky uses some kind of shader).

I usually draw the sky the last with a vertex shader that does this to push the sky back into the far clipping plane, so it seems as it was in the infinity:

vec4 p=modelViewProjectionMatrix * position; //vert to eye space
gl_Position = vec4(p.x, p.y, p.w, p.w);           // replace z by w, this pushes skydome vertex back to the far plane
This way, the sky is pushed back in the far plane (no size issues) and you are rendering it in the last position with z test enabled, so probably many of the sky's fragments are ocluded by other things in your scene and it will be cheaper to render.

Hope I helped.

Hello again 

I've been playing with collision detection octrees lately, they are quite interesting structures. This is going to be more of a learning thread, not a technical question. I have a big terrain (2500 triangles) and asigned a 10 depth octree to it (collision mode only). I was amazed at how fast it tests collision using sphere collision on my character. When I get close to that terrain, fps only fall from 57/58 to around 54 or 56 with such a big structure, especially on a phone!. It would be nice to know how this works a bit more (maybe not a completely jpct-ae related question, if it doesn't belong here, i'm sorry, just delete it).

I've been reading about octrees and they recursively subdivide a bigger space in the shape of 8 cubes/bounding boxes. But how can the collision detection system calculate this so fast? I mean, a 10depth octree can get really complex and testing against 8 nodes at every tree level should damage performance by a lot. I guess there are some optimizations but still, I can't believe that these sphere vs triangle collisions are calculating so fast on such a big mesh. Also, given a certain mesh, is there a method to know the optimal depth/max polys for the octree?  I would appreciate any insight on this topic, I'm really curious at how this works

Hi!

I recently switched to a Nexus 4 phone with Android 4.2.1 and i'm getting some weird crashes while loading textures. All my textures are square of 2 size, but I'm getting errors like these when executing Texture aux=new Texture(res.getDrawable(id),alpha); and after that activity stops

256x256 size texture:

02-06 14:05:26.487: I/jPCT-AE(17562): Loading Texture...
02-06 14:05:26.487: I/jPCT-AE(17562): [ 1360155926496 ] - ERROR: Unsupported Texture width: 341
02-06 14:05:26.487: I/jPCT-AE(17562): [ 1360155926500 ] - ERROR: java.lang.RuntimeException: [ 1360155926496 ] - ERROR: Unsupported Texture width: 341
02-06 14:05:26.487: I/jPCT-AE(17562): at com.threed.jpct.Logger.log(Logger.java:189)
02-06 14:05:26.487: I/jPCT-AE(17562): at com.threed.jpct.Texture.loadTexture(Texture.java:798)
02-06 14:05:26.487: I/jPCT-AE(17562): at com.threed.jpct.Texture.<init>(Texture.java:198)
02-06 14:05:26.487: I/jPCT-AE(17562): at com.threed.jpct.Texture.<init>(Texture.java:234)

128x128 texture:

02-06 14:09:46.624: I/jPCT-AE(18345): [ 1360156186637 ] - ERROR: Unsupported Texture width: 171
02-06 14:09:46.624: I/jPCT-AE(18345): [ 1360156186639 ] - ERROR: java.lang.RuntimeException: [ 1360156186637 ] - ERROR: Unsupported Texture width: 171
02-06 14:09:46.624: I/jPCT-AE(18345): at com.threed.jpct.Logger.log(Logger.java:189)
02-06 14:09:46.624: I/jPCT-AE(18345): at com.threed.jpct.Texture.loadTexture(Texture.java:798)
02-06 14:09:46.624: I/jPCT-AE(18345): at com.threed.jpct.Texture.<init>(Texture.java:198)
02-06 14:09:46.624: I/jPCT-AE(18345): at com.threed.jpct.Texture.<init>(Texture.java:234)

Some more info that appears on my logcat

02-06 14:15:53.186: I/jPCT-AE(18762): GL20 render pipeline initialized!
02-06 14:15:53.186: I/jPCT-AE(18762): OpenGL vendor:     Qualcomm
02-06 14:15:53.186: I/jPCT-AE(18762): OpenGL renderer:   Adreno (TM) 320
02-06 14:15:53.186: I/jPCT-AE(18762): OpenGL version:    OpenGL ES 2.0 V@6.0 AU@ (CL@2946718)
02-06 14:15:53.186: I/jPCT-AE(18762): OpenGL renderer initialized (using 2 texture stages)


Last time I tested my app on my Samsung Galaxy S plus it worked fine, now a relative has that phone so i can't test it again in it until tonight! Any ideas?

Thanks

You don't have to make the Object3D implement the collision listener. You can simply make it its own class.

It should be save to add/remove objects based on the events because they should be triggered after iterating over the world's objects when checking for a collision. However, i'm not convinced that this is needed. Do you really need new texture coordinates for this? Couldn't you get away with just setting a new texture? In that case, you could reuse the Object3D. Another option might be make the broken object a child of the normal one and just toggle visibilities of both depending on their states...i'm not sure if that works well, but it might be worth a try.

Thanks Egon, unless I'm missing something, replacing the texture wouldn't work because both models (original and replacement) are different. The replacement is a broken version of the original, so it has less vertices but it uses the same texture (and the same texture coordinates for the vertices that "survived the crash"). This broken model is just the original one modified in Blender (some vertices got removed, others just got translated or rotated, uv mapping didn't change, but i think removing those verts makes the object completely different internally).

I'm going to give the child idea a try, I think it would probably work well and I guess it wouldn't be a big overhead, as i'll be cloning the pre-loaded model for them to use the same mesh.

Edit: Child idea is working like a charm, thanks!

Texture coordinates are from 0 to 1, maybe you want something like this?

Code: [Select]

public class myShaderManager{
public static float timer = 0;
static GLSLShader myShader;

    public static void update()
    {
        timer += 0.01f;
        if (timer > 1)
           timer = 0;
        myShader.setUniform("timer", timer);
    }
}

That was it! Sometimes I feel stupid , in the other version I had that timer multiplied by 0.01 before passing it and that's why it worked, and I completely ignored that in this version so i was just adding 1 to the texcoord leaving it in the same position  Thanks a lot!