Is there a shader that uses heuristics to detect pixelized textures on 3D objects and smoothens them? Beetle’s integrated texture filtering is limited. Bilinear, Jinc2 and 3-point algorithms create visible seams on the edges of some textures. Sabr looks bad, xBR looks okay but still too agressive with no ability to tweak parameters (Maybe it’s possible by editing source in repo and recompiling the core?). Best solution would be to add Nnedi3 or ScaleFx as filtering methods since they are in my opinion much better at scaling than all of the mentioned above. But for now I wonder if there is a shader alternative?
post-proc shaders can’t really handle the perspective changes that happen with texture-mapped polys.
For the texture filtering shaders, they have to run on every texture, which chews up performance, and there’s currently no way to do multipass shaders (it’s technically possible but would be messy and a lot of work), so more complex effects that require multiple passes to be even reasonably peformant are out of the question.
1 Like
I see. I have a few questions then:
-
Is it possible to reduce seam visibility caused by bilinear/jinc2 filtering somehow? Maybe by blurring the edges of filtered texture?
-
Is it possible to reduce intensity of xBR filtering by editing parameters in this file and recompiling the core?
-
clamping the coords of the textures can help, but it’s still not perfect. The problem is just that those sample clusters of pixels, and at the edges, the sampling gets into stuff we don’t want.
-
sure. It’s easier to test with GL, since the vulkan renderer needs the shaders pre-compiled and baked-in, so you’re on the right track there.
1 Like
Ahhh so it’s hard to do for Vulkan in Beetle. What about Swanstation? Is it possible to tweak it here for DX11 or Vulkan?
Yes, that should work there. I haven’t personally done anything in Swanstation but its shader-driven texture filtering is based directly on the work I did in Beetle-psx, just abstracted to all 3 backends instead of having individual implementations per renderer.
2 Likes
Oh man… you need Visual Studio to compile Swanstation. Isnt it like 30 GB or something? It’s probably an overkill for me. Also @hunterk xbr filtering is notorious for posterization. Is it a good idea to use a despoterize shader? I found one with two passes in misc/deposterize folder but it seemingly not working? I dont see a difference.
deposterization would be nice, sure, but again: we can’t really do multipass effects here, and doing single-pass bilateral filtering et al. in serial with the xBR calculations is likely to be pretty demanding with only a subtle effect on output.
Yes, I understand about filtering performance cost. But I meant as a post-process shader. Do deposterize-pass0.slang and deposterize-pass1.slang work for you? For me it seems like they dont do anything. What game coud be a good test?
Ah, as postproc, they’re not going to do much at all, and nothing in conjunction with xBR texture filtering. They would need to be applied to the texture in memory prior to the xBR application to have any effect on the texture posterization.
1 Like