www.jpct.net
jPCT-AE - a 3d engine for Android => Support => Topic started by: K24A3 on October 05, 2012, 05:15:44 pm
-
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.
-
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.
-
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.
-
I'm not aware of any problems with HelloShader on Mali crap... ???
-
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?
-
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).
-
calcTangentVectors makes everything really dark and introduces the lightning effect again.
I'll prepare the test case and send it through soon, thanks.
-
Sounds like as if you are either using the wrong textures or your objects have no proper texture coordinates...
-
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.
-
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().
-
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.
-
Ok I tried what you said;
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]
-
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.
-
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]
-
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.
-
Ok I moved obj.setShader(shader) into updateFrame() calling it 5 seconds later, the standard texture looks normal at the beginning then after 5 seconds it goes black with white bolts.
-
...update
rotating the screen causes the whole sphere to be textured as if it had no directional lighting, just ambient light all around.
(and yes I am calling calcTangentVectors() at the beginning)
Edit: Attached log of starting with default shader, 5 seconds later it sets the user shader, then rotate the screen a second later. Also attached an image showing all three stages.
[attachment deleted by admin]
-
...that's all on MALI crapset, i assume?
-
Yes.
The shader works fine on the Tegra3.
I'm using a 3DS file now and that too has the lighning bolt effect, also visible on the Tegra3 but it's barely visible.
[attachment deleted by admin]
-
Just to confirm I'm adjusting the ambient light correctly in the fragment shader, I've added the below lines
float specular = pow(clamp(dot(reflect(-lVec, bump), vVec), 0.0, 1.0), 0.85);
vec4 vSpecular = vec4(specularColors[0],0) * specular;
vAmbient.x += 0.3; // ADDED
vAmbient.y += 0.3; // ADDED
vAmbient.z += 0.3; // ADDED
gl_FragColor = (vAmbient*base + vDiffuse*base + vSpecular) * att*2.0;
}
-
Are you still use calcTextureWrapXXX to apply the texture? The tangent vectors are calculated based on the u/v-mapping. Try to find and use a model with proper spherical uv-mapping.
-
Just to confirm I'm adjusting the ambient light correctly in the fragment shader,
Looks ok to me.
-
Are you still use calcTextureWrapXXX to apply the texture? The tangent vectors are calculated based on the u/v-mapping. Try to find and use a model with proper spherical uv-mapping.
Oops yes you are spot on. Looks perfect now on the Tegra3
-
Still the same on the Mali crapset minus the bolts.
-
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.
If you wouldn't mind posting that version I'll give it a try. As far as I can tell it looks like the problem may be related to shader lighting.
-
I'll post them later. I'm still not sure what causes this...as said, i got similar reports from other shaders on other MALI based devices and saw the exact same problem in another engine, so i tend to think that it's a driver bug of some kind. The question is what triggers this bug and if we can somehow work around it. I have some ideas to try...i'll post them later too.
-
Ok thanks, no rush.
-
The shader code. It assumes that the first light is the one you want to use for offset mapping. To ensure that this is always the case, you most likely have to enforce this by using http://www.jpct.net/jpct-ae/doc/com/threed/jpct/Light.html#setDistanceOverride(float) (http://www.jpct.net/jpct-ae/doc/com/threed/jpct/Light.html#setDistanceOverride(float))
vertex:
uniform mat4 modelViewMatrix;
uniform mat4 modelViewProjectionMatrix;
uniform vec4 additionalColor;
uniform vec4 ambientColor;
uniform int lightCount;
uniform vec3 lightPositions[8];
uniform vec3 diffuseColors[8];
uniform float fader;
uniform float fogDistance;
uniform float invRadius;
attribute vec4 position;
attribute vec3 normal;
attribute vec4 tangent;
attribute vec2 texture0;
varying vec3 eyeVec;
varying vec2 texCoord;
varying vec4 vertexColor;
varying vec4 diffuseColor;
varying vec3 lVec;
varying float fogWeight;
varying float att;
void main(void)
{
texCoord = texture0.xy;
vec3 n = normalize(modelViewMatrix * vec4(normal,0.0)).xyz;
vec3 t = normalize(modelViewMatrix * vec4(tangent.xyz, 0.0)).xyz;
vec3 b = tangent.w*cross(n, t);
vec3 vVertex = vec3(modelViewMatrix * position);
vec3 tmpVec = lightPositions[0].xyz - vVertex;
vec3 lv;
vec3 ev;
lv.x = dot(tmpVec, t);
lv.y = dot(tmpVec, b);
lv.z = dot(tmpVec, n);
tmpVec = vVertex*-1.0;
eyeVec.x = dot(tmpVec, t);
eyeVec.y = dot(tmpVec, b);
eyeVec.z = dot(tmpVec, n);
eyeVec=normalize(eyeVec);
vertexColor=vec4(0,0,0,0);
diffuseColor=vec4(diffuseColors[0],0);
float distSqr = dot(lv, lv);
att = clamp(1.0 - invRadius * sqrt(distSqr), 0.0, 1.0);
lVec = lv * inversesqrt(distSqr);
if (lightCount>1) {
vec3 normalEye = normalize(modelViewMatrix * vec4(normal, 0.0)).xyz;
tmpVec = lightPositions[1] - vVertex;
float angle = dot(normalEye, normalize(tmpVec));
if (angle > 0.0) {
vertexColor += vec4(diffuseColors[1] * (angle * (1.0- (min(fader, length(tmpVec)+0.1)/fader))), 0);
}
if (lightCount>2) {
tmpVec = lightPositions[2] - vVertex;
angle = dot(normalEye, normalize(tmpVec));
if (angle > 0.0) {
vertexColor += vec4(diffuseColors[2] * (angle * (1.0- (min(fader, length(tmpVec)+0.1)/fader))), 0);
}
if (lightCount>3) {
tmpVec = lightPositions[3] - vVertex;
angle = dot(normalEye, normalize(tmpVec));
if (angle > 0.0) {
vertexColor += vec4(diffuseColors[3] * (angle * (1.0- (min(fader, length(tmpVec)+0.1)/fader))), 0);
}
if (lightCount>4) {
tmpVec = lightPositions[4] - vVertex;
angle = dot(normalEye, normalize(tmpVec));
if (angle > 0.0) {
vertexColor += vec4(diffuseColors[4] * (angle * (1.0- (min(fader, length(tmpVec)+0.1)/fader))), 0);
}
if (lightCount>5) {
tmpVec = lightPositions[5] - vVertex;
angle = dot(normalEye, normalize(tmpVec));
if (angle > 0.0) {
vertexColor += vec4(diffuseColors[5] * (angle * (1.0- (min(fader, length(tmpVec)+0.1)/fader))), 0);
}
if (lightCount>6) {
tmpVec = lightPositions[6] - vVertex;
angle = dot(normalEye, normalize(tmpVec));
if (angle > 0.0) {
vertexColor += vec4(diffuseColors[6] * (angle * (1.0- (min(fader, length(tmpVec)+0.1)/fader))), 0);
}
if (lightCount>7) {
tmpVec = lightPositions[7] - vVertex;
angle = dot(normalEye, normalize(tmpVec));
if (angle > 0.0) {
vertexColor += vec4(diffuseColors[7] * (angle * (1.0- (min(fader, length(tmpVec)+0.1)/fader))), 0);
}
}
}
}
}
}
}
}
fogWeight = 1.0-clamp((-vVertex.z - (fogDistance-280.0)) / (280.0), 0.0, 1.0);
gl_Position = modelViewProjectionMatrix * position;
}
fragment:
precision highp float;
varying vec3 eyeVec;
varying vec2 texCoord;
varying vec4 vertexColor;
varying vec4 diffuseColor;
varying vec3 lVec;
varying float fogWeight;
varying float att;
uniform sampler2D textureUnit0;
uniform sampler2D textureUnit1;
uniform vec4 ambientColor;
uniform float heightScale;
void main ()
{
float height = texture2D(textureUnit1, texCoord).a;
vec2 offset = eyeVec.xy * ((height * 2.0 - 1.0) * heightScale);
vec2 newTexCoord = texCoord + offset;
vec4 base = texture2D(textureUnit0, newTexCoord) * fogWeight;
vec3 bump = normalize(texture2D(textureUnit1, newTexCoord).xyz * 2.0 - 1.0);
float diffuse = max(dot(lVec, bump), 0.0);
vec4 vDiffuse = diffuseColor * diffuse;
gl_FragColor = ((ambientColor + vDiffuse)*base * att*2.0 + vertexColor*(base*2.0));
}
-
I can't seem to find setDistanceOverride in v1.26 beta, was it removed?
Also adding the below lines to the fragment shader causes a shader load error
ambientColor.x += 0.3;
ambientColor.y += 0.3;
ambientColor.z += 0.3;
-
No, it's still in the Light class. I'm using it myself, so it has to be...
Which error do you get for the ambientColor-code?
-
Here's the log:
10-12 09:39:39.422: E/AndroidRuntime(1567): java.lang.RuntimeException: [ 1350034779427 ] - ERROR: Failed to load and compile fragment shaders!
10-12 09:39:39.422: E/AndroidRuntime(1567): at com.threed.jpct.Logger.log(Logger.java:189)
10-12 09:39:39.422: E/AndroidRuntime(1567): at com.threed.jpct.GLSLShader.loadProgram(GLSLShader.java:764)
10-12 09:39:39.422: E/AndroidRuntime(1567): at com.threed.jpct.GLSLShader.preInit(GLSLShader.java:276)
10-12 09:39:39.422: E/AndroidRuntime(1567): at com.threed.jpct.GL20.setShader(GL20.java:336)
10-12 09:39:39.422: E/AndroidRuntime(1567): at com.threed.jpct.GLRenderer.setShader(GLRenderer.java:510)
10-12 09:39:39.422: E/AndroidRuntime(1567): at com.threed.jpct.CompiledInstance.render(CompiledInstance.java:159)
10-12 09:39:39.422: E/AndroidRuntime(1567): at com.threed.jpct.GLRenderer.drawVertexArray(GLRenderer.java:2244)
10-12 09:39:39.422: E/AndroidRuntime(1567): at com.threed.jpct.World.draw(World.java:1321)
10-12 09:39:39.422: E/AndroidRuntime(1567): at com.threed.jpct.World.draw(World.java:1083)
10-12 09:39:39.422: E/AndroidRuntime(1567): at com.threed.jpct.ES2Test.Scene.updateFrame(Scene.java:293)
10-12 09:39:39.422: E/AndroidRuntime(1567): at com.threed.jpct.ES2Test.Scene.onDrawFrame(Scene.java:365)
10-12 09:39:39.422: E/AndroidRuntime(1567): at com.threed.jpct.ES2Test.HelloShader$MyRenderer.onDrawFrame(HelloShader.java:206)
10-12 09:39:39.422: E/AndroidRuntime(1567): at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1516)
10-12 09:39:39.422: E/AndroidRuntime(1567): at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1240)
Attached are the available functions in the Light class
..by typing sun.
[attachment deleted by admin]
-
It's definitely there...i just checked it with the latest beta version. Check your project setup. Maybe you are referencing some old version of the library.
About the shader error: Before that part, there should be some output from the driver that tells the actual problem.
-
You were right, the build path was pointing to the jPCT lib in the original HelloShader, which was earlier than v1.25 (you may want to update the lib in the HelloShader folder of the zip on the website), but running the app tells me it's using v1.26 in logcat during runtime - eclipse bug I suppose.
I added sun.setDistanceOverride(10000f) but the output is totally black, which is why I tried increasing the ambientColor in the shader. Below is the additional log info, which I assume it's because ambientColor is a uniform type, not a varying type?
Edit: It's totally black on the Tegra3 as well.
01-02 12:07:46.060: I/jPCT-AE(1088): Compiling shader program!
01-02 12:07:46.070: I/jPCT-AE(1088): Could not compile shader 35632: <invalid atom 65535>(30) : error C7563: assignment to uniform ambientColor
01-02 12:07:46.070: I/jPCT-AE(1088): <invalid atom 65535>(31) : error C7563: assignment to uniform ambientColor
01-02 12:07:46.070: I/jPCT-AE(1088): <invalid atom 65535>(32) : error C7563: assignment to uniform ambientColor
01-02 12:07:46.070: I/jPCT-AE(1088): [ 946814866081 ] - ERROR: Failed to load and compile fragment shaders!
-
You have to use a close distance for the override like 0.001 or similar. It's about making the first light source the closest one, not the farest.
About the uniform: Just copy it into a local variable and use that one instead.
-
I tried 0.001 with a light nearby and both devices are showing black textures.
Not to worry, I'll use the original shader since I need multiple light support and since it only fails on Mali.
-
So...finally...i had to buy K24A3's Galaxy Note to track this down... ;) The solution is, that Mali isn't very good (read: fails spectacular) on calculating the square root for higher values. Higher values mean anything larger than 655xx in this case. If you take the square root of a higher value, you'll get rubish. To fix this, you can change this line in the fragment shader:
float distSqr = dot(lightVec[0], lightVec[0]);
to this
float distSqr = min(65500.0, dot(lightVec[0], lightVec[0]));
...and it should work again. Of course, this isn't a real solution as it simply clamps the values. A better solution would be to get rid of the square root in the following line, but i can't be bothered with that right now... :)
-
Thanks Egon the shader looks normal now.
However the lighting direction on the objects seems to be in reverse or incorrect. Can you replicate this on the Note?
Blue dot is the light source.
[attachment deleted by admin]
-
Only on Mali or on all devices? Can you send me a current version of the test case? I've modified mine in the process to an extend that i can't use it anymore to test this particular thing... ::)
-
I'll send the test case via email now.
Seems I misplaced the charging cable for the Tegra3, I'll need a moment to find it.
-
The Tegra3 is terribly flat needing a good hour to get up and running. But I'm seeing the same effect in the Emulator.
Perhaps you can try it on your tablet?
-
Emulator with four spheres 300 units respectively away from the light at 0,0,0
Tegra3 is still afraid of booting google's robot
[attachment deleted by admin]
-
It's your globe model. It seems to have clockwise order in it's polygon definitions, i.e. jPCT culls the front faces and what you see are the lit back faces. Just add
oClonedSphere.invert();
and it will look fine again.
-
Hmm where did that sphere come from.. not to worry it works fine using invert.
Thanks for all your help I can finally continue with this project :)