Disclaimer: I understand that this might not be a scripting issue (though it might be), don’t roast me for that, the other categories don’t get nearly as much attention.
Attempting to use parts as pixels, I run into this issue:
I’m using a color picker to zoom in on an area of the screen. That’s a 1:1 ratio - 1 part fits exactly 1 pixel on the screen.
What’s the issue in that image? Nothing. At smaller viewport sizes it works fine, but when it’s increased (especially in fullscreen):
The colors start blending/bleeding. Even at a close range:
The black lines are not parts, those are frames, irrelevant to the issue. The colors are 1x1x1 parts.
I’m almost 100% sure that the code is correct, there is both an X and Y offset of 0.5 studs that’s either applied or not depending on whether or not the viewport dimensions are even or odd numbers. I tried reversing those, that made it worse, so it’s set right the way it is.
It doesn’t seem to be a number precision issue either, I tried switching things up to make sure that all the values of the camera CFrame are round, and it still happens.
You might think that those are the sides of the parts giving an impression of blending, but I tried wrapping the 3 parts in more parts of a same color, and it’s still there.
Graphics quality, lowest or highest doesn’t change a thing (since this is a ViewportFrame).
I’m out of ideas. A simple solution would be to turn of anti-aliasing but that’s not possible.
Do you have any thoughts? Feel free to ask me for any additional information.
I can’t be sure, but:
Lighting tends to bleed through unless they are 4x4x4 (voxel size). This is why I mentioned Lighting.Technology earlier, since I was wondering which one was being used.
However, I have absolutely no clue how ViewportFrames work. They’re just that low quality thing I try not to use.
@ignite_rock Well that’s the odd thing, the easiest thing for them to do would be to give me the same pixels. I’d at least expect this with low graphics settings. But I suppose that doesn’t apply for UIs.
@SubtotalAnt8185 Yes, performance. Even if everything is anchored, not casting a shadow, compatibility and so on, there’s still much more going on in workspace. However I’ll test it in workspace anyways just because I’m curious if that would solve my issue. And this is not a lighting issue.
Each viewport frame will create a texture for rendering. The texture has a max size limit, so if the frame is too big, the contents may look blurry.
That’s probably it, I’ll test it out, thanks a lot!
If that is the case then I’ll have to compare workspace and ViewportFrame performance and decide what’s worse - the performance loss or having the view cut off on most PCs and some tablets.
EDIT: Yup, that’s it.
I’ll give an update regarding performance differences once I test things out.
PERFORMANCE UPDATE (workspace vs ViewportFrame comparison)
For anyone interested, I created this topic instead of just replying with the results here, so it’s more visible/searchable for anyone who might google it at some point.