We are a team of developers working on a terrain visualization software over a virtual 3D globe. The project is aimed at mobile devices running android, mainly tablets and mobile phones. We have tested this in several devices and, while mobile phones seem to run the application fine (we haven't detected any issues on any of them), some tablets seem to have problems when drawing the textures in the screen.
For clarity purposes, im attaching a video that displays the problem, since its a little difficult to explain with words. This example shows a sphere divided in 200 sectors, each one with a different texture.
Texture problem video
As you can see, sometimes it looks like it is trying to draw two different textures in the same sector at the same time.
We have tested this in these devices:
Samsung Galaxy S SLC (ok)
HTC Desire (ok)
Nook Ebook Reader (ok)
Samsung Galaxy Tab 10.1 (doesnt work propperly)
Sony Tablet S (doesnt work either)
Samsung Galaxy Tab 7.0 (ok)
Im posting the critical code that may be involved in this. First the fragment shader that is used to draw the textures:
varying mediump vec2 TextureCoordOut;
uniform sampler2D Sampler;
....
gl_FragColor = texture2D (Sampler, TextureCoordOut);
Next, im posting the key instructions that are executed in OpenGL, since the code is spared in several big functions:
GLES20.glGenTextures(num, idTextures, 1); //declare 200 textures
...
GLES20.glBindTexture(GLES20.GL_TEXTURE_2D, idTextures[texture]); //texture binding
...
GLES20.glVertexAttribPointer(Attributes.Position, size, GLES20.GL_FLOAT, false, stride, fb);
...
GLES20.glVertexAttribPointer(Attributes.TextureCoord, size, GLES20.GL_FLOAT, false, stride, fb);
...
GLES20.glDrawArrays(GLES20.GL_TRIANGLE_STRIP, first, count);
Im sorry not to be able to provide more details, but after several weeks of debugging, we have no clue at all of what could be causing this. Im turning to you hoping for any leads, since we are completely lost right now. Thanks in advance.
I think I might know what causes you difficulties. The only devices where it doesn't work for you are Tegra 2 devices. I recently started working with a Tegra 2 device and noticed certain differences. Compared to other devices Nvidia seems to have introduced certain kinds of rounding errors where some things can behave differently from other GPUs. I had to go to extreme lengths and use workarounds to get it working the way I want with my complex shaders.
And what I could see on your video looks sort of like the z-buffer might not have enough resolution and that causes some kind of z-fighting: http://en.wikipedia.org/wiki/Z-fighting. I am not sure because I don't really see from your code/description if you are drawing triangles that are very close together and can cause this kind of behaviour in the z-buffer.
But maybe you can try to scale the vertices (x,y,z) somewhat up or down and see what happens to the flickering. If it changes it probably has something to do with that, if not, the problem might have another reason, but then a little more code would be nice.
It would also be interesting to try to narrow it down by not painting the whole sphere but just one or two triangles where the problem occurs and see if it still happens.
PS: A longer video would have been better, short clips suck on vimeo.
Related
I'm working with the opengl es 3.0 api for android. I'm writing functionality for a bitmap text renderer, and, well, it works flawlessly on two of my devices, both samsung. but on my kindle fire 10 HD (7th generation) tablet, it's all messed up. it's sampling from wrong portions of the texture atlas, displaying wrong glyphs, and it won't display the entire message sometimes, and sometimes when i go to switch messages, via mapped buffers, it briefly displays the entire message at once before starting the animation of it. Anyhow, I seem to think it's related to degenerate triangle strips that I'm using, so I ask, is support for them not ubiquitous across all android devices supporting opengl es 3.0? I've had trouble before with the kindle fire, in shader-related stuff. It won't work at all if I don't specify a precision, both for floats, and for sampler2DArray, that I've discovered thus far.
A degenerate triangle "should just work"; there is no feature here in the API for the hardware not to support. They are just triangles which happen to have zero area because of two coincident vertices.
They have historically be really common for any content using triangle strips, so to be honest I'd be surprised if they are broken.
It won't work at all if I don't specify a precision, both for floats, and for sampler2DArray, that I've discovered thus far.
That's not a bug; that's what the the specification requires you to do. See "4.7.4. Default Precision Qualifiers" in the OpenGL ES 3.2 shader language specification.
I have developped a small openGLES2.0 app which is compatible from android version 8 to 17.
It basically renders a sphere model with simple texturing in an empty scene. I also keep track of device sensors like accelerometer. All is working fine and cool on a wide variety of android phones (GS2, GS3, GN2, Nexus...).
My simple problem is that i can't get it working on tablets (GT2 running on 4.1.1 for example). The app is installed correctly, it doesn't crash at all, i just see a black screen instead of my sphere model. The part of the application that doesn't use openGL is running perfectly.
I can't believe that OpenGLES 2.0 is not working on GT2, neither sensors, neither internet connection that i used also. Is there something to check/enable to get it working ? Maybe something related to the larger size of screen on tablets ? I could maybe post a bit of code but i think the problem is elsewhere...
Thanks for your time !
When you use GLES 2.0 on devices you must be careful with indices. On many devices you cannot use int index. Every device supports unsigned short index. For render you must use:
GLushort indicies[] = { 0, 1, 2, 0, 2, 3 };
...
glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_SHORT, indicies);
I'm developing an app that does live filtering of the camera preview stream ON THE GPU (OpengGL ES 2.0). It's similar to the famous apps "paper camera" (paid) and "cartoon camera" (free).
It works fine and quite fast on my galaxy s2, even faster on an s3 and ok on older Samsung devices. I've also tested it on a Sony Xperia Arc S and htc desire, as well as on several other devices I don't remember, where it isn't quite as fast as on my s2 but at least above 10 fps.
NOW HERE'S THE PROBLEM:
Yesterday I was able to test it on a HTC One X+ and a Galaxy Tab 10.1 (tegra 3 and tegra 2 respectively). On the one x+ it runs at around 5 fps and on the tablet at about 2 fps.
I also tried the before mentioned similar apps (paper camera and cartoon camera) on the one x+ where they also run considerably slower compared to my galaxy s2, even though they SHOULD run faster because of better hardware.
Is there any known problem of tegra GPUs concerning texture upload speed (I have to create a texture for every video frame) or something else that could reduce speed that much?
PS: Reducing camera preview resolution makes it slightly faster, but its still annoyingly slow.
Probably the issue is on the fragment shader itself, I've worked quite a lot with shaders on different GPU's and I've allways have found that not a faster GPU means a faster interpretation of the shader.
Are you using a lot of branching in you fragment shader ('if' conditions), or calls to other functions within the shader? If so, then you should try to avoid branching, also to inline the code's function into one, and to test GLSL built in functions which might be buggy on the current gpu drivers implementation, and then write your own replacement.
My Android app has been out for several months and works fine on any number of WVGA phones like the Droid, Droid 2, Galaxy, etc.
On the Motorola Xoom, however, a small portion of the textures load with white boxes where the images should be.
Researching online the most usual cause for this appears to be not using power of two textures. This seems an unlikely explanation since they work fine on so many other devices. Also, I am using power of two textures. The one caveat there is that I'm loading a bunch of bitmaps into a 1024 by 1024 texture dynamically. The code I'm using is from a now defunct library called Rokon, the relevant texture atlas code is here: http://code.google.com/p/rokon/source/browse/trunk/src/com/stickycoding/rokon/TextureAtlas.java?r=260 -- Like I said, I'm skeptical this could be the cause since it works on so many other devices AND many of the textures I am loading this way do work fine.
But I'm not sure what else could be causing it. A memory issue seems unlikely given that amount of memory available on the Xoom compared to the other devices the app works on.
Right now I don't own a zoom, but I can replicate the issue via DeviceAnywhere (where I see white backgrounds).
Nothing of interest shows up in LogCat either.
I know this isn't much to go on, but I'm at a loss here, what kinds of potential causes should I be looking at here? Thanks in advance for any ideas.
Try using glGetError() to see if OpenGL throws any errors
Is your application 2D or 3D? When you're drawing your sprites on the screen; which method are you using?
If your texture is white during onDrawFrame that probably depends on:
An untextured quad (using VBO:s or standard Vertex Arrays) - probably not, because it works on other devices
Xoom lacks support of the draw_texture extension - if you're using 2D
Xoom lacks support of VBO:s (Vertex Buffer Objects) - probably not, almost every Android device out there supports VBO:s
Do you have any sort of texture compression implemented that Xoom doesn't support?
At runtime, use this code to get the extensions and check if they're available:
String extensions = gl.glGetString(GL10.GL_EXTENSIONS);
boolean supportsDrawTexture = extensions.contains("GL_OES_draw_texture");
// Continue here and sooner or later you should see where Xoom lacks support
// where other devices doesn't.
Is it possible that you're falling foul of Android's automatically-resize-bitmaps behaviour? Print out the bitmap sizes as they are loaded to check, or move them to res/drawable-nodpi to avoid the behaviour entirely.
Is it possible that your texture exceeds 2048 pixels width or height? That's the maximum allowed texture size on XOOM.
So, I'm writing a game engine.
I have a little example (see http://qrcode.kaywa.com/img.php?s=8&d=http://rokonandroid.com/rd.apk), that seems to work fine on every device except Droid / Milestone.
It displays a blue screen (due to glClearColor being set to blue), and nothing more.
I have tried with/without textures, and with/without VBOs. Yet still all blue screens on Droid.
What is unique about Droid and how it handles OpenGL, and why is it doing this?
Are you using OpenGL ES 2.x perchance? The droid can't support it. Alas there is precious little we can do but guess without seeing some source code!