Find better approximations for atan2 and acos in sky shaders?

[Melvin8D]

I was messing about with sky shaders, and digging in sky.glsl in the engine code, I noticed that godot uses an approximation function for acos and atan2 for the mapping of SKY_COORDS. However, I noticed the approximation is a little inaccurate, especially on the Y axis, although the X axis is also noticeable. I was wondering if there were better approximations for acceptable performance out there and if it would even be worth changing?

Here are 2 screenshots of a HDRI from Polyhaven implemented into a custom shader. I tinted the one using the true inverse trig functions blue, and the approximations red. It might be a bit hard to tell if looking at both at once, but when switching in open tabs you can see there's a significant shift of pixels on the y axis, and you can see some minor shifts on the x axis.

Here I've taken the absolute difference of each axis of the approximate and true coordinates. The red, which corresponds to using the atan2 approximation, is multiplied by 300.0 for visibility, while the green, which corresponds to the acos approximation, is multiplied by 16. The images are taken with a camera facing forward with a field of view at 120 degrees.

Here are some desmos graphs comparing the approximations of acos and atan to their true ones.

https://www.desmos.com/calculator/pxdh4asgeb (acos)
https://www.desmos.com/calculator/k5ppu79r6a (atan)

The atan, which is used for calculating the x axis, is fairly ok, with a max error of about 0.13%, while the error of the acos is just under 1%. I want to know if the Godot team would consider using better approximations if they exist for similar performance.

[Calinou]

I want to know if the Godot team would consider using better approximations if they exist for similar performance.

Sounds good to me on principle, but we need benchmarks on low-end GPUs (particularly mobile), in scenes with no lights present (or sky-only lights). In these conditions, you might need to bump the Scaling 3D > Scale project setting up to avoid V-Sync limitations on mobile.

[Melvin8D]

Upon digging, it seems that there probably isn't a better approximation with the same amount of terms/performance, its just that godot's acos_approx ends up having an error of just under 1%, compared to the more accurate atan2. In my case, implementing the 3rd order polynomial approximation is very good.

[clayjohn]

If you can find a better approximation, then feel free to open a PR. I went with one that has fairly reasonable error terms for all ranges. But you may be able to find one that is specifically optimized for how we use acos/atan2 in the shader. In which case it may be possible to reduce the error terms without compromising performance

Removing the approximation is not an option, the hardware implementation is way too slow. And the visual difference isn't noticeable in practice. Chasing mathematical purity is not a worthwhile endeavour

[Melvin8D]

Upon further digging, I don't think there is a better approximation for the same amount of performance/operations. An error of just under 1% did seem a little high, especially because the arctan function was quite more accurate, but if its good enough for most people then I guess thats how it is. Just gonna close the discussion.