Pixel Perfect Camera should NOT have bilinear as a filter mode option.

Every time I open up the editor, I have to manually go into this file and modify it to always return Point to ensure that my art actually looks like nice pixel-perfect pixel art. If I don't, it looks like blurry garbage. I don't understand why this is an option to begin with. The whole point of this package is to achieve crisp, pixel-perfect art.

Please fix this.

Thanks.

 

You can see from the code that the filter mode is set based on the

m_Internal.useStretchFill

boolean being true. Why is it true?

From the blog post about Pixel Perfect 2D:

https://blogs.unity3d.com/2019/03/1...up-your-unity-project-for-retro-8-bits-games/

 

It has the complete opposite effect for my mobile game.

 

We really need the ability to override the use of the bilinear filter mode. I understand why you have it in place but there's no reason to not be able to override it. For my game, I do not want it.

 

Using stretch fill causes the render texture to be stretched to fill the desired resolution, which needs to calculate the required size of the sprites and resize them. Doing this with point filter would be inaccurate as bilinear uses an average to calculate this size.

If this is not desired disable "Stretch Fill". Could you post some screenshots of your camera view and Pixel Perfect Camera component so we can possibly advise you of your best options.

 

The problem is I still require the ability to use Stretch Fill and have the filter mode set to Point. Otherwise, I have to manually edit the script every time I open up the editor and before I build.

 

This feature would be welcomed. I can get it working by editing PixelPerfectCamera.cs myself, but obviously that's not a permanent solution.

 

But the issue with doing that is you have to change it every time you open Unity!

 

I can't believe this isn't permanent any more, and I can't believe it hasn't been added as a toggle. Can I just read-only the file or something?

 

Well, the camera is useful for more than just absolute perfectness, it calculates everything properly and is the easiest way of making a pixel-perfectly positioned rendertexture. If it's still not being planned after all this time and numerous requests for it, I'll just fork the folder, remove it from package manager and hack the single line in myself.

 

Oh, and also, I don't get "swimming pixels" since I work out exactly which resolution will upscale to integers on a 16:9 1920x1080 screen (really doesn't matter to me on a screen that isn't 16:9 or 1920x1080).

I think almost anybody making a pixel-art game would rather have swimming pixels and not-so-pixelness to an unbelievably bad bilinear smoothed mess. Seriously, it looks like when you don't upscale old games in Dosbox and it hits your monitor at the original non-native resolution, nobody in the world wants this.

Of course, you could try to implement the type of bilinear that first upscales to as close as possible by integers, then bilinear smooths the remainder (Sonic Mania does this, Shovel Knight, etc). This has also been mentioned before in great detail (over a year ago on the last thread) but you also don't seem to like that, so I'll just have to change that one line to make a practically useless camera tool into an excellent camera tool.

 

First off that's not an excuse to add an option, non whole number pixel sizes don't "defeat the purpose" of anything. Besides there's already the option to not use upscaled render textures which looks like a slightly scaled down then scaled up version of a normal camera.





Even if it is flimsy, it's not even a valid excuse because pixel perfectness isn't even lost, the only difference is whether or not the implied pixels are whole number multiples of the real pixels or not. When emulating older hardware it's preferable that there be no filters by default so you can have a more accurate representation of how they would display on digital displays.

You can see that even though the implied pixels aren't whole number multiples of the real pixels of my display, it doesn't interfere with the readability of what's being shown.







By forcing people to only use bilinear filtering when using stretch fill, your limiting the usability of your tool. It doesn't matter if you personally find it unappealing some people may find a use for it, especially when there's no other way to get that result except by using the pixel perfect camera.

It took me an hour to figure out why things were being filtered when I used the stretch fill and took me 10 minutes to fix it for myself. It's not difficult and it has a use, the least you can do is just add it

 

I couldn't agree MORE! What was your solution?

 

I just copied the folder where the package was saved, changed the PixelPerfectCamera.cs of the copy to my liking, then removed the package then imported my copy

 

This seems to be the accepted practice for this abandoned(?) package.

 

Awesome! That second option should be very close to how Sonic Mania (and I think Sonic CD) does it, which makes for a very crisp image, but still smooths out any integer jankiness. I will still keep it totally off by default, but this would allow me to add a pixel-friendly smoothing setting for users that won't blow everything out into a billinear smear.

 

Sorry to tag along with this, but 2dlight buffer filtermode and shadow (and normal, mask) should also be able to set as point sampling and able to match the screen buffer resolution as well. Right now the light buffer is just set to be screen resolution multiplied by resolution value and all bilinear filtering. We need option to be able select filter mode and match the pixel perfectness set by the pixel perfect camea component.

 

I just wanted to chime in that this all sounds great, thank you! I'm especially interested in that first point, since not everyone will be on resolutions that can be targeted with perfect integer scales of the reference resolution, being able to offer those players the option of black borders, or stretched with filtering, or stretched with no filtering sounds ideal.

 

So I see that some progress is being made for this issue. Do any of us know when this functionality will be available for us?

 

No idea, PPC updates take an eternity.

Any ideas when the update will be available?

 

Change the PixelPerfectCamera.cs script in

C:\Users\[username]\AppData\Local\Unity\cache\packages\packages.unity.com\com.unity.2d.pixel-perfect@3.0.2\Runtime

and it will be persistent.

 

You're the man, Zebbi

 

For any newcomers to this thread:

Find

PixelPerfectCamera.cs

in

C:\Users\[username]\AppData\Local\Unity\cache\packages\packages.unity.com\com.unity.2d.pixel-perfect@3.0.2\Runtime

Code (CSharp):

1. activeRT.filterMode = m_Internal.useStretchFill ? FilterMode.Bilinear : FilterMode.Point;

Change to:

Code (CSharp):

1. activeRT.filterMode = m_Internal.useStretchFill ? FilterMode.Point : FilterMode.Point;

 

Also for macOS users, you wanna go to

/Users/[username]/Library/Unity/cache/packages/packages.unity.com/com.unity.2d.pixel-perfect@1.0.1-preview/Runtime

to find PixelPerfectCamera.cs

 

@yuanxing_cai when will this be updated?

 

Hai, @yuanxing_cai!

Any news on when these features might land?

 

I was actually going to bump this thread yesterday before I forgot, thanks for reminding me. I mean, this post is from nearly 4 months ago: https://forum.unity.com/threads/pix...-as-a-filter-mode-option.721760/#post-6058565

 

*bump* @yuanxing_cai

 

(I know, it's Christmas) *bump* @yuanxing_cai

 

It could be in version 4.0. I haven't used that version though because my game is in Unity 2019.

 

I have no idea, I'm still using the package manager version that's STILL not updated. Still using this one weird trick:

 

Happy *bump* day.

 

Any update on this?
I've copied the package a long time ago exactly for this issue, but it breaks every so often because other packages work differently (universal render pipeline for instance).

Btw, a little bit simpler (you don't need the if):

Code (CSharp):

1. activeRT.filterMode = FilterMode.Point;

And if anybody is looking to fix this with the urp, change this:

Code (CSharp):

1. internal FilterMode finalBlitFilterMode
2. {
3.      get
4.      {
5.          if (!isRunning)
6.              return FilterMode.Bilinear;
7.          else
8.              return m_Internal.useStretchFill ? FilterMode.Bilinear : FilterMode.Point;
9.      }
10. }

to this:

Code (CSharp):

1. internal FilterMode finalBlitFilterMode => FilterMode.Point;

 

I'm confused, I got the other thing to work, but I'm also using URP. Where does this code fit into it all?

 

I suspect that the reason this hasn't been addressed yet may simply be that @yuanxing_cai no longer works at Unity. @Chris_Chu , can you review this simple feature request?

The code is known (more or less), and yuanxing_cai offered an ideal, non-breaking solution in this reply. Thanks!

 

@Chris_Chu Hellooo~~~ this thread would've been hilarious to me if I wasn't in on this wagon~~ It's kind of important? Otherwise I'm just gonna write my own ppu cam because fixing source code just ain't scalable~~

-----------

You know what on second thought, I'll just abandon the package and edit the source code and put it in my github with the rest of my collections... seems to be the way

 

Supposedly this fix was shipped in 2022.X. I'm on 2021 LTS so I can't confirm. Using my own hacked solution until 2022 LTS comes out.

 

Oh goodie.. yeah I'm still using 2021.3.16f1 myself. Thanks for the heads up

 

FYI, the documentation doesn't reflect this. It only shows Filter Mode in the docs for URP 15.0+, which tricked me at first because the option only shows up conditionally when you select

CropMode.StretchFill

.

 

If anyone is working in Unity 2021.x, AND is using URP, go here to make the change to make the change instead;

C:\Program Files\Unity\Hub\Editor\2021.3.29f1\Editor\Data\Resources\PackageManager\BuiltInPackages\com.unity.render-pipelines.universal\Runtime\2D