An Overview of Phong Shading in GLSL
github.com
github.com
Not sure if it's because it's totally opaque, or because it adds a dependency and potentially a whole heap load of transitive dependancies. You're putting your game/app/whatever's performance in the hand of someone else (moreso than for infrequently run CPU code), not only hoping they didn't write a crappy implementation of whatever, but hoping nothing they depended on did either.
Not to mention, they might have done it differently than you would. For example, lots of times you want to do gamma correction using square/square root, and not using pow 2.2 (monitors vary so much that this is in all likelihood just as/nearly as correct, and it's vastly cheaper).
... Also, you'd think in a discussion about how to do most of these things, they'd actually show the code and not just say 'oh a library magically handles it'
Anyways, thanks for the comments. Modular programming has a lot of merits, but it isn't for everybody. :)
It's like anything, you're not just going to dump a third party library into your code and hope for the best. You're going to see if it does the job, does the job well, and if it doesn't - you'll figure something else out.
Game code isn't magic, despite how much game programmers want to act like it is.
Conditionals, loops, and even function calls on bad drivers are all things that need to be avoided, when possible, and it's very rare you can get ship a game without having to spend time optimizing your shaders.
Not to mention the fact that the landscape of GLSL compilers is fairly broad and you have absolutely no control over whether or not you have one worth anything (frequently on mobile, you don't).
Unfortunately, the fact that shader code is hard to write, and has a huge number of performance pitfalls mean that you're going to have to inspect the source of any non-trivial library you use, and in most cases you'll probably need to write it yourself, if you care.
Here, I took the time to look at a few from NPM.
- https://github.com/Jam3/glsl-hsl2rgb/blob/master/index.glsl This is awful. Data dependant branching absolutely destroys performance on the GPU. A vectorized, zero branch solution to this exists and is fairly well known, the author just doesn't know it or doesn't care. - https://github.com/hughsk/glsl-dither/blob/master/2x2.glsl A neat effect, but the statement above is still true. The other dimensions (4x4 and 8x8) are even worse.
There are others as well. The point seems to be that many of them that are doing something other more complicated than a couple lines, are not well written for code that runs on the GPU and are going to perform very poorly in practice.
FWIW, I don't think it can without assuming the input lies in a certain range.
But for most use cases, especially quick prototyping, a fraction of a millisecond isn't going to make a difference when your game is already at 60 FPS, or when your bottlenecks don't lie in the shader.
In rare cases where it makes a difference, you can just require a local file that has been optimized for your use case, or a module that you control (for semantic versioning and better reusability).
#pragma glslify: optimizedHSL2RGB = require('./hsl2rgb')
With some inlining and algebraic simplification (the kind that, unfortunately, can't safely be done by a compiler most of the time) you can get even simpler than the ones linked. For example, I've used something similar to the following for hsl to rgb before.
l + (1.0 - abs(2.0 * l - 1.0)) * s * (clamp(abs(mod(h + vec3(0.0, 4.0, 2.0), 6.0) - 3.0) - 1.0, 0.0, 1.0) - 0.5)