Texture Sampling Glitches | Vulkan API Discord | Page 1

supple shard Dec 13, 2024, 1:20 AM

#

Currently experimenting with Fractals, and it seems they have an increased propensity to cause texture bleeding than without. Here's my current fragment shader

//atlasPos is the upper left (x,y) of the texture, atlasReg is the region to be rendered. Shaded among a quad's set of vertices
outColor = fragIndex >= 0 ? texture(texSampler[fragIndex], atlasPos + fract(fragTexCoord) * atlasReg )  * fragColor : fragColor;

I've tried toggling the mag and min Filters, but no luck far. Wanted to know if there was any suggestions to address this?

#

Above is the image with the fract function called,

#

This is without

#

Also a snapshot of the larger spritesheet for reference,

#

The bleeding only occurs on the border of a specific partition, since as shown here, there's plenty of blank space that wouldn't be present if the issue was mere overlapping texture coordinates.

vapid fossil Dec 13, 2024, 2:59 AM

#

looks pretty much like floating point errors to me, so try increasing padding between objects and try changing your address mode to clamp to edge/border color

#

if they're still there then debug those specific pixels and look at the texture coords

supple shard Dec 13, 2024, 5:46 AM

#

vapid fossil if they're still there then debug those specific pixels and look at the texture ...

I debugged the pixels (two pixels in the exact same spot in different builds) and found that every single floating value was the same, and that the color only diverged in the image sample.

Here's the assembly for the version without fract (comments show the resulting value)

void main() {
 ...
    int _34 = *fragIndex; //1
    int _35 = CopyObject(_34) : [[NonUniform]]; //1
    SampledImage<float2D>* _37 = &texSampler[_35] : [[NonUniform]];
    SampledImage<float2D> _38 = *_37 : [[NonUniform]];
    float2 _40 = *atlasPos; //0.00006, 0.00028
    float2 _41 = *fragTexCoord; //0.00249, 0.97737
    float2 _43 = *atlasReg; //0.01283, 0.06861 
    float2 _44 = _41 * _43; //_44 0.00003, 0.06706
    float2 _45 = _40 + _44; //_45 0.0001, 0.06734
    float4 _46 = ImageSampleImplicitLod(_38, _45); //_46 1.00, 1.00, 1.00, 0.00 <--- Blank alpha, like it's supposed to have
    float4 _49 = *fragColor;
    float4 _50 = _46 * _49;
    *_24 = _50;
...
}

And the version with,

...
int _34 = *fragIndex; // 1
    int _35 = CopyObject(_34) : [[NonUniform]]; //1
    SampledImage<float2D>* _37 = &texSampler[_35] : [[NonUniform]];
    SampledImage<float2D> _38 = *_37 : [[NonUniform]];
    float2 _40 = *atlasPos; //_40 0.00006, 0.00028
    float2 _41 = *fragTexCoord; //_41 0.00249, 0.97737
    float2 _42 = GLSL.std.450::Fract(_41); //_42 0.00249, 0.97737
    float2 _44 = *atlasReg; //_44 0.01283, 0.06861
    float2 _45 = _42 * _44; //_45 0.00003, 0.06706
    float2 _46 = _40 + _45; //_46 0.0001, 0.06734
    float4 _47 = ImageSampleImplicitLod(_38, _46); //_47 0.85039, 0.87714, 0.85565, 0.25 <---Color is not blank
    float4 _50 = *fragColor;
    float4 _51 = _47 * _50;
    *_24 = _51;
...

So despite the change being triggered by the call to fract it looks like the change is caused by the Sampled Image, despite it being the exact same image.

#

Also here're the Sampler Settings for further reference

vapid fossil Dec 13, 2024, 5:53 AM

#

soo incase you don't know what clamp to edge means

supple shard Dec 13, 2024, 5:56 AM

#

None of those modes helps get rid of the bleeding issue.

vapid fossil Dec 13, 2024, 5:57 AM

#

and did you try increasing the padding between sprites?

supple shard Dec 13, 2024, 5:59 AM

#

Yes

#

Left was the entire test spritesheet, right is an individually rendered one

vapid fossil Dec 13, 2024, 6:02 AM

#

there is already a line in the full sheet, is that intentional?

supple shard Dec 13, 2024, 6:02 AM

#

That line is a result of the artifacting

#

Removing fract causes it to disappear

#

Like so

vapid fossil Dec 13, 2024, 6:03 AM

#

so when you say "fullsheet" you mean doing the same thing but showing the whole image

supple shard Dec 13, 2024, 6:03 AM

#

It's not just sprites it happens to

#

Yes

#

It occurs with both the individual sprites and the whole texture/atlas

vapid fossil Dec 13, 2024, 6:04 AM

#

ok so manually check where on the sheet those UVs end up

#

prob weird coords and math

#

but you do know what fract does right?

supple shard Dec 13, 2024, 6:05 AM

#

I think I already tried that, with the example code above

#

Compared to identical frames from renderdoc

#

I used the artifacts on the side as a point of reference.

#

All the floating point values were the same except for the output of ImageSampleImplicitLod

#

The only contrast would be the Sampled Image

supple shard Dec 13, 2024, 6:10 AM

#

vapid fossil but you do know what fract does right?

And, fract converts the floating point values to the decimal only, if I'm not mistaken.

#

What I was trying to do was alter the shader so that I could extend texture coordinates past 1 but only repeat the specified region, and was following the method from this (old) post
https://jvm-gaming.org/t/glsl-making-a-texture-atlas-repeat/40457/5

JVM Gaming

[GLSL] Making a Texture Atlas repeat.

Something like this (kind of psuedo code) //You can make these attributes too to avoid having to change them between draw calls. uniform vec2 atlasCoord; //Top left corner of the atlas image uniform vec2 atlasSize; //Size of the atlas image attribute vec2 localTexCoords; //From 0 to 1, repeats outside that range void main(){ vec4 texture...

#

If there's a better way to do it, I'm up for it.

vapid fossil Dec 13, 2024, 6:29 AM

#

have you rules out fragIndex >= 0 ? being false and the fragColor being weird?

supple shard Dec 13, 2024, 6:32 AM

#

Yeah, if it were false, the texture wouldn't be rendered at all, it'd just be a big white square.

#

Holy sh*t

#

So it turns out this is actually a GPU issue