In my mining game, I have a chunk loading system to help keep memory low. Parts are created on the client-side, and are reused with a PartCache optimization, which means instead of adding new / removing old Parts whenever they’re needed, Parts are CFramed between their actual position, and extremely far away (CFrame.new(1e9, 1e9, 1e9)).
I was testing what it would be like if I used ImageHandleAdornments instead of Textures to give a brighter, bolder look to some ores, and I assumed they’d be cheaper to render than 6 SurfaceGuis per block. Turns out, I was wrong.
It appears that if an ImageHandleAdornment is somewhere under Workspace, it will add a constant frame time cost regardless if it’s being rendered on screen or not, as if it’s not affected by “Frustum culling”. Even when it’s in my cache (being trillions of studs away even, there’s no point to rendering something that far), it’s still affected.
CTRL+SHIFT+F2 draw counts also indicates that nothing should be abnormal here, but it still causes frame time to increase. (Note: Vulkan is being used, but it still happens with D3D11.1)
Currently, my only workaround is to either cut use of ImageHandleAdornments and use SurfaceGuis (also intensive for usage like this), or toggle Visible when it’s returned to the cache.
Other instances like Parts do not get rendered when they’re this far away.
Here’s a reproduction file.
ImageHandleAdornment Repro.rbxl (59.2 KB)
Expected behavior
I expect for ImageHandleAdornments to (ideally) only increase frametime when it’s being rendered on screen, whether that be through occlusion / frustum culling.
This lag would only make sense if I had several parts in my proximity (<100K studs) with ImageHandleAdornments active.