Random question about uvs and seams from packed textures

Rigging
#1

Hi folks, long time no see!

I am mucking about with some stuff hlsl-wise, and I’ve come across something annoying which I can’t workaround. It is no big deal but one of those annoying things which keeps me noodling away. I’ve been at it for hours now, outputting the uvs, transformed uvs, allsorts of stuff, to see if I can understand why it’s happening, but I can’t as yet.

I am hoping that maybe one of our shader gurus will be able to explain to me what’s going on! :):

I was writing up this UDK packed-texture example in hlsl to fiddle with in max.
http://udn.epicgames.com/Three/TerrainAdvancedTextures.html#Texture%20Packing:%20Implementing%20large%20texture%20tile%20sets

I’ve attached a screenshot of the shader in max. It’s just outputting diffuse pixels, and I have taken into consideration the padding suggested in the article. Despite having some padding there’s still a pesky seam visible if the filtering of the texture is anything other than ‘NONE’.

Maybe this is just something which can’t be avoided in this technique, but it seems that it should be doable, it would be great if any of you guys can explain to me what I’m doing wrong.

Cheers,

cw

#2

I think what you’r talking about is http://wiki.polycount.com/EdgePadding?highlight=(\bCategoryTextureTechnique\b) try adding more ‘padding’???

#3

Thanks Shawn, but I’ve taken the padding into consideration, I’ve even now plumbed in some spinners in the shader UI to adjust the pad values per tile, and even when the bleed is visibly gone, there is a miniscule seam.

It is not apparent when the shader just texture samples in the normal way, only when it is sampling and blending the 4 quadrants.

I have checked removing all the blending stuff, so it is essentially simply rescaling the UVs to a portion of the texture, still makes seams.

My clumsy debugging makes me suspicious of the ‘frac’ intrinsic command, but what I don’t understand is how it can not work, I’m hoping someone can tell me some techno gubbins which is the reason, it will put me off the scent. I’m like a dog with a bone on one of these annoying things - just can’t leave it alone! :):

#4

I’m stabbing in the dark here but is it caused by sampling the lower mip levels of the packed texture?

#5

There is an option for “Use Full Precision UVs” in the static mesh editor, have you checked it for that object?

It might help.

Use Full Precision UVs - By default static meshes use half precision (16 bit) UVs in order to save memory. Enabling this option forces the mesh to use full precision (32 bit) UVs. This might be needed for certain cases when seeing artifacts with texture mapping the mesh.

http://udn.epicgames.com/Three/StaticMeshEditorUserGuide.html

#6

Yeah Stefan, it must be something to do with that, but even when looking at the texture such that you can see the pixels’ size, and eradicate that bleed by moving the padding, there is a smaller than 1 texture pixel sized bleed of some kind still visible. Setting mipfilter to NONE removes the problem so it seems likely that it is something in that world causing the effect.

Probably something which is unavoidable, but I just wondered if there was a hardware or code explanation for why that is. It’s no big deal, really, just curiosity on my part.

I should try something other than max to look at it I suppose, max is not the most unbuggy of shader viewing platforms. :slight_smile:

@jonathan - I’m not looking at it in UDK/UnrealED, just in max’s viewport. Could be a max thing. I will have a try in another platform and see what occurs. Thanks to you all for your input. :slight_smile:

#7

same thing happens in fx composer :frowning: i’ll try UDK next.