Confirming 32bit color output via jPCT

[K24A3]

Is there a way to confirm that the app is rendering in 32bit mode via jPCT during runtime?

I've set everything up to use 8:8:8:8 but the output still looks 16bit with excessive color banding and I'm not sure if it's a texture/transparency issue or a configuration issue with the new Wallpaper service I'm using.

[EgonOlsen]

There's no way for jPCT-AE to detect the color mode and it actually doesn't have to care because choosing the video mode is out of its scope (unless you are using one of the ConfigChoosers). In case of banding, make sure that haven't enabled 16 bit color depth or texture compression on the textures in question. To fight banding in 16bit modes, you might want to enable dithering in Config.

[K24A3]

Ok I think I found the problem, the banding is caused by the SuperAMOLED screen on the Galaxy Note. Dark colors produce quite a lot of banding on these screens.

ps. the HellowShader example app crashes on the Note, if I can get logcat working in Eclipse I'll post the exception.

[EgonOlsen]

I'm not aware of any problems with HelloShader on Mali crap...

[K24A3]

False alarm, the project had that jPCT lib linking glitch. Renaming Lib to Libs solved the problem.


I also solved that 'lightning' glitch with the texture, calling .build() for every object seems to have fixed the problem.

But now I have a new problem with the offset shader included in the HelloShader example.
I built a test app so the problem is not related to the screensaver code.

I'm using the shader on a basic sphere, the results are:

Emulator: Looks perfect. The texture is shaded gradually depending on the light source.
Galaxy Note (Mali): The lit side of the sphere is pure white except for the closest part to the light which is pure black. Looks like a snooker ball.
Tegra 2 Tablet: It looks fine but there is no gradual lighting at all. The lighting effect is either on or off.

I'm guessing the shader wasn't designed to be used on a sphere, but why does it look perfect in the emulator?

[EgonOlsen]

The shader (if you are using the parallax mapping shader that came with the example) should work fine on everything as long as normals and tangent vectors are fine. You can try to force calculation of tangent vectors by calling calcTangentVectors() on the objects in question. If that doesn't help, maybe you can provide me with your test case. I can at least do a check on Tegra (and PowerVR).

[K24A3]

calcTangentVectors makes everything really dark and introduces the lightning effect again.

I'll prepare the test case and send it through soon, thanks.

[EgonOlsen]

Sounds like as if you are either using the wrong textures or your objects have no proper texture coordinates...

[K24A3]

hmm ok I'll look into that tomorrow, it's getting late here but I had a quick look at the textures, the height map is an 8bit grayscale texture so perhaps that is the cause? However the emulator renders it perfectly which is confusing.

I've sent through the test case anyway, if you could have a quick look that would be great. Screenshots are included.

[EgonOlsen]

If you add calcTangentVectors() (like you already did, but you commented it out), everything works as it is supposed to. I'm not sure what you mean with "really dark", but that's how this shader looks. If you don't want that, maybe the shader is not the one you want. You may as well play around with it to add some additional lighting to light up the dark regions. I can also post a version that combines offset mapping for the first with normal gouraud shading for all other light sources, if that helps.

A little background information on why calcTangentVectors() is needed in this case: jPCT-AE tries to detect the need for tangent vectors based on the shader's source code. If it detects it, it will calculate tangent vectors when calling build(). In your case, you assign the shader after calling build(), so the engine can't detect it in this case. So either call it yourself or assign the shader before calling build().

[K24A3]

I realized earlier the shader was dark by design and added extra ambient lighting static uniforms, but calcTangentVectors() still made it much darker, and without calcTangentVectors it looked perfect in the emulator which is what really confused me.

Anyway I see how it all works now, I'll make the changes you mentioned and see how it goes. Thanks.

[K24A3]

Ok I tried what you said;

Code Select Expand


obj3DMain3 = Primitives.getSphere(20, fScale);
obj3DMain3.calcTextureWrapSpherical();
obj3DMain3.translate(20, 0, 440);
obj3DMain3.setSpecularLighting(true);
offsetShaders.Set(obj3DMain3, R.drawable.venus_bmp, R.drawable.venus_normal, R.drawable.venus_height, 2);
obj3DMain3.calcTangentVectors();
obj3DMain3.build();
obj3DMain3.strip();
world.addObject(obj3DMain3);


..plus I added 0.3 to the Ambient vectors in the shader which has improved the brightness, but that lightning symbol is still appearing.

GalaxyNote: Extremely dark output on first launch, you can only see the lightning effect. Jump to another app and back, it looks like the image in the attachment.
Tegra3 device: Shader looks fine but again the lightning effect is evident as seen in the attachment.

Why is Thor cursing me with a bolt of lightning?

[attachment deleted by admin]

[EgonOlsen]

Ignore the lightning effect. It's most likely caused by the way these spheres from Primitives are build and/or the texture wrap distributes the texture coordinates. Use some proper sphere build in a modeller with proper coordinates instead and it should disappear.
About the problem on the Note...looks like a common problem with MALI that not only jPCT-AE suffers from. I've no idea what causes this, but maybe you can do some tests for me as i don't have access to a MALI based device:
     

• Don't set a user shader, let jPCT-AE use its default ones. Is the lighting correct then at startup?
• If it is, render the first frame with the default shaders and switch to the user shader on the second. Does that help in some way?
• Print out some debug information in onSurfaceChanged and onSurfaceCreated, run the app on both devices and post the complete log for both. Se the Logger to debug before doing this.

[K24A3]

1. Yes the lighting is correct at startup using the default shaders. There is no 'bolt' either.
2. It doesn't seem to switch over properly and I can't seem to figure out why... it's crashing when setting the TextureInfo when setting the shader:

01-01 06:21:57.850: E/AndroidRuntime(5425): java.lang.ArrayIndexOutOfBoundsException: length=1; index=1
01-01 06:21:57.850: E/AndroidRuntime(5425):    at com.threed.jpct.Object3D.setTexture(Object3D.java:3467)
01-01 06:21:57.850: E/AndroidRuntime(5425):    at com.threed.jpct.ES2Test.OffsetShader.Set(OffsetShader.java:88)
01-01 06:21:57.850: E/AndroidRuntime(5425):    at com.threed.jpct.ES2Test.Scene.updateFrame(Scene.java:240)
01-01 06:21:57.850: E/AndroidRuntime(5425):    at com.threed.jpct.ES2Test.Scene.onDrawFrame(Scene.java:351)
01-01 06:21:57.850: E/AndroidRuntime(5425):    at com.threed.jpct.ES2Test.HelloShader$MyRenderer.onDrawFrame(HelloShader.java:206)
01-01 06:21:57.850: E/AndroidRuntime(5425):    at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1462)
01-01 06:21:57.850: E/AndroidRuntime(5425):    at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1216)


3. Logs are attached for both devices, setting the user shader normally from the beginning.

[attachment deleted by admin]

[EgonOlsen]

That's because you can't increase the number of texture layers after the object has been compiled. Try to add the textures that the shader needs at the beginning ignoring that the default shaders doesn't handle them properly.