If I divide a large Texture into some small ones,and use these to render some quads.then piece these quads together in correct order, which looks like use large Texture rendering one large slice.The Problem is that between these small quads the Texture looks non-linear.How to deal with these?
Use texture borders.
A ‘visual’ sample with 1D textures :
left border texel | normal texture data | right border texel
tex A :
B0 | 0--------1 | B1
tex B :
B1 | 0--------1 | B2
displaying two quad side by side with texcoords going from 0 to 1 will then show no seam.
quad A | quad B
Texture looks non-linear
I guess you mean that textures have broken filtering at edges.
Imagine the situation:
You have large texture with 4 colors:
-upper-left quarter of teture is black
-upper-right is white
-lower-left is red
-lower-right is green
If you split this texture into 4 smaller textures then you will have:
-completely black texture
-completely white texture …
You will clearly see the edges of textures because there is no filtering between different textures.
The solution is to have textures larger by one texel and instead of using texture coordinates from 0.0 to 1.0 use coordinates from:
0.5 / textureSize
to:
(textureSize - 0.5) / texture size
last texel of each texture should be identical to first texel of next texture.
For example - instead of splitting 64x32 texture into two 32x32 textures you should split it into two 33x32 textures or two 32x32 textures and one 4x32 texture.
You can also split 64x32 texture into two 32x32 textures but you must copy first column left texture into last column of right texture and vice versa.
just put 1 in the border parameter of glTexImage2D, and specify 2^n+2 pixels (including left and right border).
And do NOT use anything other than 0 to 1 texcoords,
properly used borders are meant to deal with this automatically.
Right, it become a texture border problem.if I set a texture width as 64+2,how to index it.if I want to render 31 points with index 0~31 in texture data,should I do this: (0+1)/(64+2)~(30+1)/(64+2).If we set the border, the index 0/(64+2) is the left border, Right?
Use index mode in shader, the index value type is BYTE which value is from 0 to 255.I think the border and normal texture data are all included in it.If it is true, the texture would be split 256 parts,how can we use 256 indexes to match 256+2 texture datas including border.We do not always use 0 to 1 texcoords,because the bricksize does not always match the object size.
I have a idea. Can I do this:
uniform sampler3D volume;
uniform sampler1D transferfunction;
void main()
{
float data = texture3D(volume, gl_TexCoord[0].stp).a ( +1/258 );
gl_FragColor = texture1D(transferfunction, data);
}
after we get data from tex3D,plus 1/258 to match the lookup table. Is it reasonable?
And now I do not understand how texture3D() convert BYTE data to float data. Does it do this:
(BYTE_data)/1D_texSize?
Check my answer in the beginner’s forum.
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.