Hi there,
Can someone help me solve this problem.
When I run my android game it seems that the textures of the models and any geometry I use appear pixelated.
All that I do on the materials I create is to set a defuse map and that is it. On the PC it seems to appear normal and smooth, but not on android.
Any help will be appreciated.
Here’s some screenshots.
Notice the skymap is doing the same.
MipMapping is by default disabled on android due to the overhead. You can try enabling mipmapping and see if the overhead is okay or tweak the textures so they work better without.
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there’s emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.
Can you please explain how to do both?
Sorry for being clueless…
You can load a texture with mipMaps by using a TextureKey where you set the enableMipMaps (or whatsisname) flag. For the texture you basically just have the resolution and any blur etc. effects you have in your image editor.
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there’s emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.
1 Like
Is it possible to do this using the material editor?
And for the second approach I don’t understand.
Afaik the auto-loading of textures is somehow hardcoded to be w/o mipmaps, maybe @Momoko_Fan or @iwgeric can tell you more about that, manually assigning the texture to the material should work any way. The second approach is simply using higher resolution textures or trying to use a “blur” filter in photoshop on the texture before using it in the game.
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there’s emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.
Thank you so much for you quick response and help.
I went the blur route for now and it seems to look a lot better.
Thanks again.
1 Like
IMO, that’s not a mipmap issue.
That’s a float precision issue in opengles shader, we have an opened issue in the tracker about this. I’m working right now on a solution.
In our opengles renderer, texture coord in the shader use 16bit precision float. So when you have a repeated texture with scaled texture coordinates on a wide area, the precision of the coords decrease pretty fast. Hence the “blocking” pattern of the texture fetch.
Go to the bottom left corner of your terrain and look if the quality of the first “tile” is ok. If it’s ok, I’m right.
This also explains why you don’t have the issue on desktop because floats use 32 bit precision.
@nehon: So moving the world instead of the player would help?
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there’s emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.
@normen said: @nehon: So moving the world instead of the player would help? The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there's emotes that hint otherwise or there's an increased use of exclamation marks and all-capital words.not really, it's not relative to the player, it's relative to the 0,0 coord in texture space, so the more the texture is repeated (and spread in the scene) the more the effect is obvious.
The thing is , usually texture coordinates are from 0 to 1 but when you want a texture to be tiled on a big area, you scale up the texture coord and set the texture’s wrap mode tor Repeat.
So while the coordinates are between 0 and 1 (the first tile) it’s fine. But let’s say you want 1000 tiles on x and 1000 tiles on y, the last tile’s coordinates will be between 999 and 1000.
But if you have a 1024 texture, for example, to be texel accurate you need 1024 sub divisions for a tile texture coord span. So roughly you need to be precise at 0.001. While it’s fine between 0 and 1 with 16 bits it’s probably not between 999 and 1000.
So this imprecision will return the same texture fetch for neighboring pixels, also voiding the bilinear filtering effect in the process.
I like this answer the most on the issue on stack overflow floating point - What range of numbers can be represented in a 16-, 32- and 64-bit IEEE-754 systems? - Stack Overflow
Half precision (16bit) floats max accurate value for a 0.0005 precision is 2. So I won’t do the math, but I guess with a 0.001 precision requirement the max is reached pretty fast too.
EDIT : I guess this effect can also occur when you don’t have scaled coordinates. If you have a texture spread on a wide area (uh…like a terrain 
) the varying interpolation of the texture coordinate might lack precision with 16 bits even between 0 and 1.
2 Likes
Well first of I think the problem you explain is probably true for the terrain.
In my case I am not even using a terrain.
The screenshots you see is actually a sphere with mountain models attached to the sides.
So the problem you explained below might be the case,
I guess this effect can also occur when you don’t have scaled coordinates. If you have a texture spread on a wide area (uh..like a terrain ) the varying interpolation of the texture coordinate might lack precision with 16 bits even between 0 and 1.
Here is another game I am actually working on and it looks a lot better than the previous one.
The texture of the menu picture appears pixelated. And if you look close some parts in the models also.
This very between different android devices. These screenshot were taken on my new galaxy note 2, but on my friends galaxy nexus they appear even worst.
Probably this:
https://code.google.com/p/jmonkeyengine/source/browse/trunk/engine/src/android/com/jme3/asset/AndroidAssetManager.java#107
It says “Strongly consider removing this.” - maybe we should.
1 Like
@Momoko_Fan said: Probably this: https://code.google.com/p/jmonkeyengine/source/browse/trunk/engine/src/android/com/jme3/asset/AndroidAssetManager.java#107It says “Strongly consider removing this.” - maybe we should.
OMG…
I removed it…
1 Like
Will the fix be in the latest nightly?
In next one, i made the commit 2 hours ago
Thank you very much for this fix.
I am sure it will look great now.
Will test as soon as possible.
Man nehon you are my HERO…
The graphics on android looks amazing now.
Your changed solved the problem.
Thank you.
1 Like
@ndebruyn said: Man nehon you are my HERO... The graphics on android looks amazing now. Your changed solved the problem. Thank you.Lol well thanks Kirill, (momoko_Fan), i just removed what he pointed out.
1 Like