libretro / common-shaders

Collection of commonly used Cg shaders. These shaders are usable by either HLSL and/or Cg runtime compilers. The cg2glsl script will translate most of these into GLSL shaders.
http://www.libretro.com
1.03k stars 250 forks source link

Apparent issue with the XBR shaders #164

Open mijofr opened 3 years ago

mijofr commented 3 years ago

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: contra

And then upscaled in XBR-2x-noblend

vWb9vKP

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:

hkgRgcy

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:

image

Is it possible there's a common math issue across this repo's glsl implementations?

Hyllian commented 3 years ago

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: [image: contra] https://user-images.githubusercontent.com/20412792/114705344-f9ebb380-9d6a-11eb-8518-65d65c529537.png

And then upscaled in XBR-2x-noblend

[image: vWb9vKP] https://user-images.githubusercontent.com/20412792/114705396-0c65ed00-9d6b-11eb-957b-0e533556742c.png

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:

[image: hkgRgcy] https://user-images.githubusercontent.com/20412792/114705575-37504100-9d6b-11eb-8d13-75921c98ab5a.png

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:

[image: image] https://user-images.githubusercontent.com/20412792/114705786-78485580-9d6b-11eb-9fd6-d73656b13c52.png

Is it possible there's a common math issue across this repo's glsl implementations?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/libretro/common-shaders/issues/164, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGJS3F2CP4J23PNN3ZADM3TIV6UZANCNFSM425HQO3Q .