As a Roblox developer, it’s currently impossible to create true pixel art or low-fidelity 3D models that look correct. Textures on models are always blurred by forced bilinear filtering, meaning there’s no way to make them render pixel-perfect like UI images can.
While SurfaceGuis can technically achieve a similar look, they are memory-heavy, inefficient, and don’t work on Meshes, making them practically useless for teams looking to achieve this look with tile-based tools such as SpryTile or CrocoTile 3D.
The only current workaround is to upscale tiny textures (like 16×16) to extremely large resolutions (such as 1024×1024). This approach:
- Consumes unnecessary memory
- Increases load times
- Still looks blurry when viewed up close
- Introduces texture bleeding and visible seams due to filtering artifacts
Practical examples
The following are real, practical examples I have encountered while developing a game with this artstyle:
Blurry edges
Even at maximum texture resolution (1024×1024), edges appear smeared and lose their sharp pixel definition.
Texture bleeding
Pixels near UV edges blend into each other, producing visible seams. Developers must manually add 2–3px padding per tile to hide these artifacts, further inflating texture size and wasting memory.
Why SurfaceAppeareance would work
Roblox Staff have previously mentioned that adding ResampleMode to legacy Textures and Decals isn’t possible due to backwards compatibility with older systems (“legacy avatars”).
However, that limitation does not apply to SurfaceAppearance, which:
- Is a modern rendering system with no legacy dependencies
- Already supports PBR materials and layered maps
- Is not used by Legacy avatar types (PBR hats are not supported on R6)
Considering it is the most versatile Texture Instance in the entire engine, it would be an ideal place to introduce a property like:
SurfaceAppearance.ResampleMode = Enum.ResampleMode.{Default, Pixelated}
Conclusion
Nearest Neighbour filtering Textures (NOT SurfaceGuis) has been one of the most consistently requested features on this Forum, and the approach proposed on this Feature Request could bring some of that desired functionality into the engine, today.
These filtering limitations have forced our team to maintain a two-page internal document filled with workarounds, warnings, and specific export instructions just to avoid visual artifacts.
Every other major engine supports nearest-neighbor texture sampling natively, without any of these complications. It’s frustrating that we need to spend so much time fighting the engine instead of creating content, and the only reason we continue doing so is because we genuinely love this platform and want to see it improve.
