Image Filter artefacts when zoomed

[drunken_munki]

Actually this would just be sorted if LOVE would allow you to set the texture mode for openGL.

Texture modes in opengl:

The GL_REPEAT mode has textures repeat when you go past (0,0) to (1,1) range

The GL_CLAMP_TO_EDGE mode has textures stop at the last pixel when you fall off the edge.

EDIT -- I think the default is GL_CLAMP_TO_BORDER

Other modes: GL_MIRRORED_REPEAT, GL_MIRROR_CLAMP_TO_EDGE, etc.

EDIT -- I believe that you do not need to fluff your graphics by 1 pixel borders and you do not need to avoid every decimal fraction for scaling.

I believe the GL_MIRRORED_REPEAT mode would be the best suited default for this scenario, or nearly all scenarios really.

[s-ol]

Actually this would just be sorted if LOVE would allow you to set the texture mode for openGL.

Texture modes in opengl:

The GL_REPEAT mode has textures repeat when you go past (0,0) to (1,1) range

The GL_CLAMP_TO_EDGE mode has textures stop at the last pixel when you fall off the edge (I think this is the default)

Other modes: GL_MIRRORED_REPEAT, GL_MIRROR_CLAMP_TO_EDGE, etc.

Opengl does all of this and everyone's insinuations and insults to people learning LOVE2D is just plain wrong. No you do not need to fluff your graphics by 1 pixel borders. No you do not need to floor every co-ordinate. No you do not need to avoid every decimal fraction for scaling.

I believe the GL_MIRRORED_REPEAT mode would be the best suited default for this scenario, or nearly all scenarios really.

Texture modes don't help with quads though...?

[drunken_munki]

I believe the GL_MIRRORED_REPEAT mode would be the best suited default for this scenario, or nearly all scenarios really.

Texture modes don't help with quads though...?

I beleive it should work with all draw types.

If I can assume somewhere in the underbelly of love2d it is calling:
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);

with GL_LINEAR or GL_NEAREST

to set the filter mode when we call love.graphics.setDefaultFilter.


I could expect a new function love.graphics.setDefaultTextureMode would call the gl function:

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);

where the mode could be GL_REPEAT, GL_MIRRORED_REPEAT, GL_CLAMP_TO_EDGE, GL_CLAMP_TO_BORDER.

This attrubite is bound to the texture and then we would hope the scaling/rotating artifacts would go away with no other fuss if set to anything other than GL_CLAMP_TO_BORDER.

If we're asking does this work with buffer objets and other things like that, then I do not know -- however I would assume the same principle is applied when those textures are bound to the graphics memory.

[slime]

Actually this would just be sorted if LOVE would allow you to set the texture mode for openGL.

Opengl does all of this and everyone's insinuations and insults to people learning LOVE2D is just plain wrong. No you do not need to fluff your graphics by 1 pixel borders. No you do not need to floor every co-ordinate. No you do not need to avoid every decimal fraction for scaling.

LÖVE does allow you to set the wrap mode for images and canvases (see the [wiki](Image):setWrap[/wiki] and [wiki]WrapMode[/wiki] wiki pages.)
The clamp wrap mode is the default in LÖVE, and it is appropriate for dealing with this problem if Quads are not used.

However, as pointed out above, the OpenGL / GPU texture wrap mode only affects the borders of the texture, not the borders of a quad. With a texture atlas / sprite sheet this means it only affects the borders of the entire atlas, rather than the borders of each sprite within the atlas. So it doesn't solve this problem when texture atlases are used.

Modern GPUs have another technique that can get around the problems inherent to texture atlases: Array Textures.
However Array Textures require a modern GPU as well as custom shader code in order to use, so it might be challenging to integrate them into LÖVE in a clean and nice manner.

[arampl]

Modern GPUs have another technique that can get around the problems inherent to texture atlases: Array Textures.
However Array Textures require a modern GPU as well as custom shader code in order to use, so it might be challenging to integrate them into LÖVE in a clean and nice manner.

Also, all array textures must be the same size. Texture atlas can contain images of different sizes and you don't waste additional memory for smaller images (and don't have to crop them later).

I've read somewhere that border padding can't be an ideal solution for eliminating texture bleeding, it just shifts the problem onto another mipmap level. But you can use different version of texture atlas for each mipmap level. LÖVE v.0.10.0 allows creating such mipmaps (didn't tested this yet).

[slime]

Also, all array textures must be the same size. Texture atlas can contain images of different sizes and you don't waste additional memory for smaller images (and don't have to crop them later).

Each layer in an array texture has to be the same size, but you can theoretically have a texture atlas in each layer if you want (although in that situation you'll have most of the same problems that regular texture atlases do, of course.)

I've read somewhere that border padding can't be an ideal solution for eliminating texture bleeding, it just shifts the problem onto another mipmap level.

Yeah. Images don't use mipmaps in LÖVE though, unless you explicitly enable them.

[arampl]

Images don't use mipmaps in LÖVE though, unless you explicitly enable them.

Hm, thought SDL generates them automatically anyways. Scaled image's quality is good enough in LÖVE which I'm not sure is possible without mipmaps. And I have problems with texture atlas with borders' padding when scaling. Or SDL allows to load textures without mipmap generation and LÖVE uses this loading function?

[slime]

LÖVE doesn't use SDL for the love.graphics module, it uses OpenGL directly (and the SDL_Render API doesn't support mipmaps at all.)

You can enable mipmaps in LÖVE 0.9 with [wiki](Image):setMipmapFilter[/wiki], or in 0.10.0 with [wiki]love.graphics.newImage[/wiki](filename, {mipmaps=true}).

[arampl]

Good then! Tomorrow I'll try to make test suite for this problem.
I'm especially interested in creating custom mipmaps for atlases (on the fly, of course, using scaling).

[drunken_munki]

That's really interesting news thank you everyone.