Having a difficult time with porting my immediate mode GUI to NGUI

[ArenMook]

1. I'd need an example to look at as your assumption is correct -- pixel filtering means no bleeding at all.

2. The offset is actually by a half-pixel, which is a DirectX 9 issue. You won't see this on a mac. Google "dx9 half pixel offset" for more info. It's a hardware thing.

In your case it's a full pixel because the size of the texture is likely half of its normal pixel size.

[Wisteso]

Aren:

Please check your PM inbox for a message labeled "Issue repro example and demo (topic 9253)"

The message has links to a stripped Unity project and a brief demo video on how to reproduce the issue.

[ArenMook]

Note what I said above:

make sure to add some padding to the sprites you're displaying that you notice an issue with. By default NGUI adds 1 pixel of padding around sprites (chosen in the Atlas Maker).

I opened your project, saw the issue right away. Opened the Atlas Maker, chose your atlas, selected White_Pixel texture and hit Update with the default Padding set to 1. Just like that, the issue was gone.

Padding is important...

[Wisteso]

Adding 1 pixel of padding has removed the bleeding, but instead, there are now small half-pixel gaps between sprites that should be perfectly butted up against each other.

However, I have a really strong instinct that the bleeding and gaps are only a symptom of the still unknown primary issue. The bleeding was not occurring at all unless the "fracturing" was happening as well and the the fracturing is also *still* happening with the 1 pixel padding.

I sent you a small screen recording that shows some observations that I think are pretty significant. Though I later figured out that some of those problems were due to the DX9 half pixel adjustment. Disabling the DX9 adjustment fixed some of the off-by-1 issues I was having, but it did not fix the fracturing. Considering the fracturing occurs on OS X too, I'm not surprised by that.

[ArenMook]

Make sure that everything is pixel-perfect. If you've adjusted sprite sizes at any point, they likely aren't anymore. Padding in between of sprites has no effect on what's visible.

Added 1 pixel on sprites is something NGUI adds if the sprite is not using dimensions that are dividable by two. So for example a 17x17 sprite will have size of 18x18. The drawn area will be 17x17, but the widget size will be 18x18. This is done because otherwise a centered sprite would be using floating point position values.

[Wisteso]

For the most part, I think I've finally (functionally) solved the issue by disabling the DX9 half pixel correction on line 837 of UIPanel. Disabling that line has fixed almost all symptoms of the issue except for one or two (read below). It also confirms what I suspected, which is that pixel padding around all sprites in the atlas is actually not needed when using point filtering. I no longer have any texture bleeding or half pixel gaps, and I've been able to remove the 1 pixel padding around the sprites as well. The fix also makes sense too, since I was not seeing those symptoms on any platform except for Windows (and a tiny bit on OSX, read below for that).

It seems that the code that you're using on line 837 of UIPanel needs some revision. I don't think anyone's noticed this issue so far because: it's only a half pixel change that's usually hard to notice, it's mostly hidden by linear filtering, and it's only visible on Windows systems.

The only remaining symptoms are that random quads of a Sliced sprites are being distorted. I see this symptom on all platforms though so it's probably a totally separate bug. I've attached a screenshot of what it looks like with this post. There seem to be two workarounds...   

1) Use a proper SD atlas for SD mode instead of an HD atlas with 0.5 pixel size. (right now I'm cheating and using an HD atlas for both modes)
2) Use different dimensions for the UISprite that make the UV math happy. (being even and a multiple of 4 is not enough, apparently)

As for your suggestions: I just need to figure out the problem with Sliced sprite, but everything should be pixel perfect already - I frequently do a sweep over my UI check for corrupt/bad values. All sprite dimensions are already divisible by 4 as well.

[ArenMook]

The half-pixel offset is most certainly necessary. Here's what a button looks like with and without half pixel offset in Unity:

[Wisteso]

I believe you, but that's just with DirectX.

Messing with mHalfPixelOffset does not help me in DirectX mode. However, in OpenGL mode, with mHalfPixelOffset set to false, everything is mostly peachy. I think using a proper SD atlas will fix the remaining issues that seem to be due to floating point round error + nearest-neighbor resampling.

It seems that it's possible to detect if running in OpenGL mode ( http://docs.unity3d.com/Documentation/ScriptReference/SystemInfo-graphicsDeviceVersion.html ) in which case mHalfPixelOffset should be set to false.

E.G.

1. if (mHalfPixelOffset) mHalfPixelOffset = (SystemInfo.graphicsShaderLevel < 40) && (SystemInfo.graphicsDeviceVersion.Contains("Direct3D"));

or maybe just

1. if (mHalfPixelOffset) mHalfPixelOffset = SystemInfo.graphicsDeviceVersion.Contains("Direct3D 9");

Of course, this leaves the question of "Why does DirectX look messed up still while OpenGL is mostly fine?" but, for now that's something I can ignore. I greatly prefer OpenGL, and our main platforms are OpenGL based.

[Wisteso]

Just another data point to add...   using "-force-d3d11" also fixes most issues. There's some minor issues in SD mode, but again (like with OpenGL), I think they're due to resampling textures to 50% without using linear filtering. Proper SD textures for SD mode would not need resampling and should fix the issue.

So to recap...
"-force-d3d9" (d3d9 is used by default anyway) = numerous issues - looks messed up in HD and SD modes
"-force-d3d11" = HD mode looks great, SD mode has some issues that should be fixable with proper atlas
"-force-opengl" = HD mode looks great, SD mode has some issues that should be fixable with proper atlas. However, NGUI needs to not apply D3D9 half pxiel correction by checking if the API is OpenGL or DirectX

[ArenMook]

Yup, DX9 is the only one that uses the stupid half-pixel offset BS. I often wonder what "genius" added that gem in there.