Texture on CustomSceneNode glitch

[Rayshader]

Hello everybody !
I'm actually using Irrlicht to do a prototype of my project.
I compiled the latest version of Irrlicht on CodeBlocks with MinGW 64 (POSIX + SEH).
And use the same compiler for the project, I configured Irrlicht to use OpenGL.

Currently, I'm generating a terrain which is made of chunks of the same size (100 * 100 per chunk).
In each chunk there is 100 cells by side, each cell is scaled by 10.
I want to texture my terrain with this image :

Therefore regarding the Z value average of the four vertices of a cell, I use an offset for the UV coordinates of each vertices.
For example, I have a Z which represent the grass :
My offset will be : (2.0f / 3.0f, 0.0f)
Then I apply it to my computed UV : going from 0.0f to 1.0f (with a step of 50), I scale it down by 3.0f on U and 2.0f on V.

Problem is that when rendering, I can see a line of pixel on each side of a cell which is not from the grass texture :
left = sand
top = snow
right = water
bottom = snow


I try to shift the offset with a value like 1.0f / 768.0f (the image is 768px * 512px). But not conclusive...
Any idea why this problem occur and how to solve it ? Maybe by configuring the material with a setting I don't know about ?

Or would it be better to texture by using 6 materials each one using a texture...? But here again I don't know how I can tell the vertices which material to use to represent the texture I want.

Thanks in advance, you're help will be much appreciated !

EDIT:
After few messages, here a resume:
Using a texture atlas cause this problem and mipmap introduce this glitch.
Half-pixel correction might be a solution but I couldn't make it works, I think due to mipmap problem.
The solution I have found is to repeat your own texture with a padding (at least 40 pixels) and to adapt your UV to the texture in the square. No mipmap problem with an enough big padding.

[CuteAlien]

Just so we know what we talk about exactly:
Are you using something like addTerrainSceneNode or addTerrainMesh for this?
Are you using one terrain-mesh per chunk? Or are all those chunks in a single mesh somehow?
(best if you can just post the related code where you create/render that stuff).

[kornwaretm]

looks like a LOD issue, the math is correct but the sampler still interpolating the neighbor pixel. try to render test it without mipmaps. if the line gone, it means that you have to mess with LOD in shader.

[Rayshader]

@CuteAlien:
I'm not using anything prebuild in Irrlicht like addTerrainSceneNode or addTerrainMesh.
I'm inheriting from ISceneNode and render from my own generated vertices, normals and uvs. Like the tutorial "Tutorial 3: Custom SceneNode".
One ISceneNode per chunk.

@kornwaretm:
LOD ? Is Irrlicht providing LOD ? Even for custom ISceneNode ?
Hum shader, it don't use shader neither...
I didn't set mipmap...
I use default value of SMaterial and I set following properties :
Wireframe = false
Lighting = true
BackfaceCulling = false

Thanks for answer so fast

[CuteAlien]

@Rayshader: So this is one single node for all chunks? And one mesh with different mesh-buffers? Or just one meshbuffer and uv-coordinates pointing to some texture-map?

[Rayshader]

No no, for X chunks, there is X SceneNode.
Each SceneNode receive its list of vertices, normals and uvs.
I split in multiple SceneNode otherwise I would overflow the limit of 65535 vertices (I tried to switch from 16bits to 32bits, but Irrlicht crash in this case).
Each SceneNode use the same texture.

[CuteAlien]

And the white line is exactly at the border of junks? Maybe vertices are not exactly identical (tiny floating point inaccuracies in calculation could cause that). Print out 2 of them which should be identical with all numbers past the point to see if they are really the same.

Also in case it's useful to you - the limit is not 65535 vertices per mesh but per meshbuffer. This is somewhat important as working with one mesh and one node might be simpler sometimes.

[kornwaretm]

LOD ? Is Irrlicht providing LOD ? Even for custom ISceneNode ?

i'm talking about the texture LOD, mipmap levels that automatically generated and selected based on transformations, lets say you want pixel at 300,300, the gpu will select a pixel, like you might not expected, again its uses mipmaps to select texel based on distance, so textured object are much "smoother". to dissable mipmaps driver->setTextureCreationFlag(ETCF_CREATE_MIP_MAPS , false).

Hum shader, it don't use shader neither...

dont worry they are hidden somewhere in the irrlicht code

ok, judging from the image you post. is it correct that you use one big image tiled with all required texture? not seperated texture? because i see that white line look like the white color from the white texture below the grass texture, probably due to the vertical resolution not being power of two. floating point accuracy can cause this as CuteAlien mentioned.

[Rayshader]

As a chunk is 100 * 100, and as I scale cell by 10, a chunk is 100 * 10 per 100 * 10.
A texture (grass) do not fill the entire chunk, the chunk is divided so texture fill a cell of 50 * 50 (or scaled 500 * 500).
Which lead me to this kind of output (only 1 chunk) :

Delimited square represent a cell of 10 * 10. Glitch appears every 500 * 500.

I check my vertices, and yes they are exactly identical.

I think it comes from the fact that I use 2.0f / 3.0f as a U value for grass which lead to a 0.333334f value.
But where it is very strange is that the V value start at 0.0f, but when rendering, it show one line of pixels like it comes from the bottom of the image, where the snow ends.
I could understand that a value of 0.333334f bring a problem when picking the pixel on the texture, but an exact value as 0.0f : it just shouldn't ?

Thank you for the tip about vertices.

[Rayshader]

i'm talking about the texture LOD, mipmap levels that automatically generated and selected based on transformations, lets say you want pixel at 300,300, the gpu will select a pixel, like you might not expected, again its uses mipmaps to select texel based on distance, so textured object are much "smoother". to dissable mipmaps driver->setTextureCreationFlag(ETCF_CREATE_MIP_MAPS , false).

Oh ok

dont worry they are hidden somewhere in the irrlicht code

Good to know ^^

ok, judging from the image you post. is it correct that you use one big image tiled with all required texture? not seperated texture? because i see that white line look like the white color from the white texture below the grass texture, probably due to the vertical resolution not being power of two. floating point accuracy can cause this as CuteAlien mentioned.

Yes one big image tiled with all required texture. I don't know how I could use separated textures, if you can give me a clue or two on this, that would be so great !
So floating point accuracy regarding the texture, not the vertices.
I'll try to load an image of 1024 * 1024 with blanks...

EDIT : 1024 * 1024 texture didn't resolve the issue...

[kornwaretm]

probably similar whit my problem here. http://irrlicht.sourceforge.net/forum/v ... tm#p290677 . i use custom shader thou. basically it compute the lod manually in glsl via texture2dlod() function. pretty certain that it was a mipmap problem. my recomendation is testing the mipmap first by calling driver->setTextureCreationFlag(ETCF_CREATE_MIP_MAPS , false) before any getTexture call.

[Rayshader]

I call driver->setTextureCreationFlag(ETCF_CREATE_MIP_MAPS, false) before any getTexture.
Here the result :

Despite the "noisy" aspect, lines are still displayed. Here with a big image of 1024 * 1024 px.

[MartinVee]

Have you tried a half-pixel correction when computing the texture matrix?

Check this post for a sample on how to compute a texture transform matrix. See this MSDN article that explains why we need a half-pixel correction.

[Rayshader]

I don't compute the texture matrix my self...
So I've read the MSDN document and the StackOverflow post and I understand the purpose of the half-pixel correction.
But from what I see on my terrain, I don't see how half-pixel correction would resolve this glitch?
Because the lines of pixels unwanted shows on the four side, not just the right and bottom sides. From what I understand of the half-pixel correction, it would be useful if only the left and top sides showed the unwanted lines of pixels. In this case, half-pixel correction would nicely translate so the left and top sides don't glitch anymore.

Or am I wrong ?

[kornwaretm]

if mip map and texture filtering doesn't remove the glitch. please do check your texture. image editor like photoshop sometimes do unnecessary interpolation during export, this means photoshop smoothing pixels especially the one with detectable edges, confirm your pixel locations. if this is the case i'm pretty sure that photoshop has a settings somewhere to disable this filtering (i think it called bilinear filtering / nearest neighbor / or other exclusive filter ).

in my opinion the half pixel correction is totally make sense here. say you need pixel at 512, 512 texture space. yo do so by saying u = 0.5 v= 0.5. this uv will get transformation to texture space, involving a lot of things such as mipmaps, filtering it means there will be float to integer (floating point accuracy). by doing a half pixel correction at worst case you still get desired coordinate minus one pixel which is better than overlap one pixel.