koobas.hobune.stream
[libnoise port] spherical texture is one pixel too wide
I am trying to texture a sphere with spherical noise as described in Tutorial 8 in this post, using the unity port of libnoise. Like other noise tutorials I found, it seems to be written with the old sphere primitive in mind, which had different UV mapping from the new version. So I exported it as an OBJ file from an old unity version. I discovered that, for whatever reason, the normals were inverted, so i flipped them back in Wings3d. Now the mesh seems to be identical to the old primitive.
I applied the texture, but it still has a visible seam. Google told me it was likely due to mipmapping, so I set that to "false" in the textures constructor, to no effect. I also changed filtering mode to "point", and wrapmode was already set to "clamp" in libnoise.
Edit: As AlucardJ kindly found out, in the texture returned by GenerateSpherical(), the first and last columns of pixels are identical, but we don't know what is causing this. 
In the image, it definitely looks like a problem with the normals along the seam. Are you using the imported model normals, or recalculating?
I tested the script in Unity 5 using the new primitive sphere, and a procedural sphere found in the unity wiki :
There is no visible seam in the uvs, so the script works. However the Unity 5 sphere is really shonky, with stretched/compressed uvs and strange poles. The wiki sphere also has some strange things happening around the poles :(
I suggest using a sphere from a modelling program, or look into this sphere by CatLikeCoding.
EDIT : looks like UA is still broken, won't show images in comments. Here's that image of the 2 spheres : http://imgur.com/J4eYofx
Thank you for having a look at this! I tried both importing and calculating normals, with no visible difference. I also just tried out a few of CatLikeCoding's meshes, as well as the primitive generator script you linked. Spheres with higher resolutions make the seam less visible, and I can make the artifact almost disappear by setting "Tiling X" to .999 ins$$anonymous$$d of 1, as if the texture was just "a few pixels too wide", but I still don't know what's causing it, or how to really fix it.
On closer inspection, you are correct. There is a problem with the texture.
I changed the filtermode to point, and the material to LegacyDiffuse, and it showed the first and last column of pixels are the same : http://imgur.com/2gxZDi2
The only way I could find to remove this 'extra' column of pixels was to reduce the east variable. This works in the same way as your tiling experiment. Changing east to a value between 179.2 and 179.8 kinda gets rid of this pixel duplication, but this is a bodgy fix.
I assume the way to calculate this offset would be :
// offset east to remove 1 pixel column from returned texture
offset = ( 1 / textureWidth ) * 360
offset = ( 1 / 512 ) * 360 = 0.703125
east = 180 - offset = 180 - 0.703125 = 179.296875
Sorry, that's the best I can think of. Perhaps post on the LibNoise thread with a link to this question to see if one of the great brains there can think of a reason and fix.
I made a post in the libnoise thread and will continue working on this, I suspect that I will see how accurate the fix is when I get to looking at heightmapped terrain from this texture. Or maybe someone can come up with the cause, I'm really curious. Thank you again for your help!
