Texture on CustomSceneNode glitch

[Rayshader]

I've check the way I export the image with Photoshop, in deed I was using bicubic or bilinear, I set it to "Keep details" with JPG and PNG formats. No change.
Ok I'll try the half-pixel correction on the texture matrix... Just not sur how it works. The matrix describe to Irrlicht how to retrieve pixels from the image for a given UV ?

[Mel]

You're doing it rigth, don't worry, it only lacks a few tweaks.

First, when using texture atlases, it is good to leave a bit of padding around each tile of the atlas that repeats the border pixels and apply the half pixel correction. That provides you with enough information to seamlessly repeat the texture from a side to the other, and avoid the lines.
Then, In a shader, you can limit the mip level that reaches the renderer using tex2dlod (or so, i might be mixing it with HLSL, but GLSL has something similar), so, you can prevent it from reaching the lowest mip levels (when the textures start to mix between them) so you always have the looks of a single texture, despite having many and that should do it. Good luck!

Also... texture arrays when?

[Rayshader]

Well, I'm lost...
Adding a bit of padding won't increase the line problem ? Well I try to let one line of pixel on X and Y between each textures of the image... It gives me larger lines of blank.
Also, I have no idea on how to manipulate the matrix of the texture... When I call buildTextureTransform, I send a translate vector with the value 1.0f / 2.0f / 1024.0f so that it is a half pixel of the image. With this call, the top left sides of the texture don't show the line, but the right bottom sides still show it. When adding a vector to scale down, the opposite happen : top left sides show lines, right bottom sides don't show lines...
For now I just disable mipmap level to get rid of it... As I have never used shaders, neither in Irrlicht...

Texture arrays are implemented in Irrlicht ?

[Mel]

Texture arrays? Not yet oficially. There is a patch somewhere. I can't tell where though,

The bottom problem is the mip mapping reaching sooner or later to the edges of the tiles, and the simplest way is to use a shader to control it. You can control the texture matrices but you can't change it on a per pixel basis, that is what you would need here, at least, IMO.

[Rayshader]

... you can prevent it from reaching the lowest mip levels (when the textures start to mix between them) so you always have the looks of a single texture...

So, actually, I have an half-pixel correction on the UV of my vertices, which fix the left-top borders.
So for the others borders, I may use a shader to limit the mip mapping level. That would prevent texture to mix between them. I repeat just to be sure I understand ^^
By googling I found for GLSL the following functions :

• - textureQueryLod : to query currently used lod.
  - textureLod : to apply the mipmap level.

I hope this will do the trick... Let's start using shaders on Irrlicht !
Thank you for all your answers guys !

[Rayshader]

I follow the tutorial on Shaders. I'm able to load vertex and pixel shaders files and apply the created material to my terrain scene node.
I tested the shader with a piece of code doing a cel shading effect.
So shaders compile and render properly.
I force my texture by calling textureLod with a mipmap level of 0. No change on the terrain. So limiting the mipmap level do not seems to be the solution.
When applying half-pixel correction on my UV, I can have a good result, but when looking far away, blank lines shows up... Which make seems it is a mipmap level problem...
So I use half-pixel correction and disable mipmap (and shader forcing mipmap to 0) : blank lines again when looking far away.
I'll try texture array...

[LunaRebirth]

This may be silly and/or unrelated but have you tried messing with the far/near camera views, since you're using multiple nodes?
I've noticed an issue where if I have a block close (but not touching) another block, the further away I move the camera, the more you can see the walls "merging" together and eventually being inside the other.
When I messed with the near/far camera views, it mostly solved the issue other than that it still had the problem in a very far distance away. Never solved it, but it's looking better than it was.

[Rayshader]

I've tested to mess with the far/near camera views, but no change. Well in anyway, I can't rely on this as a solution as I need to fully control this parameter.
Here, the problem isn't about "merging" between multiple nodes, it is for each node, in each node...

[CuteAlien]

As mentioned above - you don't need different nodes. The vertex-limit is per mesh-buffer, not per mesh. So can be a single node.

[Mel]

I've tested to mess with the far/near camera views, but no change. Well in anyway, I can't rely on this as a solution as I need to fully control this parameter.
Here, the problem isn't about "merging" between multiple nodes, it is for each node, in each node...

As a rule of thumb, messing with the near value of the camera isn't a good idea at all: As long as possible, it should remain 1, if not, it should be more than 1, rarely less than 1 and NEVER 0 or negative. When it is less than 1 messes the ZBuffer precission, the perspectives remain more or less unaltered, but there could appear Zfight issues, so it is not a safe practice

[kornwaretm]

i was thinking, half pixel correction should be enough for this problem. firstly, lest confirm the half pixel correction implementation, before taking any step further or take suspicion at other places.

Code: Select all

 
// untested probably wont compile
// just for explanation purpose
f32 imageWidth = 1024.0f;
f32 imageHeight = 1024.0f;
vector2df fullResolution(imageWidth, imageHeight);
vector2df pixelSize = vector2df(1.0f, 1.0f) / fullResolution;
vector2df halfPixelCorrection = pixelSize * 0.5f;
 
//     lets see the quad
//  0--1
//  |/|
//  2--3
S3DVertex verts[4];
verts[0] = S3DVertex(
                        vector3df(0.0f, 0.0f, 0.0f), // position
                        vector3df(0.0f, 0.0f, 1.0f), // normal
                        SColor(255,255,255,255),   // vertex color
                        vector2df(0.0f + halfPixelCorrection.X , 0.0f + halfPixelCorrection.Y ))); // check the sign plus or minus
 
verts[1] = S3DVertex(
                        vector3df(100.0f, 0.0f, 0.0f), // position
                        vector3df(0.0f, 0.0f, 1.0f), // normal
                        SColor(255,255,255,255),   // vertex color
                        vector2df(0.5f - halfPixelCorrection.X , 0.0f + halfPixelCorrection.Y ))); // check the sign plus or minus
 
verts[2] = S3DVertex(
                        vector3df(0.0f, -100.0f, 0.0f), // position
                        vector3df(0.0f, 0.0f, 1.0f), // normal
                        SColor(255,255,255,255),   // vertex color
                        vector2df(0.0f + halfPixelCorrection.X , 0.5f - halfPixelCorrection.Y ))); // check the sign plus or minus
 
verts[3] = S3DVertex(
                        vector3df(100.0f, -100.0f, 0.0f), // position
                        vector3df(0.0f, 0.0f, 1.0f), // normal
                        SColor(255,255,255,255),   // vertex color
                        vector2df(0.5f - halfPixelCorrection.X , 0.5f - halfPixelCorrection.Y ))); // check the sign plus or minus
 
 

[Rayshader]

This is the way I implement it in my code.
I add the half-pixel correction when I have U = 0.0f or V = 0.0f, and I subtract with U = 1.0f or V = 1.0f.
Here the result when I zoom :

And if I look far away, blank line is shown, the far I look, the biggest is the line. (Makes me think it is a mipmap problem).

[Rayshader]

When searching I found this article from Ogre3D's community: link.
So I try the trick by using the following image, I decrease the number of different textures as I wanted to keep a size of 256 * 256 for each textures:

And here a screenshot of the result, as expected mipmap don't cause any problem with this solution (there isn't half-pixel correction):

I use half size of each texture for padding, so I think I can reduce this to a padding of ~16 pixels. Until it match with mipmap levels no glitch should been showed.

[LunaRebirth]

Thanks for sharing your solution, I learned from it

[Rayshader]

You're welcome.
By the way, 16 pixels padding was to small, texture bleeding start to show when looking far away.
I can store 9 textures of 256 * 256 pixels each with a padding of 42 pixels for each borders in one big image of 1024 * 1024.