NPOT artefacts on .Repeated = true texture?

[Robin]

Afternoon gents,

I'll keep it simple.

We all know that when running non power-of-two textures you get slight artefacts which make the texture look 'off'. EDIT - This is entirely assumed on my part due to consistencies when using DirectX8 like... 5 years ago. May not be true?

I'm getting the same artefacts when running a power-of-two texture with the .Repeated flag set to true on a larger NPOT sprite.



I had a look around but couldn't really find any information on this. Should this be happening? Is there a workaround?

The artefacts are showing up on the grid as well as the 'transparency' checked background. The grid is a 32x32 texture, the checked effect is a 16x16 texture. Both of them are running on a >1024 sprite size, but occur on smaller ones too.

I'm running the .NET implementation of SFML 2.0.

Thanks,
Robin

[eXpl0it3r]

I'm glad you're still around, because I'm still waiting for that editor...

Are you sure artifacts happen because of NPOT textures?
Non pixel precise placing usually happens, when the view or sprite is set to a floating point value, thus the graphic cards will have to interpolate since you can't draw points between to neighboring pixels. But this interpolation often leads to objects being off by 1 pixel or a 1 pixel width line disappears completely.
I'm a bit surprised that this happens with repeating textures though...

Make sure the view and sprite are set to integer values and if possible use nice zooming factors.

[Robin]

I'm still plodding along with it. Things are slow due to work and other commitments, but it's always in the back of my mind.

I figured it'd be something to do with NPOT due to the fact that the rendering is flawless if the total size of the sprite is POT. The only time I've seen slight 'skewing' like this is when loading larger NPOT textures on non-repeating sprites. I can't be 100% sure on that without testing it a bit more, though.

I'll get some time with the code tomorrow and look at the areas you mentioned and get some more information. I only really noticed it an hour or so before posting, so haven't had much time to screw around.

Thanks for the help!

[Robin]

Good morning!

I'm back after doing a bit more sleuthing.

Every single rendering control in this application is based off a SFML 'mother class' which handles management of the window, view, drawing cycle etc. You basically just build more specific functionality whilst inheriting this class and add an override which the mother class will pull from to render -- simple stuff.

First of all, here's the code for initialising the texture and sprite. (Ignore the lazy resource manager reference, it was just a basic class to avoid duplicate loading. I'm planning on writing a real one at some point.)

Code: [Select]

_checkedTexture = ResourceManager.Instance.LoadTexture(Application.StartupPath + @"\content\textures\transparency.png");
_checkedTexture.Repeated = true;
_checkedSprite = new Sprite(_checkedTexture);
_checkedSprite.TextureRect = new IntRect(0, 0, 0, 0);

Later on I set the TextureRect like this:

Code: [Select]

_checkedSprite.TextureRect = new IntRect(0, 0, ObjectWidth, ObjectHeight);

ObjectWidth and ObjectHeight are both integers which store the size of the sprite. As such I don't think they'll be causing a problem with floating point rounding.

The view is created (and re-created on resize) like this:

Code: [Select]

View = new View(new FloatRect((XOffset * -1), (YOffset * -1), ClientSize.Width, ClientSize.Height));
View.Center = new Vector2f(XOffset + ((int)View.Size.X / 2), YOffset + ((int)View.Size.Y / 2));
RenderWindow.SetView(View);

Now the fact that I'm forced to pass a FloatRect through to create that view is slightly more interesting. From all the examples I looked at when picking SFML up this was the standard way of doing things.

Could this be creating the rounding errors you talked about?

ClientSize.Width and ClientSize.Height come from the System.Drawing.Size class and are both integers.


I did some more screwing around with a more isolated environment to re-create the artefact problems I was having. This is done using a simple ScrollTexture view, which is just the SFML mother class with the ability to have a texture passed through to it.

This first image shows a 1024x1024 texture with a grid pattern of 32x32 squares which alternate between 100% red and 100% transparent, thus showing off the checked pattern which is the .Repeated=true sprite with a 16x16 texture assigned to it.



Zero problems.

However, if I add an extra 32pixels to both dimensions to take it to a 1056x1056...



Chaos! This was actually the first time I saw such aggressive artefacts showing up, so it was slightly shocking.

From what I could tell before my eyes started giving up on me, the 1056x1056 texture is actually rendering properly... it's the repeated background which is screwing up.

However, this is not consistent across all sizes.

This is a 960x384 texture.



The raw image is insanely smooth -- the artefacts are 100% from the rendering code. If you zoom in you can see the repeated background screwing up once again, something which never happens with a standard POT sprite size.

Here are a couple more images showing the artefacts in other situations. I ended up loading a screenshot in to Photoshop to see exactly what kind of skewing was occurring.





I hope this gives a bit more context for my problem. Again, any help would be greatly appreciated!

[eXpl0it3r]

Pixel perfect rendering has always been a bit of a pain with SFML/OpenGL...

It's kind of hard to tell where the problem now really is, since you've multiple things mixed.

Does the checkerboard pattern draw normal if you don't load an image at all?
Does the checkerboard pattern draw normal if the loaded image doesn't cover it?
Does the checkerboard pattern draw normal if you move a POT texture a few pixels off?

From what I can see there seems to be something going wrong, when drawing transparent parts of an image on top of the repeated pattern. And you say this only happens with NPOT textures?

What if you for once used a non-repeated texture for the checkerboard background, would it still get corrupted?

[Robin]

Pixel perfect rendering has always been a bit of a pain with SFML/OpenGL...

It's kind of hard to tell where the problem now really is, since you've multiple things mixed.

Does the checkerboard pattern draw normal if you don't load an image at all?
Does the checkerboard pattern draw normal if the loaded image doesn't cover it?
Does the checkerboard pattern draw normal if you move a POT texture a few pixels off?

From what I can see there seems to be something going wrong, when drawing transparent parts of an image on top of the repeated pattern. And you say this only happens with NPOT textures?

What if you for once used a non-repeated texture for the checkerboard background, would it still get corrupted?

I realise now my post had a lot of noise in it. I was simply giving examples of similar corruption occurring when rendering NPOT textures.

The problem is that if I have a 512x512 sprite, my checkerboard pattern will repeat over it flawlessly. If I resize that to, say, 528x528 the checkerboard pattern will appear like it does in those screenshots.

Ignore everything else, that was simply my debugging process.

If a sprite is POT, the repeated texture is fine. If a sprite is NPOT, the repeated texture has artefacts when rendering. The texture being repeated is POT regardless of the situation.

I can create a stand-alone example of the SFML control which shows this behaviour if that would help.

[eXpl0it3r]

Ah okay.

Have you tried it with a minimal example, where you simply draw a texture repeated without any controls or anything else around it?

Btw. what graphics card do you have and is your driver up to date?

[Robin]

That was a very good idea.

I ran it in a more standard SFML Window environment. Not only did the repeated texture render flawlessly, but so did the NPOT textures which normally exhibit artefacts when rendering within the WinForms environment...

It seems there is a problem with how I'm handling rendering within the SFML control.

From what I can see, however, there is very little code which could be screwing up here.

Here's how I initialise the class:

Code: [Select]

private void ScrollableSFML_Load(object sender, EventArgs e)
{
    RenderWindow = new RenderWindow(Handle);
    SetView();
    Render();
}

And here's how I create the view:

Code: [Select]

public void SetView()
{
    View = new View(new FloatRect((XOffset * -1), (YOffset * -1), ClientSize.Width, ClientSize.Height));
    RenderWindow.SetView(View);
}

Here is what I do when the client area is re-sized:

Code: [Select]

public void SetAndRefreshView()
{
    View = new View(new FloatRect((XOffset * -1), (YOffset * -1), ClientSize.Width, ClientSize.Height));
    View.Center = new Vector2f(XOffset + ((int)View.Size.X / 2), YOffset + ((int)View.Size.Y / 2));
    RenderWindow.SetView(View);
    Render();
}

You mentioned earlier than floating point numbers can causing rounding issues in texture rendering. Do you think that the way I'm initialising the view rect could be causing these problems?

[upseen]

Do you think that the way I'm initialising the view rect could be causing these problems?

Why not try?

Why manually set sf::View::Center at all? A quick look at sf::View()'s source tells you SFML does it in your stead automatically, without flooring (casting)...

[Robin]

Why not try?

Why manually set sf::View::Center at all? A quick look at sf::View()'s source tells you SFML does it in your stead automatically, without flooring (casting)...

You're right on the money, there. If I remove the integer casting from the View.Size.X in the View.Center change it fixes everything.

Because the artefacts were always there with NPOT rendering I figured it was just how things were... especially because I had similar problems dealing with DirectX8 around 5 years ago. Thinking back I probably just had some dodgy casting errors there too as I was writing my own classes to deal with rendering when I had no idea what I was doing.

Thanks for the help. You may have also retroactively fixed a problem I had when I was a teenager on top of things. :^)

[eXpl0it3r]

especially because I had similar problems dealing with DirectX8 around 5 years ago. Thinking back I probably just had some dodgy casting errors there too as I was writing my own classes to deal with rendering when I had no idea what I was doing.

Well that's quite possible. A few years back GPUs often went crazy when dealing with NOPT textures. However we've come quite a bit and drivers/GPUs have "learnt" how to deal with POT textures.

[Robin]

Well that's quite possible. A few years back GPUs often went crazy when dealing with NOPT textures. However we've come quite a bit and drivers/GPUs have "learnt" how to deal with POT textures.

I'm just happy I've got something like SFML to use now-a-days. Working with lower level libraries like DirectX and OpenGL always hurt my head. Can't deal with all the fractions.

Thank you both for your help, it really saved me from a frustrating situation!