This is a shocking “feature” which is resulting in significant loss in visual quality across all of my places. I’ve found a workaround for the time being. In the folder where your ROBLOX install is located (e.g. where the Player EXE files are), create a folder called “ClientSettings”, and create a file called ClientAppSettings.json
Inside this file, copy and paste the following line, then save the file. {"FIntTextureCompositorLowResFactor":"4","DFFlagEnableRequestAsyncCompression":"false"}
After that, when relaunched, textures should now work properly.
“Request Async Compression” appears to be the feature at fault, though it seems to be an intentional change. Personally, I’d go as far as to say that this so-called feature simply shouldn’t exist on desktop devices without an off-switch in the user’s graphics settings since the sheer amount of loss in texture quality without any prior warning is simply unacceptable for both players and developers.
The fact that this has even shipped, for desktop users, is appalling.
This happens consistently and seems to be either a reduction in Roblox’s VRAM cap or its hardware throttling limit not respecting the VRAM cap. Either way, Roblox NEED to have better settings for the player and need to meet the industry standard for graphics settings, such as allowing players to control the VRAM cap, force texture quality and render distance, etc., Rather than a single very obscure graphics level which isn’t even respected most of the game (ie this bug).
This occurs moreso on experiences with more visual instances (parts, meshes) or when I have other programs using VRAM (yet my GPU still has more than enough spare VRAM) such as Roblox Studio. I have no performance issues and I have plenty of hardware being unutilised, and my system also has a very cool temperature under heavy load (low 80C) so there is definitely no thermothrottling occuring.
The main issues with this is that the user has no in-app control over the VRAM cap, AND if VRAM usage drops, the textures are NOT uncompressed within the same session.
Users should be able to force textures to stay uncompressed. If I can run my experience in studio (where no render distance exists) at level 21 quality, then the client shouldn’t be reducing performance utilisation at ALL (noting that Studio uses far more resources than the client).
here are something that I’ve noticed about the issue -
seems to be only affect places with relatively large part counts and causing the engine to auto-adjust texture quality for performance boost (while quality setting is set to “Manual”)
causing mesh texture, material texture to flicker during the texture quality auto-adjust
although the texture quality being adjusted to lower quality, the process on auto-adjusting (flickering) actually appears to be CPU intensive and result in low FPS for a while
after the auto-adjusting, all affected textures stay in low quality and didnt appear to revert to full quality even for a while
only happens on my dev place with high part counts while my testing place with low part counts being unaffected
seems only happen on some servers but not everytime joining the game (AB testing in progress?)
Another reason that this should be an opt-in or atleast opt-out setting, not FORCED upon people. Increasing CPU usage could cause instability for many computers on particular experiences.
People should just be able to choose the material compression quality (or none at all), and that should only affect newly loaded parts (joining an experience or streaming service)
(2k monitor, leaderboard GUI included for reference.)
I have 16 gigabytes of ram. I doubt most games will even us a significant portion of 4gb ram. How will this help memory usage on my machine, or others? This feature should be entirely opt-in and not forced upon people.
seems to still be actively happening and is making everything super amplified or outright changing the colors, as well as messing with some of the hitboxes for voxels.
I’ve noticed this is Project Smash where sometimes the stud texture is unbearably low quality and the billboard’s become unreadable. I have a pretty good gaming PC so it should be able to handle without the resolution scaling.
I am noticing that this issue has resurfaced again, however it seems to especially affect user-made decals, rather than the built-in materials. Its hideous and a completely useless feature, and should be removed permanently from this platform. Why such a bad feature has even been implemented is beyond my comprehension.
Not only is texture resolution and compression changed multiple times on the fly, there is also a really hideous fuzzy outline added, however that could just be the terrible compression algorithm.
It’s when your device runs out of memory or roblox thinks it is to prevent crashes (I’ve noticed a lot of Roblox devs are extremely bad at UV optimization and keeping texture size low, why does a 2x2 stud block need to have an 1024x1024 texture ); but it should defo be reworked to be less aggressive. I also think a possible way to rework it is to compress it a little bit more from the start so that it’s not getting downscaled really low during runtime. Before, there was also a system that downscaled textures not being looked at however that was also wayyy too aggressive; looking away from an object for more than 30 seconds resulted in the texture completely unloading and remaining grey when you looked back at it while the texture reloaded.
Well frankly it shouldn’t be forced on the user anyway, especially not when their memory detection and commit is broken. Roblox doesn’t dynamically alter its commited memory at all, when they really should. Is there a way to force Roblox to commit or have more ram allocated to it?
The worst part about all this is Roblox forcing it on users with no setting to disable or alter its behaviour. The rest of the gaming industry offer plenty of graphics and computation settings for users, so why can’t Roblox?
That actually occurs to some extent; that’s why on baseplates you get about 4GB of RAM usage on a 8GB device, Roblox is trying to use all the available memory to run smoothly. Just curious, what is your ram usage while playing roblox?
Well this seems to be completely untrue because my Roblox client consumes less than 2GB of RAM per instance, and this is consistent. Its completely broken. I have 16gb of ddr4 memory, and most is available.
Then again Roblox is well known for behaving wildely different on different devices, so who knows. I’ve had to force enable fflags to get vulkan rendering to work, as the auto detection that is meant to switch the rendering to that engine on high-end systems is also broken on my end.
reposting some of my findings from other post - 
); but it should defo be reworked to be less aggressive. I also think a possible way to rework it is to compress it a little bit more from the start so that it’s not getting downscaled really low during runtime. Before, there was also a system that downscaled textures not being looked at however that was also wayyy too aggressive; looking away from an object for more than 30 seconds resulted in the texture completely unloading and remaining grey when you looked back at it while the texture reloaded.