You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been working on some of my own stuff using XBR shaders and have been using the libretro implementation as reference, and I've noticed what seems to be a common issue across the XBR implementations:
Take a look at the reference image:
And then upscaled in XBR-2x-noblend
If you look at the edges of the balls, there seems to be a lot of small sharp edges poking out around the corners. The same issue is visible in my personal rendering of the shader code, which lets me go in closer:
These spikes happen in all of the XBR shaders, but I've run a few tests on the reference using other XBR implementations and libraries around and the circles are rendered more like you'd expect:
Is it possible there's a common math issue across this repo's glsl implementations?
The text was updated successfully, but these errors were encountered:
The problem is related to color difference math. In shader, the color diff
math is very basic, because the speed is critical. It's more problematic
with red shades, like in those balls.
There's an implementation where I tried another approach and called the
shader xbr-accuracy or something. There these problems are more rare. The
drawback is on speed, though.
Feel free to try other color diff implementations. But beware that it takes
a good hit on shader speed.
Em qua., 14 de abr. de 2021 às 08:51, mijofr ***@***.***>
escreveu:
I've been working on some of my own stuff using XBR shaders and have been using the libretro implementation as reference, and I've noticed what seems to be a common issue across the XBR implementations:
Take a look at the reference image:
And then upscaled in XBR-2x-noblend
If you look at the edges of the balls, there seems to be a lot of small sharp edges poking out around the corners. The same issue is visible in my personal rendering of the shader code, which lets me go in closer:
These spikes happen in all of the XBR shaders, but I've run a few tests on the reference using other XBR implementations and libraries around and the circles are rendered more like you'd expect:
Is it possible there's a common math issue across this repo's glsl implementations?
The text was updated successfully, but these errors were encountered: