Is there a way to turn off anti aliasing for pixel art?
I try to make pixel art, but when put into Roblox, it has to be really small to not blur. if i enlarge it, it becomes blurred. even if i keep the same aspect ratio.
1 Like
There isn’t, really. Various Minecraft-themed places also ran into this issue half a decade ago. They had to upscale the images (without anti-aliasing) on their own end. Even then, the edges weren’t completely sharp.
You can sort of make it work if you make an ImageLabel for each pixel.
Each label’s ScaleType must be Crop, ImageRectSize must be 1, 1 and ImageRectOffset should corresponding to the position on the sprite.
It’s as good (or bad) as making a colored Frame or Part for each pixel, except you don’t have to export your pixel art as binary data and convert it to a Lua string first.
Both options suffer from being horribly slow (hundreds or thousands of ImageLabels or Frames or Parts).
To clarify the topic, this is technically this is a mipmap issue, not anti-aliasing. Unfortunately for pixel artists, there is no way to turn it off at the moment.
As Eestlane771 already suggested, your best option is to upscale the images as large as possible to 1024 pixels.
You can upscale pixel art to something like 128 x 128, using Nearest Neighbor as your upscaler. I do this a lot in paintDOTnet, and I have no issues with the pixel art.
1 Like
Well I’ll be damned, it really is possible.
This guy makes crisp, aliased textures on objects.
He makes a mesh in blender composed of square quads.
The UV map/texture of the mesh is just a palette of colors used in the texture.
The UV coordinates of each quad on the mesh is a tiny section on the appropriate color on the palette.
There is no antialiasing on polygons/parts/whatever else, so these will look completely crisp even from really close up without 2048x2048 textures.
The downside of this is that you need a new mesh (new UV coordinates) and a new palette for each sprite. It doesn’t sting that bad if you have a script or tool to do it for you. But you likely don’t, and there’s no pre-made tool for it yet.
…It’s possible, but it’s an incredibly inefficient use of memory for the sake of gimmick. Even as cheap as quads are, the total tri count would eventually be a detriment to your game if you were to design every mesh like this.
I would highly suggest not doing this, it is far more painless to compromise with the texture upscaling solution.
1 Like
Actually the reason I did this was because on Roblox I’ve found that tris are generally more performance friendly than textures, especially with how efficient Roblox’s LoDs are for meshes, specifically.
Granted, this is only for pixel-style assets that will not use PBR. It’s archaic, I know, but it works better than having a bunch of 1024x textures.
It’s also worth noting that Roblox on mobile compresses textures by an additional step than PC and Xbox, so this method protects against that in addition to being good on performance.
1 Like
I was curious to see for myself if this method did in fact have performance benefits, but I’m afraid I’ve only reinforced my concerns about memory overuse.
I modeled a generic grass block with 3 unique 8x8 textures between the top, sides, and bottom. The texture block (TB) is to the left and the poly block (PB) is to the right.
The graphical differences are negligible, the TB’s mipmap fuzzing is visible on closer inspection but not to an overall effect that a player would notice. The unseen difference here is a whopping 6 to 768 tris (128 times as many).
Texture-wise, I have given the experiment the benefit of the doubt and made the TB’s texture as large as possible and not to reuse any pixels, while the PB’s texture is a super efficient 4x4 palette (mipmaps destroyed the effect at 2x2).
This is the only area where the PB is more efficient, and only between 7KB to 119 bytes.
Lastly, I exported the mesh data, and it was the final nail in the coffin for me. Memory-wise, it is a difference between 6KB to 84KB (14 times as large) and ultimately what will impact performance.
A rule of thumb as a 3D modeler is that it is way more efficient to rely on textures than tris, which for example is why normal maps are used for minuscule details rather than actually modeling them and consuming so much more memory.
Overall, performance won’t be impacted on a small scale, so it is certainly a doable gimmick for tool and accessory meshes. I still stand by not relying on this style on a large scale, I wouldn’t discourage developers from utilizing it but they should really weigh the negligibility of the graphical differences with inefficient memory usage.
2 Likes
I’m very glad you actually compared the options!
There’s something I’d like to nitpick on, though.
That large texture is not 7KB. It is 3MB at the very least (1024x1024x24 bits, width x height x bits per pixel), could grow to 4MB with mipmaps and could be 4MB/5.33MB if the bit depth were 32 (RGBA).
The reason for this is that textures have to be uncompressed (or very lightly compressed) in order to be used, as PNG compression does not support random access.
Furthermore, the uncompressed texture will have to be uploaded to the GPU.
So in general, that increase in texture size could potentially outweigh the decrease in polycount, especially with mesh instancing (although I’m not 100% sure how well that helps)
But now that there’s a comparison case, I’ve become much more curious about this.
I’ll likely get back to this and check for myself how well suited this is to pixel art, where the canvas size is fixed (mesh can be the same) but the texture differs (which is where it can help to make each texture ~12 bytes, not 4 megabytes)
1 Like